Writing to CoCoIOr
Some details of my messing around with the CoCoIOr EEPROM (ROM) on a CoCo2. We are almost certainly doing it wrong, this is simply what I've run across playing with the new hardware.
A simple boot ROM is the obvious use, so we grabbed the trusty TL866, flashed disk basic on a CoCoIOr and booted every thing in every way - CoCo2, CoCo3, with MPI, bare... The CoCo3 adds an extra layer of complexity thanks to it's ROM2RAM boot process, but at this level it doesn't matter. Once programmed, easy to boot from.
Write by CoCo is more complicated. Let's ignore CoCo3 until we figure that out and concentrate on the bare hardware, starting with the Atmel 28c64b EEPROM. It can do single byte writes or 64 byte pages. There is 200ms of dead space after each write, so aligned pages usually win. But you can drop a few bytes at any random location without concern.
Our first wrinkle is the CoCo2, where the ROM(s) are an active part of the running code. Color Basic looks for an Extended ROM, which looks for another extension. As each one is found and executed, it puts vectors to the code it contains in Basic's jump table, sets up some data storage, and JSR, new extension loaded. We are at stage three, ECB is set up and is looking for an ascii 'DK' in the first 2 bytes of the disk ROM area. If found, execution jumps to the 3rd byte in our ROM. That code is expected to add entry vectors to ECB and return.
Now you've potentially got a network extension to ECB. Which means the ROM will be accessed regularly. With a longish 200ms dead (tristate) time after any write we make, Basic will occasionally not find the ROM and it will not wait, splat. So changing a live boot ROM is hard, mayube impossible in 16K. We'll have to adopt ROM2RAM for updates. At least the CoCo2 and 3 loaders will probably be related.
Note you don't have to do the Tandy. To abandon ECB, just use the 8k - 2 bytes to set up anything you want. Or don't start the ROM with 'DK' and Color Basic will ignore the space, it is now your private 8K of nonvolatile storage.
Which brings us to the Multipak. The MPI can select which slot to read ROMs from, but not write to. It doesn't allow writing at all! We can force it on, but there is no switch- the write hits all the slots at once.
Writes to a non-boot slot work. For example, boot SDC in slot 4, CoCoIOr in any other slot. Write away, it will be stored on the CoCoIO. After ROM2RAM or under OS9, you can 'slot switch' and verify the result. Inside DECB, you can't. The blind write wrote, but switching *CTS will crash the CoCo.
Next wrinkle, more than one CoCoIOr. There is a write protect jumper, but there also be users. To detect two writable slots active, I propose we overload that initial 'DK', so the start of a session might go something like this:
In the end, there are two types of user. I expect folks using this as a boot ROM will just set Read Only. Changing the boot is an event, with an offline updater to avoid these issues. Power users with an MPI full of stuff might want some fast storage - our own private Optane. If the card has been left open for user data storage, here are a few odd things to look out for.
Us. Some part of this ROM is going to be appropriated for network ID. Expect to loose a page from someplace (end?). To extend the overwrite prevention scheme, set the first two bytes ascii 'DT' = data so it's recovered cleanly if accidentally left writable when another slot was the target.
Dallas Smartwatch. Looks for a sequence of bytes written to ROM then dumps clock. So when the driver runs, it's going to cut short any page write in progress. Splat. Some of them only run at boot, even then the smartwatch will drop a few bytes of garbage someplace now and then. This area will need to be found and mapped out of any user storage.
Copy protected ROM games. A very few (SRB software?) games are rumored to try self-modification as copy protection. User won't associate a quick slot selected ROMPak game as dangerous to every other slot. Another thing that could be mapped out, if we knew where to avoid.
Anyway, it's been an interesting week. Advice welcome! More as soon as it happens.
PS: That EEPROM datasheet is here:
https://ww1.microchip.com/downloads/en/DeviceDoc/doc0270.pdf
A simple boot ROM is the obvious use, so we grabbed the trusty TL866, flashed disk basic on a CoCoIOr and booted every thing in every way - CoCo2, CoCo3, with MPI, bare... The CoCo3 adds an extra layer of complexity thanks to it's ROM2RAM boot process, but at this level it doesn't matter. Once programmed, easy to boot from.
Write by CoCo is more complicated. Let's ignore CoCo3 until we figure that out and concentrate on the bare hardware, starting with the Atmel 28c64b EEPROM. It can do single byte writes or 64 byte pages. There is 200ms of dead space after each write, so aligned pages usually win. But you can drop a few bytes at any random location without concern.
Our first wrinkle is the CoCo2, where the ROM(s) are an active part of the running code. Color Basic looks for an Extended ROM, which looks for another extension. As each one is found and executed, it puts vectors to the code it contains in Basic's jump table, sets up some data storage, and JSR, new extension loaded. We are at stage three, ECB is set up and is looking for an ascii 'DK' in the first 2 bytes of the disk ROM area. If found, execution jumps to the 3rd byte in our ROM. That code is expected to add entry vectors to ECB and return.
Now you've potentially got a network extension to ECB. Which means the ROM will be accessed regularly. With a longish 200ms dead (tristate) time after any write we make, Basic will occasionally not find the ROM and it will not wait, splat. So changing a live boot ROM is hard, mayube impossible in 16K. We'll have to adopt ROM2RAM for updates. At least the CoCo2 and 3 loaders will probably be related.
Note you don't have to do the Tandy. To abandon ECB, just use the 8k - 2 bytes to set up anything you want. Or don't start the ROM with 'DK' and Color Basic will ignore the space, it is now your private 8K of nonvolatile storage.
Which brings us to the Multipak. The MPI can select which slot to read ROMs from, but not write to. It doesn't allow writing at all! We can force it on, but there is no switch- the write hits all the slots at once.
Writes to a non-boot slot work. For example, boot SDC in slot 4, CoCoIOr in any other slot. Write away, it will be stored on the CoCoIO. After ROM2RAM or under OS9, you can 'slot switch' and verify the result. Inside DECB, you can't. The blind write wrote, but switching *CTS will crash the CoCo.
Next wrinkle, more than one CoCoIOr. There is a write protect jumper, but there also be users. To detect two writable slots active, I propose we overload that initial 'DK', so the start of a session might go something like this:
Note the first byte of each ROM.
Write ascii 'P' there. (PK = parked)
If only one of the 4 slots changed, restore first byte and succeed
else seeing multiple changes, write ascii 'D' to restore OS images to bootable
and then display the 4 initial bytes to user for manual restore
In the end, there are two types of user. I expect folks using this as a boot ROM will just set Read Only. Changing the boot is an event, with an offline updater to avoid these issues. Power users with an MPI full of stuff might want some fast storage - our own private Optane. If the card has been left open for user data storage, here are a few odd things to look out for.
Us. Some part of this ROM is going to be appropriated for network ID. Expect to loose a page from someplace (end?). To extend the overwrite prevention scheme, set the first two bytes ascii 'DT' = data so it's recovered cleanly if accidentally left writable when another slot was the target.
Dallas Smartwatch. Looks for a sequence of bytes written to ROM then dumps clock. So when the driver runs, it's going to cut short any page write in progress. Splat. Some of them only run at boot, even then the smartwatch will drop a few bytes of garbage someplace now and then. This area will need to be found and mapped out of any user storage.
Copy protected ROM games. A very few (SRB software?) games are rumored to try self-modification as copy protection. User won't associate a quick slot selected ROMPak game as dangerous to every other slot. Another thing that could be mapped out, if we knew where to avoid.
Anyway, it's been an interesting week. Advice welcome! More as soon as it happens.
PS: That EEPROM datasheet is here:
https://ww1.microchip.com/downloads/en/DeviceDoc/doc0270.pdf