[Coco] Superboard discussion: Serial EEPROM

[Boisy G. Pitre]

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
> items."

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 
> "preferred
> resolution" (for those programs with an option). I was thinking of 
> maybe
> storing some small TSR type ML routines there, like a HiRes joystick 
> routine
> loaded by whatever program needs it. Here's a thought... alarm clock 
> data!

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

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