[Coco] "super" ROM pak??

[Retro Canada]

to power the board from the coco you need a flip flop set in low for the halt and once the microcontroller starts and load the pak, set it to high to resume.

On Aug 31, 2014, at 1:29 PM, Chad H <chadbh74 at hotmail.com> wrote:

This is not a relevant issue at all if the CPU is the only thing accessing
the SRAM while the CoCo is powered.
As far as I can tell, the only reason to even buffer the data or control the
CPU HALT would be if the microcontroller was trying to access the SRAM at
the same time as the CoCo CPU.  This would not be happening if I designed it
to run off of a external power source and it refused to do anything while it
was inserted into the cart port of a powered CoCo.  On the other hand, if I
was trying to eliminate the external power source and make the entire cart
bus powered, I would have to perform the access management to prevent chaos.
Perhaps I will investigate the HALT option more since it seems fairly
simply.  You just pull it high to +5VDC to trigger and leave it disconnected
otherwise? 

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Luis Antoniosi
(CoCoDemus)
Sent: Sunday, August 31, 2014 10:14 AM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] "super" ROM pak??

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

--
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