Q: Can I destroy my rex by messing with the firmware?
Very unlikely. The Rex firmware has a crucial 8k area that handles downloads of firmware and any standard download of firmware cannot overwrite this 8k space. Hence the Rex will be restorable by downloading the original Rex.bin again.

Note however that C. Harris believes that using a separate and obscure method it is possible to overwrite this 8k.

Q: How can I examine the firmware?
You can view this through the Rex serial diagnostic but for some reason (simplicity?), they offset the page numbers by 4, so you have to mentally add 4 to the real page numbers, as used in Rex firmware. Format of command is: dump PPPP NNNN (where PPPP is page number in 4 UPPERCASE hex digits), and NNNN is the offset in that page - but not 0x8000-based.

Q: How do addresses in RexMap with the corresponding S-records in Rex.bin?
There are 2 issues here:
1. Each row of the firmware map in RexMap is referring to an 8KB block of code/data. On the left are 3 columns (Physical, Dg, and Pg) referring to the START address of that 8KB block; on the right (the Description column) I list references within that 8KB block, but here's the trick: only the first 4 blocks in the list (0000-7FFF) use the obvious absolute address.

>>> ALL of the remaining blocks are RELATIVE to an origin of 0x8000, not the absolute address at the beginning of the row. <<<

So, to address the example you cited, I list "8AF8: software keyboard...". Take this relative address and subtract 0x8000: 8AF8 - 8000 = 0AF8, the offset into the 8KB block.

Now take the physical address in the first column: 0002:2000, and add the above offset to the low 16 bits: 2000 + 0AF8 = 2AF8. This, prefixed with the low byte of the page (02) gives the three byte address: 02 2A F8. You may search for this address in Rex.bin directly, and in this case the search would be successful, as the S-record happens to be aligned with exactly this address, but often it isn't, which leads us to the next issue:

2. For some unknown reason, the records in Rex.bin are in a rather random order, and S-records containing consecutive blocks of code are often interrupted by other unrelated S-records. This is the main reason I did not attempt to cross-reference the information I list in RexMap with the containing S-records in Rex.bin: it would be a mess!

The only really consistent pattern is that the majority of S-records are of size 0x14, containing 16 bytes of data, and are predominantly aligned on 16 byte boundaries. So, if the above method fails, simply "backup" to the previous 16 byte boundary address (PP XX X0) and search again.

Q: Can the DS2 become a Rex6000 or vice-versa?
a) Loading the Rex firmware on a DS2. This could give us a new hardware source, whilst Citizen continue the DS2 product line.

C. Harris writes "I helped a gentleman in Hungary convert his DS2 to a Rex 6000. The only tricky part has been loading the boot sector (first 8KB of flash memory). I have successfully swapped between the Rex and DS2 boot sectors on my Rex using a little addin - but if something goes wrong, your Rex/DS2 is toast, as we don't know how they write the boot sector (on a "bare" Rex/DS2) at the factory. "

b) Loading the DS2 firmware on a Rex, to take advantage of the faster DS2 logic, and "missing" features, like Task categories, etc. I'm assuming we would modify it to suit English speakers.

C.Harris writes "I have loaded two different "builds" of DS2 firmware on my Rex: one as derived from the code packaged with the DS2 emulator, and one as extracted from Liam's DS2. Both booted up and operated reasonably, with the big exception of fonts: they aren't there! Unlike the Rex, which has the fonts right in the 1MB contiguous firmware, the DS2 has the Japanese and one English font located at the end of the dictionary. At least, that's where I found them in the DICT1.DAT file provided with the DS2 emulator. This is a 4 MB file, entirely empty except for the font bitmaps in the last 180KB or so."

Q: How are events stored?
The event definitions are stored in memory starting at C386h. Each structure has 7 bytes: id, x, y, width, height, enabled, special-flag.