Ahhhhhhhh!. I was expecting a hex dump and maybe a disassembly text output. Instead, I discovered the file (which I now understand) to be a disassembly tool project archive .
I tried all sorts of stuff to get to the contents including treating it as a ZIP file, which gave me some contexts, but nothing like what I was expecting. Looks like I need to find this Ghidra disassembler and start playing with it on my windows box. I wonder if IDA pro will read it? Thatks for the pointers. I'm sorry for my disparaging comment. I experience the same frustration when people use RAR files believing everybody has a paid WinRAR subscription when there are other archive formats that are open and I thought I was just dealing with yet another archive format. Doug On Sun, 15 Dec 2024, 6:00 pm RETRO Innovations, <[email protected]> wrote: > On 12/15/2024 12:30 AM, Doug Jackson wrote: > > I saw that, byt the owner doesn't want the archive opened - Its some > > sort of proprietary archive format. > > Hmm, the author of the files is on list (Royce Taft), and I'm sure that > was not his intent. From this list, 11/21/2024: > > > http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/2024-November/090131.html > > The list archive scrubbed the HTML, but I pasted the original text below > > The repo is mine, so if there's something Royce or I need to do so make > it more public, let one of us know > > ---------------------- > > If anyone tried to access the Ghidra disassembly files in Jim’s GitHub > repository and found that the project doesn’t load, please disregard > those files. The correct file has been uploaded which can be imported > (or “restored” as Ghidra puts it) into Ghidra 11.2 or higher to load a > snapshot of the disassembly thus far. > > > Even for the code I’ve stepped through and commented, I don’t have > everything figured out yet. I’ve got a handle on good portions of it up > to the DOS IPL which was loaded to RAM from the first sector. > > When the ROM copies data to RAM, I used the byte viewer tool in Ghidra > and manually copied the data into RAM at the appropriate location. From > there, I could continue the disassembly in RAM. I did the same for the > first sector of the boot disk. I used a separate hex editor to copy the > 256 bytes from sector 1 of the boot disk and pasted that into Ghidra’s > bytes viewer at the appropriate location in RAM. > > As I stepped through code, when writes were made to data in RAM, I > manually made those changes using the bytes viewer. > > When playing around with it, keep in mind that reads and writes to > 0x0000-0x07FF are not referencing the ROM and are instead referencing > RAM1 once the bank has been switched to RAM1. Ghidra doesn’t know this, > so those references must be manually changed. I probably missed some > references as I stepped my way through. > > The amount of code I’ve stepped through and tried to decipher+comment is > relatively small in terms of bytes compared to the size of DOS or disk > basic, so there’s much left to do. > > I’m hoping to get back to this soon. I should probably try to capture a > bunch of this FYI type info for the Ghidra disassembly project and > compile it into a readme. >
