Nice *DI*gression, Steve. So is that the fix for you - DI on the REX
side whenever you're writing a hook?
Philip
On 13/12/2020 1:22 am, Stephen Adolph wrote:
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
