ZBasic Forum

Version 1.1.0 of the VM has experimental support for non-standard EEPROMs. A standard EEPROM, like the AT25256A, has 64-byte pages, is byte-writable and is capable of running at 7.5MHz. Non-standard EEPROMs with a different page size or which must be written a page at a time are supported by re-configuring the device using the ZLoad utility. The procedure is documented in the updated ZBasic Reference manual. Currently, slower EEPROMs are not supported.

Note that using a "page mode only" EEPROM still allows PutEEPROM to function correctly as well as writeable Program Memory data items. This is accomplished by temporarily allocating a page-sized buffer from the system memory pool to use for a read-modify-write operation. After the operation is complete, the buffer is returned to system memory pool. If a buffer cannot be allocated, the write will not be performed, i.e. it will fail silently.

There has been some discussion about providing a System Library routine to pre-allocate a page buffer for the read-modify-write operation so that it would be guaranteed to succeed. This has not yet been implemented and I would invite comment on this issue.

Note that during download, pages are filled and written as the device receives data from the host. At the end of the download, if a page is partially filled the remainder is filled with &Hff. Because of nature of this "streaming" process, download images that do not begin on a page boundary or that are discontiguous will not load properly. The compiler will always generate download images that begin at zero and are contiguous so this is only an issue for download images generated by other means or modified after generation.

I don't think silent failures are an option. I prefer the pre-allocation of a buffer solution. Worst case a ZX register needs to be set in EEPROM if there is a failure. But then there is still no information on which write failed.

Although support for larger EEPROMs would be nice, the whole page-oriented mechanism for writes can get messy very quickly. The implementation has to ensure that a dirty page is written back before new page can be loaded for a read-modify operation.

This problem together with the other restrictions probably makes support for larger EEPROMs more trouble than it is worth.

The implementation has to ensure that a dirty page is written back before new page can be loaded for a read-modify operation.

The page buffer is not used like a cache. Rather, when PutEEPROM is called, if the device is configured for page mode the page is read, modified and written back immediately.

Also, until a provision is added for pre-allocating the page buffer, failure can be detected by reading back the data and comparing it with what was written. By way of comparison, the BX series does not support writing to the EEPROM at all with the 25HP512.