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
