Bytesaver, block move program & BASIC-5

[Hugo Holden]

The 2708 UV EPROMS finally arrived in the post from Germany. I got the Bytesaver up and running with Processor Technology's BASIC/5 in PROMS.

The BASIC/5 program was broken up and placed in seven PROMs using the Eberhard Bytesave program, leaving the 8th PROM free for something else.

There was enough room in the 7th PROM to fit a block move program starting at 7A00h. The whole thing works very well.

The Bytesaver board address starts at 6000h and extends to 7FFFh and my 48k of RAM has a modified address decoder to deactivate it over this range.

In the SOL-20 I just have to type EX 7A00, and the mover program comes up with on screen information and explains that it is moving BASIC from address 6000H (starting in the ROMS), to address 0000h in RAM and reports when it has finished.

I labelled the PROMs with transparent sticky labels from a label machine, over the light occlusive aluminium foil (builders tape) so there is no confusion and noted that the Mover program is in ROM 7 with its address at 7A00h with a black label with white writing on the IC body.

So if somebody finds this board in the future they will figure out how to get it working.

(Most ROMS on vintage boards never seem to be labelled properly, if at all, and they might have all sorts of goodies hiding in them, so it is probably better to label them well).

 

[Hugo Holden]

There was a question I was meaning to ask:

When the file for each 2708 ROM was loaded into the buffer, prior to programming, it reported a checksum value as a byte. So I kept a record of it or each ROM.

Would it be worth adding this byte value to each of the ROMs as a sticker, so if ROM rot developed many years later, and the file checksum changes, somebody would be able to detect that. Or, would it still be possible somewhere in the file, for a byte to change without the checksum changing or say one or more bytes changing without the checksum changing ? In other words how good is the checksum value in detecting a corrupted/changed file ?

 

[deramp5113]

Good looking job! A checksum won't catch every error, of course, but it wouldn't hurt to put it on there if there's room. If someone still can't get it to run they can always run a compare to the original file.

MIke

 

[dfnr2]

The restoration looks great!

A 1-byte checksum is just a modulo 256 sum of all the bytes in the ROM. If you want to store it in the ROM, then you have to find an unused location with a zero, and them omit that location when you check the sum later. Or, store the 2's complement in an unused location containing a zero, and you can check that the total checksum for the ROM is zero.

The problem with a 1-byte checksum is, as you guessed, that multiple errors can cancel out. The problem with a checksum on a ROM is that there are realistic ways this could happen, because of the ROM architecture. For example, bit zero could be stuck to "1" over a zeroed-out 256-byte block (or multiple of 256), and the checksum would not change. For higher bits, the block size would be correspondingly smaller. For example, bit 7 flipped on any even number of bytes.

If you would like to add your own consistency check, a 32-bit CRC would provide an excellent integrity check. You could run the CRC over the whole ROM (except for 4 bytes), then stick the CRC in the remaining 4 bytes. Then, running the CRC over the whole ROM should be zero. A 16-bit CRC would still be pretty good, and even an 8-bit CRC over a 2k EPROM, while slightly more risky for a false passing result, would not be as susceptible to bulk failure patterns, but would require a less likely distribution of errors to fail.

Dave