Re: TI-H: EII, EII, EIV, & MMODs

To: ti-hardware@lists.ticalc.org
Subject: Re: TI-H: EII, EII, EIV, & MMODs
From: gussie@alaska.net (Grant Stockly)
Date: Sat, 7 Mar 1998 02:38:13 -0700
Reply-To: ti-hardware@lists.ticalc.org

>List the features of each, and the memory capacity, and also, the ONLY
>way the EIII can't use MMODs is if it uses a memory chip with a
>different number than the EII memory chip. Is the chips different? Is
>that why the MMOD won't work on the EIII?

Complex hank switching.

>Also, DON'T, PLEASE don't quit making the EII the moment you make the
>next new expander. Brian quit making the EuP chip when the EII was
>announced, and for MONTHS, we've had to wait. Then when something new
>comes out, the device is sudenly obsolete, and the memory module can't
>be used with any other device. I say, make the future expanders backward
>compatible with the SAME memory chip used in the EII and EuP. It should
>read the EuP and EII file formats, and allow backwards compatibility.
>You should be able to format EII MMODs and EIII MMODs, if there is any
>difference. I can't stand this! A device becomes obsolete on this list
>before anyone ever has a chance to produce it!!!

It reads the same file formats, so all you have to do is swap the chips.

Btw, the process you go to making those mem chips surprizes me.  I've got a
prefab company and a distributior that want to make them by the thousands.
They are already compatible with the gameboy...the company says they will
be a hit.  I have no idea why, its just flash with traces.

>And worry about getting the EII and ALL it's drivers complete before you
>split your valuble resources on another expander or two. Finnish a
>project before you start 1 or 2 more (and countless other NON expander
>projects)!!!

I have only 1 project going that I'm working on and that is the EII.  All
the rest are done on spare time.  And quite reasonably I don't deserve mail
like this: (names kept confidential, words changed)

--------------------------------------------------------------------------------
WHAT THE *&^% ARE YOU DOING?  WHY ARE YOU JUST LIKE THE OTHER *() HOLES ON
TI-HARDWARE?  FINISH THE DRIVER.  MEL AND BRYAN DROPED US, AND ALL RICHARD
DOES IS MAKE LEDS AND PLASIC MESSUP YOUR %$#@ING CALC.  DO US A FAVOR AND
GET A !@#$ING LIFE YOU *&^%ING MORON &^CH A^% SNIFFER!
THANKS FOR MAKING ME WASTE MY TIME
--------------------------------------------------------------------------------

This has nothing do do with you guys, but it might have a thing or to about
releas dates.  I would rather go skating (board) than read 200+ msgs like
this...

>If you realy want to do every one a favor. Make the EII and get it
>going, and then make future projects able to read and write EII MMODs.
>The MMOD is not that expensive. If you have a plan with TONS of memory

Each mod is $15.  I will make them for $6 and resell them for $10 in june.

>avaliable, great, but have the built in memory and the MMOD. the driver
>could treat one as a hard drive and the other as a floppy drive. You
>could copy files between the EIII memory and the calc, the MMOD and the
>calc, and between the MMOD and the EIII memory.

I'm sorry to say again, that I can't conform to your standard.  I wish you
would just wait for me to release my cart standard, entirelly non mmod
(don't get mad), because it will handle complex bank switching with just a
few extra I/O lines.

>Add backup feature to it and a busy LED and I'll be happy!!!

It already has that.

If
>something works and does everything, why try to add more???

Aparently you are getting mad when I try to.  (ie: it works)

You could
>simply make the chip and leave it at that!

You could do nothing and leave it to that.  I choose to do this because I
like not because I have to.

Produce that for a while
>untill something truly revolutionary comes along.

This is...I havn't told you half the things on it because you are already
jumping on my back telling me that your mmods handle CMB and and things
like that.

How about adding some
>sort of id that the calc would send via the link port and then the id
>would call the MMOD or the EII internal memory, but use a different id
>for other AVR's.

Again, that has been done.  Its been there since the EuP beta.

That way, you can produce an AVR that does many things,
>or have upgrade AVRs that can be added to older systems and not cause a
>problem.

I will sell 25 AVRs to the first 25 people.  After that I will sell 50.

Another idea, would be sound! Have the AVR generate waveforms
>for a DAC and it would have an id. Then ASM could call the memory
>expander and the sound, even if both are plugged in. If a shell or a
>library were to have all the ids, and link port use run through it, you
>could create a VERY awesome serial bus option!!!

"8bit I/O expander"- Grant (he's the guy who makes everyone on ti-hardware sick)

It only takes 8bits of I/O to interface with a dac.