| Gotcha. There were never any programs using DVI disk BASIC. I love the DVI but the 80–column monitor output is the most useful part. Lots of disk options already. I think the MVT100 works with those. Maybe not.
I can see the appeal with a device that provides external monitor support and virtual disk drive
Thanks Sent from my iPhone Randy,
I am looking at implementing a DVI - providing disk as well as video support - from what I can see with the MVT100, it looks like a hardware terminal emulator on the serial port, not providing disk support.
Kindest regards,
Doug Jackson
ph: 0414 986878
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
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
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 If you’d like, I can try to upload a txt file output from Ghidra.
Sent from my iPhone 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 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.
|
