[Coco] CocoFlash Updates

[Gene Heskett]

On Saturday 17 September 2016 23:44:15 RETRO Innovations wrote:

> On 9/12/2016 12:25 PM, RETRO Innovations wrote:
> > http://www.go4retro.com/projects/cocoflash/
> >
> >
> > With apologies to Zippster, but in July or so, Barry asked if I
> > could squeeze the Orchestra 90 functionality into the CocoFlash, so
> > folks could assume some additional sound options for games and such.
> >
> > This Summer was hectic, but I was able to do so, and the
> > conversation in the list around the circuitry was very enlightening.
> >  The Orch90 functionality analog section is the top right of the
> > cart, the R2R ladders are most prominent.  I used discrete resistors
> > since I helped with layout and I could get the wattage rating I
> > wanted more easily and more cheaply.
> >
> > In any event, the (hopefully) finished cart design is shown above.
> > (The wire is due to a trace issue caused by some debugging efforts).
> > I have verified the sound waveform matches the OR90 output, but has
> > a but more Vp-p, since I opted for some newer ABT-family latches,
> > which drive to the rails a bit better.
> >
> > When I get some time, I'll put some more information on the design
> > on the web page, but feel free to ask questions if desired.
> >
> > Jim
>
> Kudos to Barry, as he found a bug in my CocoFLASH Verilog, (writes to
> ff7a were mirroring to $ff5a, which is where the bank register is
> located, which meant songs were flipping the bank register all the
> time and causing crashes).
>
> Luckily, I had put some code into the unit to "move" the base address
> of the registers, so Barry was able to move it to $ff50, which does
> not conflict (until I can get the new code to him)
>
> Does anyone know of a single address in the $ff40-$7f space that is
> not used by anything?  I assume not, but thought I would check.
>
> Jim

Because most address decoding in the carts we have, are in 4 byte wide 
bits, no one has put anything at $FF7C-D-E because $FF7F is the 
multipack slot register. I have not verified the MPI's response to the 
C-D-E address myself, but if you only need one byte wide, I expect a 
little wrapping wire patch to your decoding could test it.

I have lamented for at least 25 years because someone hasn't made a one 
chip addin board for the coco itself, restricting the address space used 
by the PIA's to the 4 byte wide access they need, which would free up 7, 
4 byte wide addresses from $FF04-FF1F, and 7 more 4 byte wide blocks 
from $FF24-FF3F. Thats 14 more 4 byte wide devices we could address in 
those two spaces. A single 74ALS138 could manage that easily with one 
trace cut, two connections to the power rails, a bit of wirewrapping 
wire to put the 74ALS138 output into the CS logic of the 74LS138 in 
there now. Feed this '138 with A2 and A3 so that if either is true, the 
internal ls138 is disabled. This I repeat, would give us 14 more usable 
address blocks for a total of 21, as opposed to the 7 spaces we have 
now.

This is so simple it could even be done with a 74ALS02, a NOR gate IIRC, 
so that the internal 138 is disabled if either A2 or A3 was a logic one.  
With the ALS version of the added logic, the desired CS for the internal 
138 would be delayed perhaps 5 to 10 nanoseconds, and to the coco, any 
version, thats a never mind, it won't know its there. But those 2 PIA's, 
using a $20 byte wide access each, would disappear except at their 
assigned addresses, $FF00-03 and $FF20-23.

I'd think the majority of us long time coco hackers could install such a 
kit in less than an hour.  For those that aren't equiped with a decent 
soldering iron, Mark, Jim, heck any one of you that are doing this new 
stuff right now, could offer the installation service and make some beer 
money doing it. So why hasn't it happened?  Do it, that would triple the 
external, usable for "whatever" i/o address space on the coco3. it could 
even be done dead bug style, no pcb involved.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>