by Richard F. Drushel (drushel@apk.net)
In TWWMCA 0008.20, I described a 3-byte binary patch for SmartFiler, to enable it to function correctly under ADAMserve. (Prior to this patch, SmartFiler would hang ADAMserve when trying to read an existing database, necessitating a hard reboot of the ADAM client to clear the error.) The Address Book program, a phone number database for use with the Autodialer sideport expansion module (it uses pulse dialing), also hangs under ADAMserve. Since both SmartFiler and Address Book have similar database interfaces (and indeed, SmartFiler can read Address Book databases), I hypothesized that both programs shared the same core database code, and thus might share the same bug.
I'm happy to report that my hypothesis is correct: Address Book and SmartFiler share large blocks of identical code (though assembled at different addresses), and the same kind of patch fixes both of them under ADAMserve.
In brief, the "bug" is a single CALL _START_RD_1_BLOCK instruction which is used to force a rewind of the program tape if you bought the software on tape. ADAMserve's imperfect emulation of ADAMnet devices does not work at the low level of _START_RD_1_BLOCK, so instead of routing the read request to the ADAMserve serial line, it tries to read from the real ADAMnet device for tape 2. Naturally, nothing is there, and the application program does not have any error handler, so the program hangs. The "patch" is to replace the 3-byte CALL with 3 NOP (No Operation) instructions. The only downside to this patch is that the patched software, if run from a real tape drive, will not automatically rewind to the beginning after I/O is complete, so the next time the program tries to read the directory, you have to wait for it to rewind back to block 1.
Here are detailed instructions for patching Address Book under ADAMserve. Note that your Volume 0 might be organized slightly differently than mine; so be sure to verify the start block of the Address Book application *before* you make any changes.
run ADAMserve File Manager
Edit Catalog to find the entry for ADDRESS_BK
on my system, it starts at block 585; yours might vary
go to Media Functions/Edit Blocks
select the *1st* block of ADDRESS_BK (on my system, it's 585)
go to sector 6 (by hitting HOME+down arrow to page through the sectors)
byte offset 715 decimal, you should see the following 3 bytes in hex: CD A2 FC
change these 3 bytes to: 00 00 00
hit return and save the changes
Shift-Undo to return to HARDDISK
boot SmartFiler as usual from hard disk
I further hypothesize that the same kind of patch will be necessary for Recipe Filer. I will investigate this some time soon.
One annoying feature of SmartFiler, as it had been patched to run from the EOS partition of hard drive systems, was that it was impossible to create new databases; you could only read existing databases. I had always assumed that this inability was some kind of "safety" feature, since SmartFiler insists that the database occupy the entire disk or tape, and in the case of a hard drive system, this would mean an entire 1K volume. Since the hard drive version of SmartFiler was put into Volume 0, and this is the boot volume, inadvertently destroying it would be a major disaster. ADAMserve, being based upon the standard EOS hard drive organization, also shared this limitation.
Since the EOS hard drive under ADAMserve is just a 10MB MS-DOS file, however, it's easy to make a backup copy of a working hard drive image (I use PKZIP 2.04g), and then play around--if it gets destroyed, just unZIP the backup and start over. Looking through the directory listing of Volume 0, and comparing it to a directory listing of an original SmartFiler disk, I observed that Volume 0 was a missing file, TDS_MAP. (It's actually TDS_MA with P in the filetype byte). So, I copied it from the SmartFiler floppy to Volume 0 using File Manager, launched SmartFiler, and tried to create a new database on a blank, ADAM-formatted 160K floppy. It worked! I then tried to create a new database on DRIVE B (which is the device mapped to the ADAMserve hard drive). I got an error message which said that there were permanent files which could not be deleted to make room for a new database. Hooray, no chance to accidentally wipe out Volume 0, because there are a number of hidden and system files there. What about a disk/tape with existing user files? I tried another floppy with some SmartBASIC files on it, all A-type: SmartFiler told me that it would have to delete the files to create a new database, did I really want to? Again, a safety net to protect against accidental erasure!
So, I conclude that it's safe for hard drive systems to put the file TDS_MAP back into Volume 0. Maybe it was left out by accident, instead of as a precaution; I don't know.
Clearly TDS_MAP was some kind of code overlay. I was curious about what it does. I went back to my SmartFiler disassembly listing (still in progress) and traced out all the code which dealt with TDS_MAP. It turned out that all the SmartKey menus dealing with database creation had their executable code in an address space that was *outside* that of the 33K SMARTFILER file, and *inside* the address space where TDS_MAP gets loaded (A800H-BFFFH). Indeed, attempting to create a database causes SmartFiler to try to load TDS_MAP, and if it can't find the file, it aborts.
TDS_MAP is only 6K long, so it was pretty simple to generate a resolved disassembly listing using methods I have described previously (e.g., TWWMCA 9701.19). Aside from some garbage at the very end, TDS_MAP is mostly code with a few vector and data tables. It makes a few references to addresses in the SMARTFILER file address space, however, so any changes to SMARTFILER's memory map must be propagated through to TDS_MAP.
Address Book does not use an external overlay file (another possible reason why TDS_MAP might have been left out; what if both programs had an overlay named TDS_MAP and they were different binaries?), so after the 3-byte patch described above, it is able to successfully create new databases under ADAMserve.
In order to trace out the SmartKey entry points into the TDS_MAP code, I had to figure out the data structures used to create SmartKey menus in SmartFiler. While somewhat complicated, this code shows one possible way to use SmartKey menus in Z80 assembly language programs for the ADAM. It might even be extracted as a single library module, to save future programmers the (serious) trouble of writing SmartKey menu-driven applications.
See you next week!
*Rich*