[Coco] Superboard discussion: Serial EEPROM
Boisy G. Pitre
boisy at boisypitre.com
Sat Apr 24 07:47:40 EDT 2004
On Apr 24, 2004, at 1:36 AM, Bob wrote:
> I'd like to know if there are any "standards" in mind for this:
> "Serial EEPROM: 512 bytes of serial EEPROM will be available to both
> OS-9 and
> BASIC users. This device can be used to store configuration
> information about
> the system such as RGB or CMP monitor, slow or fast speed, and
> numerous other
There is a preliminary break-down of the storage contents of the Serial
EEPROM in the SuperBoard. I had a preliminary sketch of how this would
look in my mind... essentially the first 256 bytes are devoted to Disk
BASIC and the second 256 bytes are devoted to NitrOS-9.
Some of the information in the first 256 bytes is taken up by the VROM
feature of the SuperBoard. Specifically, there are eight 8 byte label
areas for a total of 64 bytes. These are used to label the 8 banks of
VROM. Another byte holds the default VROM to startup in. Yet another
byte holds bits about the state of startup (hi speed mode, etc.).
The plan is to keep some of the space open for "user-defined" use.
> Whether there are or not, I'd say now is the time to discuss and
> develop them,
> so that those of us still programming can think about taking advantage
> of them.
> I wouldn't even be opposed to "re-engineering" some older software to
> use this
> information, IF we set "standards".
Sure. I'm not at all opposed to nailing down a more perfect format for
the 512 bytes. Let's talk about them.
> Of course, the monitor type is a perfect candidate, perhaps add
> resolution" (for those programs with an option). I was thinking of
> storing some small TSR type ML routines there, like a HiRes joystick
> loaded by whatever program needs it. Here's a thought... alarm clock
I think TSRs would be better suited in ROM, due to the way serial
eeprom data is accessed. With VROM, you have the ability to burn your
own ROM anyways, and even bank switch to another ROM to do more neat
> So, how is this data accessed? What other ideas can we coco-nuts come
> up with
> for it's use?
I'm proposing an assembly language routine that will be in unused
portions of the BASIC ROM. One call will write a byte to a location,
another call will read a byte from a location. I wanted to use the
DEFUSR/USRX calls, but in the case of writing, two parameters need to
be passed (the location and the byte) and I don't believe the USRX
calls take more than one parameter. Anybody know?
Worst case: you will have to POKE/PEEK some values into RAM and then
EXEC into the read/write routine.
Bob thanks for taking the initiative on this. Please feel free to
submit a byte-by-byte (and bit-by-bit) outline and we can hash it out
via this medium.
More information about the Coco