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
