#DOSweek #musings #GW-BASIC

So it turns out I'm NOT actually willing to give up on showing hieroglyphs next to normal letters on DOS. But the problem might be too much to ever solve appropriately. Still, there is an option:

I mentioned before how BIOS is actually a driver pack for microcomputers. Among the things it offers is also a text console. Programs interface to this console is by raising soft interrupts after filling CPU registers with important information. And the interrupts pass through a table that lists the locations of routines that handle them. The table is user-writable (in real mode, and DOS runs in real mode) - I checked, and crashed my computer. xD Which means that, IF you wanted to implement your own console, you could - by providing your own implementation of the BIOS routines and overwriting the handler for interrupts.

So the idea would be to highjack interrupt 0x10, then directly access the video hardware, set it into some high-resolution mode, use your own fonts and then begin servicing requests like you were the true BIOS. For as long as programs don't try to directly access video hardware (and they shouldn't because then even the real BIOS would also be borked), you will be able to maintain the illusion of everything being normal while at the same time enjoying a glitzy 21st century console in full HD with pleasing color gradients and maybe even faint background images. xD

Eeeexcept there is a fly in the ointment. This presumes the programs utilize a dynamically sized user interface. So your assumption is that, first the program will call into BIOS to get some kind of dimensions of the console (I didn't look too deep, but it seems like such a BIOS routine doesn't exist), then it will figure out where it wants things based on this, and then will communicate this computed information back to BIOS as coordinates for characters that make up the TUI. ... I'm not sure all interesting programs do that. What's much more likely to happen is that the programs merely assume the console has one of several dimensions and run with it. Or they might ask the BIOS only which one of these several dimensions are in use and not ask it literral number of characters horizontal x vertical.

So what's probably going to happen is that you end up with a glitzy terminal that only has content in the upper left corner or maybe even has characters all over the place - in case the program relies on implicit BIOS behavior like automatically wrapping long lines and similar.

Still, this could be a way forward. You could pair this with applications that know about this (Lynx, Mutt?) and they will then be able to generate much larger, prettier and more useful TUIs then what is possible with stock BIOS. In fact, you might even be able to create a facitily for embedding images (xterm supports this BTW) and in that way even things like w3m will work. That would be really good.

Anyway, in case you want to explore your Interrupt Vector Table, I wrote a little BASIC script that peeks around and formats the stuff it finds into the format appropriate for IVT.

1 B%=0
120 CYCLE%=4
130 DEF SEG=0
140 ADDR% = (B% * 4) + CYCLE% - 1
150 OCTET% = PEEK(ADDR%)
160 V$ = HEX$(OCTET%)
170 IF LEN(V$) > 1 GOTO 190
180 PRINT "0";
190 PRINT V$;
200 CYCLE%=CYCLE%-1
210 IF CYCLE% <> 2 GOTO 230
220 PRINT ":";
230 IF CYCLE% > 0 GOTO 140
240 PRINT ""

To change which interrupt it peeks, just change the first line and rerun the program.

In case you want to write into IVT, make sure to first change the segment used by the POKE command, like this:
DEF SEG=0

And then you can write stuff:
POKE &h00, &hef : POKE &h01, &hbe

Keep in mind that the write isn't atomic so if you get hit by an interrupt between the two pokes, the system could crash, or worse. Remember - there's no privilege separation in DOS, a bug in your BASIC program could ruin the filesystem and destroy important data. :)