[Coco] 512K EEPROM Pak: Unlimited? .BIN size - DONE!, PAUSE ability - DONE!

[Chad H]

After spending most of the weekend and a few hours today trying to get the
.ASM code straight, the Arduino coding made sane, and Multi-Bank ROM Builder
tool byte aligned with the 8K boundaries I FINALLY was able to store .BIN
files into the 28SF40 (512K) EEPROM and they boot and play perfectly! J

 

Some .BIN's tested (on a CoCo2 AND a CoCo 3 include.

.         FLTSIM1.BIN  15K (2 segments)

.         ASSAULT.BIN   5K  (1 segment)

.         ZAXXON.BIN  17K (3 segments)

.         BAGITMAN.BIN 24K (3 segments)

.         MONOPOLY.BIN 23K (3 segments)

 

I also have as part of the 23 program test collection (a little over half
filled chip), DONKEY.BIN which only comes up with a solid blue screen for
some reason on both my CoCo 2 (64K) and my CoCo 3 (128K).  Not sure what the
deal is with that.  Going to have to copy the .BIN to a .DSK image and try
loading it that way later for comparison.  Perhaps it requires 512K CoCo 3?
If anyone could shed some light on the requirements of this file I would
appreciate the info.

 

The .BIN loading is accomplished by utilization of a 72 byte assembly loader
at the beginning of each 8K segment of the program.  By keeping it
restricted to 8K ($C000-$DFFF) I am maintain compatibility with the CoCo 3's
ROM space . The 72 byte loader ALWAYS exists (copy) at the beginning of each
8K segment to maintain persistence of the loader code.   I had originally
planned on putting a byte 'marker' at the beginning of each segment (FCB)
that would be incremented for each segment so the loader could identify
which segment the microcontroller had 'bumped' up to.  This was causing a
lot of problems so I decided to relocate the marker to the END of the 8K
segment at $DFFF. 

 

The loader begins with Segment 0, reading immediately after itself at byte
73 and continues till $DFFE (1 byte before the identity byte(0)) where it
trips the SCS line which causes the microcontroller to 'bump' to the next 8K
segment.  The 'bumping' is accomplished by decrementing the control byte
that is sent to the 74HC595 shift register.  Each bit in the control byte
represents whether a address line is asserted LOW (1) or left alone (10K
pullup to HIGH).  **A13, A14, A15, A16, A17, A18, A13H, A14H (last 2 bits
are for 16K/32K contiguous .ROM banks ** Because the 72 byte loader remains
in the exact same position, unmodified, in each segment, the loader
continues without any issues.  If for some reason it doesn't see the
expected byte identifier at $DFFF then it bumps the SCS again until it does.
It then resumes the .BIN data loading, which is placed  immediately
following the 72 byte loader code in  the segment.

 

In theory, we SHOULD be able to load any .BIN that will run on a CoCo in
this fashion, so long as the .BIN doesn't itself try to load into the 8K
cartridge space or something else weird.  I suspect this sort of behavior
would also conflict with floppy controller ROM's and therefore shouldn't
occur.

 

Unfortunately, there was a minor design hic-cup with the controller PCB's
which required me to cut a couple of traces and jumper another in order to
get the PAUSE button working.   Yes, I can press the 'PAUSE' button and I
get a flashing message on the LCD saying "PAUSE" while the HALT is asserted.
Nice to be able to pause the CoCo at ANY time J   The EEPROM boards
themselves are flawless and the 74HC595 / ULN2803 combo works very well for
address line control.

 

I will be updating my site soon with further information, the updated
Multi-ROM Builder Tool, and a video of the final setup in action.  I will
also do a full walkthrough in the video on how easy it is to take a bunch of
.ROMs (and/or .BINs) and combine them into  one single .ROM for flashing
using the tool I made.  The same tool exports a section of Arduino code that
can be copied into my sketch and re-flashed to the Atmega328 controller
quickly and easily.   This way, All the configuration, combining, padding,
math, etc. is handled for you.   It takes longer to browse and find all the
individual .ROM/.BIN files to include than it does to build the .ROM and
flash the updates.  Once you have a chip layed out, you can SAVE that layout
for later loading/editing in order to reflash a similar setup.

 

I think this is going to be as far as I'm going to take my expansion Mark
Blair's original design (http://www.nf6x.net/2013/10/cocoeprompak/) from
which I began with this over a year ago.  Before I started tinkering with
his .PCB design in Eagle, I had never touched anything to do with PCB design
at all.  This sparked other projects which I will shift more attention back
to and finish them up now that this one is completed.   I did find a 4MB
Parallel EEPROM I thought for a bit about expanding this further to.
MX29L3211.  However, this chip adds 3 more address lines, is only 3.3V and,
according to the data sheet, seems to have a quirky way of 'flipping'  a A-1
line every other byte in 8bit mode, which seems to me to be interlacing the
memory.  If this is true, I would have to almost start from scratch on
everything in order to handle the interlacing/deinterlacing.   There are
larger capacity EEPROMs in serial interface format but I'm not at the level
of experience yet to attach one to some sort of 'converter' chip that will
feed the ROM data to the CoCo parallel bus..oh well.

 

- Chad H

http://sites.google.com/site/cbhlab101/