Hey Philip/Steve, I can't say about most, but SR is not DVI compatible. Executing SR from SCREEN 1 seems to trash the display, but not hang the ROM. You can F8 out to MENU. I would say then that the LUCID and WRITE ROMs would act the same. As for DISK+ I can't say, but would certainly like to know.
As of late, I haven't tried with REXCPM, but have tried SR under DVI with REX and that was not pretty. It ended up in a hard reset and loss of test data. As I recall, I could recover w/ TS-DOS active under REX and DVI, but I in any case option ROMs and DVI seem to be a void that never was crossed and why I didn't pickup my original DVI until I found one hidden in a RadioShack for $99. These "test" were before the latest REX updates (43). I'm off this week so should have some time to check it out again, but I must first finish a keyboard drawer for a media table I'm setting up as an M100 work station and assemble my MVT100. God Bless, GregS <>< Dec 27, 2020 6:10:49 AM Stephen Adolph <[email protected]>: > 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[http://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 >>> >>> >>
