Hi Philip, I really don't know what option ROMs work with the DVI. Good question. Does anyone know?
I'm not thinking seriously about trying to modify option ROMs to make them DVI compatible. My test bed is real hardware and VirtualT, which can drive MVT100 using COM1. cheers Steve On Sun, Dec 27, 2020 at 2:09 AM Philip Avery <[email protected]> wrote: > Good going with this, Steve. Are you debugging all this on real hardware > or have you hacked VT to do 80x24, ie emulate MVT100? > > Also, does MVT100 work with all the OptROMS that work with a DVI? Or are > you attempting to do more OptROMS? > > Your interrupt dilemma... sounds like an early REX function would be > useful here. Swap out the the System ROM when activating VT100 to a hacked > System ROM with VT100-friendly interrupt routines. > > Philip > > On 27/12/2020 1:21 pm, Stephen Adolph wrote: > > My deep dive on VT100 driver integration into REX has been tiresome but > interesting. Many bumps on the road, and learnings. Actually pretty > painful to be honest. > > I have been able to explore a few ROMs, and figure out if they work or > don't work with "VT100". (which really is a modified "Disk Basic" from > Microsoft, and derives from the work others have done to disassemble Disk > Basic). > > Interestingly, ROM2 Cleuseau seems to work very well with VT100!. Should > not be a surprise as it seems to use the LCD in a simple way. > > TS-DOS ***almost*** works. You can imagine that with a few tweaks it > could work on an 80x24 screen, but then again, perhaps not usefully. > "just look at the small screen!" > > Haven't tried any other ROMs yet. An 80x24 spreadsheet and word > processor would be great! Time to try Super ROM. > > Anyhow, with a bit of knowledge gained, it seems like it might just be > possible to modify ROM programs to use 80x24. Especially if they use the > "stock calls" for printing to the screen. > > I have implemented an "expert mode" and a "safe mode". The safe mode > renders option ROMs unusable in REX, whereas the "expert mode" means ..have > at it. So, if you wanted to use R2C100 on an 80x24 screen, switch to > expert mode and off you go. > > The most painful learning for me is just how complex it can become when > you are trying to debug the combination of memory bank switching and > interrupts. > > I had originally wanted to move the VT100 driver into the REX ROM. This > would mean that 6 software hook programs would be serviced by running > software in an option ROM. So, in active use there would be (1) the main > ROM (2) the REX ROM and (3) a traditional OPTION ROM. > > But what happens when the "system" is running, at the time of an interupt, > on a separate OPTION ROM, and not either the main ROM or the REXROM? > This was not anticipated by Mr. Mo Budlong, or if he did think about it, it > is a "secret". > > Well I can tell you that I gave up after quite a bit of time sunk into > debug! OMG. > > What seems to be most reliable, is to run the "VT100" software hook > programs in upper RAM, which is how it was meant to work all along. So, > for VT100 support you kinda have to live with some memory being taken up by > that code, which reduces the usable RAM space somewhat. > > "Typical" REXMGR.BA takes about 0x200 bytes or so without VT100, and > including VT100 it takes about 0x04B5 bytes. That is more than 1k of RAM > consumed with enabling both REX and VT100. > > My prototype shows 28432 bytes free, whereas stock M100 (no REX) shows > 29638 bytes. A tradeoff I am personally happy with, for the advantages. > > I appreciate that many users may not want an LCD plugged into their M100, > but I personally really like it. I think large-screen Text, and also > programming, make it interesting, and still quite compact. > > Anyhow, happy holidays 2020 to everyone and let us all hope for an > improved 2021. > > regards > Steve > > > >
