[Coco] "super" ROM pak??

[Luis Antoniosi (CoCoDemus)]

Just a not. You need to power off your coco. Some carts will only start
from cold boot, not warm.

Unless you halt the cpu, slenb and set write to 113 address to 0.

Which makes things much more complicated as you need bi-directional
buffers, etc.


Luis Felipe Antoniosi




On Sun, Aug 31, 2014 at 10:32 AM, Chad H <chadbh74 at hotmail.com> wrote:

> 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
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>