[Coco] Christmas Wish Device

[Mark McDougall]

On 8/12/2011 4:19 AM, Robert Hermanek wrote:

> love something simpler, just a RAM cartridge.
>
> I'd like a cart that I can plug in, then plug flash memory into the cart,
> then access the flash memory as RAM via a few I/O registers.  In my mind
> the simplest thing would be setting an "address" using 4 bytes giving
> access to a 32 bit space, then when the "address" registers are set,
> either writing to the flash by setting a "value" register, or else
> reading the current value at your chosen address by reading the "value"
> register.

I designed a flash cartridge some time back, but stuffed up, not realising 
that the CART# signal (which decodes the address lines) isn't asserted on 
writes.

This meant that, without some magic, I couldn't program the flash from the 
Coco. I did have some ideas on how to circumvent that with the current 
design, but haven't done anything with it since, at the time, I didn't have 
an MPI so developing programming code - with the flash cart plugged in - 
meant I had nowhere to save it. Perhaps now that I have an MPI I should 
revisit it.

Or maybe just re-spin the PCB without these problems...

> And that's it.  I could plug a 1 gig CF or SD card into this thing and
> have all the "RAM" I could ever want.

This is a different kettle of fish, and is more complicated. You describe a 
memory device in the first instance, and substitute it with a secondary 
storage device in the second. Particularly in the case of SD, that's more 
hardware required to interface than a simple bus adapter.

Having said that, technically IDE (CF) is nothing more than a memory-mapped 
device anyway. The IDE registers are pretty much exactly as you describe, 
the only difference being that the 'memory' isn't available for random 
access on a bus like a memory block would be; you have to read it serially 
via a FIFO.

And this raises a point; using a secondary storage device would require 
caching in memory if you want to be able to access a block of memory, since 
you must meet bus timings for the 'memory' access. So you'd need a 
controller on the cart which read sectors into 'cart memory'... but this 
isn't really any different to what a stock Coco can do with a SuperIDE... so 
what's the point (except performance)?

> It would be much more fun
> to be able to just set the "address" registers and access the flash card
> as a continuous block of memory...  and it wouldn't even have to be
> flash, since that's persistent--maybe some kind of true RAM chips in the
> cart would be better?

It would be trivial to implement with SRAM and a small CPLD. The main issue 
is where to map the bank registers, as they - and the other memory-mapped 
addresses on the Coco3 (GIME etc) - would impinge on your memory address 
space. Also, annoyingly, with the CART# not driven during writes, you need 
enough address pins on your CPLD to decode the banking register addresses 
(ie most of them) which increases the size (and complexity and cost) of the 
CPLD. Something I discovered too late. :(

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"