How is the proposed device different than the MVT100 that Steve built?: https://bitchin100.com/wiki/index.php?title=VT100
I have this and it works well. It’s compatible with the REX# and REXCPM as well. Randy > On Dec 15, 2024, at 7:30 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] > <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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] >>>> <mailto:[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.
