Schematic is in the Service manual: http://cini.classiccmp.org/pdf/Tandy/Disk%20Video%20Interface%20Service%20Manual.pdf
On Sun, Dec 15, 2024 at 7:31 AM Doug Jackson <[email protected]> wrote: > A text file would be awesome. > > The block diagram I have seen suggests that its z80 based. > > Do you know what other chips are used for the disk, video, interface to > the m100? > > Looking at the m100 side I'm starting to believe it's just an 8255 being > controlled by the m100. > > Does anybody have a schematic of the DVI? > > I suspect we will be rewriting the disk basic extensions once we see the > code that gets uploaded from the DVI to the m100. > > Doug > > > On Sun, 15 Dec 2024, 10:45 pm Royce Taft, <[email protected]> wrote: > >> I had attached screenshots of some sections of the disassembly relevant >> to drive selection for the IPL. I assumed the message didn’t even send once >> I received an automatically generated email stating I had exceeded the >> message size limit. I guess it went through, just without the images. >> >> I should have copied and paste text instead of taking screenshots, but I >> was on mobile and haven’t gotten clipboard sharing working between my >> phone’s vnc client app and the VM yet. >> >> Doug, >> >> If you’d like, I can upload a txt output from Ghidra to the GitHub >> repository. >> >> I think a project to create a modern hardware emulation of the DVI is a >> great idea, and it sounds like a fun project! >> >> Royce >> >> Sent from my iPhone >> >> On Dec 15, 2024, at 03:26, Royce Taft <[email protected]> wrote: >> >> If you’d like, I can try to upload a txt file output from Ghidra. >> >> >> Sent from my iPhone >> >> On Dec 14, 2024, at 23:50, Doug Jackson <[email protected]> wrote: >> >> >> 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. >>> >>
