[Coco] "super" ROM pak??

[Chad H]

Thanks for reminding me about the HALT line use.  However, even if I did that, I would still need to reset the coco anyways so not sure I see a point in trying to have the microcontroller trying to access the SRAM while the CoCo is powered.   I was thinking of designing it to force that behavior for simplicity and to avoid conflicts with the 6809, so the SRAM is never accessed by both at the same time.   The atmega will refuse to access it when the coco is powered.

I think your chip is a square SMD type that might be akin to failing horribly at a game of "Operation" for me.  I'm looking at a SRAM 28 pin package that's 28256 pin compatible and has 32k.  I will need to flip the A14 and WE lines for my 27256 EPROM pattern but should work well.   I'm going to be looking at putting all of this in a metal or plastic cartridge housing as well.  If I make good progress I'll put up YouTube updates.  I'm sure I could use some help along the way and others may want one, never know.

Thanks!

Sent from my ASUS Infinity

On Aug 31, 2014 8:14 AM, Matthew Stock <stock at bexkat.com> wrote:
Hi Chad and Sylvain,

The docs for the version in that video aren't readily accessible, but you
can take a look at the v1.2 edition materials at
https://github.com/mattstock/cococpld/tree/v1.2.  A pdf of the schematic is
http://www.bexkat.com/coco/Coco%20Bus%20Interface%20v1.2.pdf.  The main
functional difference is that I shifted things to overlap more with the
Arduino Mega so that I could get access to a few more pins.  For a ROM-only
setup you don't need that, and in hindsight I would probably make a few
changes to simplify.

If I were doing a ROM-only design now, I'd look at using one signal line
from the Arduino to take over the bus by asserting Coco HALT.  I think you
could avoid the 74LVC16245s completely if you do it that way.  If not,
you'll want to buffer all of the data and address lines coming from the
Coco so that you can interact with the memory properly.  On the Arduino
side, you can use a set of shift register chips to latch all of the address
bits.  If you have enough pins on your MCU, it's convenient to connect data
lines directly (easy to read and write).  So the process would be HALT the
Coco, program the memory from the Ardunio, and de-assert HALT and hit the
reset button.

You would also need to think about how to share the chip select for the
memory between the Arduino and the Coco - normally it would be tied to CTS
on the Coco side, but when in programming mode it would always be asserted.

If you want the ROM to be persistent I'd suggest something like the AT28HC256,
but you'll need to spend a little more time figuring out the Arduino code
to do the programming.  The board I have up at the top uses it, and so the
programming code is there.  The main thing is you need to erase before
reprogramming.  You could also use SRAM.

On the Arduino side, I think you might run into problems with the Atmega328
due to limited memory.  The FAT microsd libraries take up a fair bit of
space.  That's one of the reasons I went to the Arduino MEGA board (plus
more pins).
Good luck,
  -Matt

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco