;) No, not quite.
The M100 during normal operation isn't in disabled state. In fact I am
relying on the TIMER hook to enable all those functions of REX - so the
timer hook has to happen.
What I have to do is, when a TIMER interrupt occurs, I need to peer back up
the stack and deduce where the interrupt occurred. If it is a dangerous
spot, I have to return and do nothing at all.
In this code snipped you see what I do immediately. The dangerous range of
codes is 7FE0 to 7FEF. Looking up the stack ... If I see a return vector
that fits that description, bail out!
lxi b, 07FE0H ; lower range 7FE0-78EF covers dangerous range
ldsi 10d ; get stack 10 back, see who was interrupted
lhlx
mov a,l
ani 11110000b ; look at upper 4 bits only
mov l,a
dsub ; compare
jz hook_program_common_exit
; hit! bail out!
;....otherwise proceed to modify Software hooks willy nilly.
On Sat, Dec 12, 2020 at 1:01 PM Philip Avery <[email protected]> wrote:
> 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
>
>
>
