Any recommendations on where to post updates? Should I just start a new thread here? Or start a thread in the Slabtop Computers Discord server?
Here’s a quick update: The boot ROM disassembled nicely in Ghidra. It was handy labeling each part of the memory and I/O maps with their function, and using the FDC and CRTC controller’s datasheets to resolve exactly what is done when certain registers are read or written with specific data. I’m still working off a lot of assumptions, and many of the labels I’ve appended are educated guesses at best. The ROM routine initializes some hardware and zeros out and sets up some data in RAM2, then it copies a decent section of data to RAM2. This data is actually program code, and once it’s copied to RAM, the program jumps to run it. One of the first things the program in RAM2 does is hit the bank select register so ROM is no longer in the picture, and RAM1 is swapped into its place in the memory map. From here on out, the system is running code from RAM. Easy for us to modify with our own code running from a custom boot disk! I identified the routine which reads 256 bytes of data contained in sector 1 of track 0. That sector contains the IPL for the system. According to the spreadsheet in Steve Adolph’s files, the first 128 bytes of that sector contain disk basic IPL, and the second 128 bytes contains DOS IPL. I’m in total agreement with that assessment. Once sector 1 is read and stored into RAM, the system checks to see that this is indeed a valid boot sector by comparing the last byte of the data read from the sector to 0x4b. Prior to reading the disk, that location in memory is either 0 or uninitialized. Once a proper boot disk sector 1 is read, that location in memory will contain 0x4b. Once this is true, the system jumps to run the code which came from the second 128 bytes of the boot disk sector 1, which is the DOS IPL. I copied the sector 1 bytes from the DAT files extracted from the disk image by Steve Adolph (disk basic IPL + DOS IPL) into memory in Ghidra at the correct location, and it disassembled the DOS IPL! After that, I needed a little break. I’ll get back to it soon. I identified routines which display text on the screen prompting the user to insert a disk, and also found routines to display the various error conditions such as a non system disk inserted, drive didn’t seek to track 0, no index pulse, etc. Returning from a CALL with the carry flag set appears to indicate a failure of the process for drive control or disk reading. There are a number of various pointers in RAM which are modified to contain different addresses based on certain conditions, and there are even small portions of self modifying code, actually changing an upcoming instruction based on certain conditions. The engineers took full advantage of the code running from RAM. It’s a lot for me to follow. I’m not sure I’m experienced enough to be “the” person attempting to disassemble and make modifications to the code, but I’m certainly capable of learning. Is there a good place for me to share the Ghidra files for others to poke around to learn or assist? I’m a noobie with git (and Z80 code), but I’m not so embarrassed by my inexperience to shy away from sharing my work. Royce Sent from my iPhone > On Oct 28, 2024, at 18:23, RETRO Innovations <[email protected]> wrote: > On 10/26/2024 5:27 PM, Royce Taft wrote: >> Along the same line, I’ve been thinking of reverse engineering the >> DVI’s firmware (BIOS) and software (DOS which is loaded into RAM by >> the BIOS) to the extent that it could be modified to utilize the >> second side of a disk once the drive is changed out for a double sided >> one. >> >> I’m fairly certain that the side select signal on the floppy interface >> is connected to a latch IC used for various system controls. If that’s >> the case, the single sided drive limitation is one of >> firmware/software, not hardware (besides the disk drive itself). I say >> I’m only fairly certain since the schematic is very difficult to read. >> >> The scan of the service manual floating around in various repositories >> is not exactly high resolution, which makes the schematics practically >> illegible. There is a user in the Tandy discord who is planning on >> scanning the schematics from their copy of the service manual this >> weekend. >> >> It would be a fun project to gain a little more exposure to Ghidra, >> especially with “overlays” in the memory map such as the memory >> banking scheme used by the DVI and the region of RAM which will >> contain DOS once the disk is read at boot. > > Is there a place to stay up to date? After showing my DVI at Tandy > Assembly this year and playing with it a bit, I'd really like to better > understand the HW (maybe reverse engineering the schematic, etc.) and > I'd love to keep updated on this effort. > > Jim
