I've been on a deep dive lately, integrating my early VT100 video driver into REX# and REXCPM. It has been a marathon of reverse engineering, troubleshooting and testing. All good, coming together well.
The purpose of this note is to highlight the value of Virtual T, for me. REX generally gets quite tightly tied into the M100 OS, especially in 2 ways. 1) REX takes over the timer hook and drives autoconfig of the OPTROM switching function that way. 2) REX also grabs a hold of and used 2 Software hooks - CHGET and CHPUT. These two hooks are grabbed *dynamically as needed. W*ith VT100 AKA Disk Video Interface software, now 6 or more software hooks are needed, also dynamically switched With all this interrupt driven interaction, the effects on the M100 can be... confusing. VirtualT to the rescue on that one! No way I could deduce what is happening without it! Some bugs however can be very well hidden, as they can be statistical. Since the TIMER HOOK occurs randomly, if there is a bug relating to WHEN the timer hook occurs relative to what the M100 is doing, it can be quite hard to find. Yesterday I discovered a unique bug that I really just wanted to write about. This bug is so well hidden that it has affected every REX device ever. Finally discovered and resolved! Here's the scenario. When I use TIMER hook to dynamically switch a software hook, I have discovered that the RST 7 routine at 7FD6H actually is not robust. Here is the nasty piece of code: This is the part of 7FD6 RST 7 routine that reads the software hook value. 7FE2H (21H) LXI H,FADAH ; Start of RST 38H vector table 7FE5H (3AH) LDA FAC9H ; Offset of last RST 38H call 7FE8H (4FH) MOV C,A 7FE9H (06H) MVI B,00H 7FEBH (09H) DAD B *7FECH* *(7EH)* *MOV A,M* *!! Can't take an interrupt here, if we change the hook itself!!!* *7FEDH* *(23H)* *INX H* *7FEEH* *(66H)* *MOV H,M* *7FEFH* *(6FH)* *MOV L,A* 7FF0H (F1H) POP PSW 7FF1H (C1H) POP B 7FF2H (E3H) XTHL 7FF3H (C9H) RET At 7FEC, the software hook data is read not as a single 16bit value (like LHLD), but instead it is read in 2 separate 8 bit reads! OUCH! This means that, when REX is re-configuring a software hook at the VERY instant that M100 OS is actually READING and USING that software hook, there is a chance that the hook value would be corrupted. If it had been read as a single 16bit address, such corruption would not be possible. This is clearly hard to see occur in real time since the TIMER has to hook at exactly the worst time for the system to crash. With VT, I can change the speed of the M100 to such a high rate that these events actually become probable in a limited time. So, I have noticed over the years that sometimes REX would crash in VT when running at a high speed. I always attributed it to a VirtualT problem. I know better now! ...but I *DI*gress. Steve
