S-Terminal_v1.0: handler /NMI...

I found the reason for the subject not working on my computer.
The problem turned out to be in the /NMI handler. On another computer with a buggy modem MX-2496 (even in the offtopic it crashes the system with the message Inrerupt stack overflow) the terminal started
and even worked for some time :). She reset after trying to use ZModem for a reception.

My computer can process /NMI only if a
handler with a software “latch” at the input is used:

================== begin of file "NMIbyMK.a" ==================
;(c) by Michael Kondratyev
;iS-DOS terminal

NMI LD A,#00 ; Here without
LL5ED8 EQU $-#01 ; this -
OR A ; work
JR NZ,LL5EF4 ; refuses!
DEC A ;
LD (LL5ED8),A;
PUSH DE
PUSH BC
DI
CALL NMI_RD
LD A,(BNK0_7)
CP #10;IT'S BANK-0 ?
JR NZ,LL5EEE
EI
LL5EEE POP BC
POP DE
XOR A
LD (LL5ED8),A
LL5EF4 POP HL
POP AF
RETN

================== end of file "MNIbyMK.a" ====

2EM: What do you say?
Sincerely, Felix.

[I ZX]

Thursday September 23 1999 22:14, Felix Knajzev ─── All:

FK> I found the reason for the subject not working on my computer.
FK> The problem turned out to be in the /NMI handler.
The problem, as I already wrote, was that the NMI was too long.

FK> I have a computer can process /NMI only if a
FK> handler with a software "latch" at the input is used:
So that's what I'm talking about too.

FK> ================== begin of file "NMIbyMK.a" ==================
FK> ;(c) by Michael Kondratyev
FK> ;iS-DOS terminal

FK> NMI LD A,#00 ; Here without
FK> LL5ED8 EQU $-#01 ; this -
FK> OR A ; work
FK> JR NZ,LL5EF4 ; refuses!
FK> DEC A ;
FK> LD (LL5ED8),A;
Yes, this is re-capture blocking. In a normal situation, on
normal gland, recapture is not possible at all. That's why I threw out
this piece as unnecessary and in pursuit of the speed of nmi processing...

FK> ================== end of file "MNIbyMK.a" ==================

FK> 2EM: What do you say?
What you already said. :) I'll see, maybe it's really worth inserting it
back.

Good luck ! Evgeny.

■ The night is shorter than the day... The day will kill me... The world of illusions burns down in it. (WITH)Апия.

27 Sep 1999 you wrote here:

...
EM> Yes, this is re-capture blocking. In a normal situation, on
EM> normal gland, recapture is generally impossible. That's why I threw out
EM> this piece as unnecessary and in pursuit of the processing speed of nmi...
...
EM> What I already said. :) I'll see, maybe it's really worthwhile to
insert
EM> back.

Isn't it possible to do preliminary testing, and if re-capture
occurs, write "crooked iron in the /NMI area" and then adjust according to the test results
?

I've been saying for a long time: you need a program to test the modem!

All the best.
Best regards Roman.

RM> insert
EM>> back.

RM> Is it possible to do preliminary testing, and if recapture
RM> occurs,
It is quite possible that I will do so. But, on the other hand, with a very long pulse, no testing will help at all - everything will hang abruptly due to stack overflow.

RM> write “crooked iron in the /NMI area” and tune in based on the test results
RM>?
RM> I’ve been saying for a long time: I need a program to test the modem!
I’ve been doing this for a long time I say - I can’t get enough of it, otherwise I would have done it a long time ago. :)

Good luck! Evgeny. (Aka 2:5057/18.73)

RM>> recapture
RM>> is happening,
EM> It is quite possible that I will do so. But, on the other hand, with a very long pulse, no testing will help at all - everything will hang abruptly due to stack overflow. And if you make a subject with a “latch”. Send one (1) byte to the modem and
check then for the number of “left” occurrences in the handler?

Imho, if everything is OK with the hardware, then the modem will echo back three bytes: the actual
character itself, #0D, #0A. That is there should
be three interrupts (if fifo=1). In this case, program the UART to
an interrupt only when a byte is present in the data register and
the ability to read it.

[skip]

FK> And if you make a subject with a “latch”. Send one (1) byte to the modem and
FK> then check for the number of “left” occurrences in the handler?
And ? If the pulse is too long, a stack overflow will simply occur. Here, count or count, but still the stack will end up somewhere. Although,
for a purely test program, the idea is not a bad one.

FK> IMHO, if everything is ok with the hardware, then the modem will echo back three bytes:
FK> the actual character being sent, #0D, #0A.
What joy is this? It will return the 0D0A packet _only_ at the end of the response to
any AT command. When echo reply is enabled, it will return this byte itself. If
is turned off, it will not return anything.

FK>> handler?

EM> And ? If the pulse is too long, the stack will simply overflow
EM>.

It will not happen. I wrote "...with a 'latch' at the input...".
The stack, of course, will grow, but not so fatally.
For me, Dikiy worked great before the fix
hardware glitch, and the very first terminal of Misha Kondratiev -
also o.k./o.b.

EM> Here you count, don’t count, but still the stack somewhere
EM> yes it will climb. Although
EM> for a purely test program the idea is not a bad one.

You can also try checking by stack growth.

08 Oct 99 01:44, Felix Knajzev wrote to Evgeny Milun:

FK> And if you make a subject with a “latch”. Send one (1) byte to the modem and
FK> then check for the number of “left” occurrences in the handler?

FK> IMHO, if everything is ok with the hardware, then the modem will echo back three bytes:
FK> the actual character being sent, #0D, #0A. That is there should be three
FK> interrupts (if fifo=1). At the same time, program the UART to

You've crashed, reboot immediately!

From 0 to 1 byte will be returned from the modem.

And the Kondratiev scheme allows _multiple_ entries into the handler.
Here you need to fix the hardware.

Kirill Frolov. [ZX]

FK> It won’t be.
No, even if it’s big, it will be.

FK> I wrote “...with a ‘latch’ at the input...”.
So, I already have a latch. :))

FK> The stack, of course, will grow, but not so fatally.
If captures occur more often than once every 50-60 clock cycles, then more than
fatal...

Well, theoretically, it can grow indefinitely. The latch only
partially corrects the situation if it is software.

Kirill Frolov. [ZX]

EM> Only if it (the growth) is small.

So we need to find out...

By the way, Misha Kondratiev once said (at the end of last summer) in
HARDWARE.ZX that even he had a re-capture of
NMI. He never found out the reason, IMHO. I just put a lock on the
handler input.

FK>> to

KF> You've crashed, reboot immediately!

:) I've already corrected myself.

KF> From 0 to 1 byte will be returned from the modem.

Oh, that's right. One.

KF> And the Kondratiev scheme allows _multiple_
KF> entries into the handler.
KF> Here you need to fix it in hardware.

“You promise everything, yes you promise... 8-)” (anecdote)

In short - draw. There is a free half from the standard NMI key
in the scheme by MK.

FK> “You promise everything, but you promise... 8-)” (anecdote)

FK> In short, draw it. There is a free half from the standard NMI
FK> key in the scheme by MK.

It is not needed there. There seems to be one more LA3 needed...

2 Roman Milukov: if you received my letter with the subject and haven’t nailed it yet,
please make it public. Drawing is a bummer.

The point is to _always_ disable interruptions in the trigger after NMI.

Kirill Frolov. [ZX]

FK> In my case: your original subject does not work, the subject with
FK> “latch” is ok/o.b. Those. There was stack growth, but “with the latch” everything
FK> worked *excellent*.
Absolutely right. Because Your NMI is not “large”, but simply “elongated”.
Well, Roman Miliukov once had a big one. Not a single latch, as far as
I remember, helped.

FK> By the way, Misha Kondratyev once said (at the end of last summer) in
FK> HARDWARE.ZX that even he had a re-capture of
FK> NMI. He never found out the reason, IMHO. I just put a lock on the
FK> input of the handler.
Well, I don’t know. Everything works for me. :) Another thing is that when you open the NMI key, a false NMI occurs, coming from the trigger, and not from the modem. But, if the NMI handler can recognize whether there is currently data in the modem, then everything is ok.

FK>> latch "everything worked *excellent*.
EM> Absolutely right. Because your NMI is not “big”, but just
EM> “elongated”. Now, Roman Milyukov once had a big one. Not
EM> one latch, as far as I remember, didn’t help.

RTFM !

The processor catches the cut of the NMI signal!

It’s not a matter of length, but a matter of chatter due to the _/fault/_ _/modem/_.
The problem is in the _/ROM/_ of the modem. It plays with the IRQ the way it wants.
And in the bi-cap the interrupt controller fixes this issue.

EM> Well, I don’t know. Everything works for me :) Another thing is that when
EM> opening the NMI key, a false NMI occurs, coming directly from the trigger,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nonsense written.

Is there a candyuk there?

Replace it with something more suitable.

Kirill Frolov. [ZX]

EM> that when opening
EM> the NMI key, a false NMI occurs, coming precisely from the
EM> trigger, and not from

This is difficult to imagine even in theory, but in practice it is even more difficult. :) How can an unauthorized impulse appear at the output of this tigger? :-/

EM> modem. But, if the NMI handler can recognize whether
EM> there is data in the
EM> modem now, then everything is ok.

That’s how the subjects are always written.

FK> Gavrilov Roman (aka Andrey Isaev) didn’t bother with hemorrhoids at all -
FK> just installed a one-shot (555AG3) and that’s it. His NMI for the processor
FK> has always become a fixed length.

And I’ve also been talking about this for a long time. Only from this one-vibrator
the signal must also be sent to the trigger for prohibiting non-maskable interruptions -
so that until the interruption is completed it will not be entered again. And then even
maybe CPS will increase...

Kirill Frolov. [ZX]

12 Oct 1999 you wrote here:

EM> Absolutely right. Because Your NMI is not “big”, but simply “elongated”.
EM> Well, Roman Milyukov once had a big one. Not a single latch, as far as

[...]

KF> 2 Roman Milukov: if you received my letter with the subject and have not nailed it yet,
KF> please make it public. It's a bummer to draw.

Here's a snippet of your letter:

─────────
Orig.Area: .NETMAIL
Orig.From: Kirill Frolov (2:5030/827.2)
Orig.To : Roman Milukov (2:4616/29)
Orig.Subj: M.K.-Hayes
Orig.Date: 8 Oct 1999

Press RESET immediately, Roman!

21 Sep 99 09:50, Roman Milukov wrote to Kirill Frolov:

[...]
Now I think that all this is nonsense. You just need to immediately disable interruptions in the existing trigger when the NMI
signal arrives from the modem. And then let the interrupt handling program resolve them. Only here you need to make sure that a too short pulse from the modem does not inhibit, and the processor does not react, or vice versa (install a monovibrator, and start it with a percentage and a trigger from it). And you can be sure
that repeated launches of the NMI processing procedure take place
-- Kondratiev even has a special flag there for this purpose... but it still doesn’t save you from
stack overflow (there are a dozen commands there before it)
-- at one fine moment everything can end up like “(C) 1982 Sinclair Research
Ltd".

│\ ───┐ ┌────
──────┘ \──── └───┘
┌────────────┐ ___
IRQ from modem───>───┤single-shot├────┬───>───── NMI on the bus
└────────────┘ │┌─┐ through open. coll.
___ └┤&│
RES ─>───────────┤ ├──> SET trigger
on bus └─┘ in original
Kondratievskaya
scheme.

Now the trigger is no longer needed and I don’t even know what.

Kirill Frolov. [ZX]
[...]
──────────────

More specifically, this is probably how you should do it:

1533TM2
└─────3─┤C│ │ ┌───────> IRQ4 (B24)
A11 ─────────2─┤D│ │ │ ┌─┐
┌─┐ ├─┤ │ └1─┤&│ 1533LA3
/RESET ─┤&├─███─┬──4─oS│/Qo─6──2─┤ o─3─┐
┌┤ │ │ └─┴──┘ └─┘ │
│└─┘LI1 │ │
│ ─┴─ │
│ ─┬─ │
│ ═╧═ │
│ │
/NMI

Resistor - 430 Ohm, capacitance - 330 pF. It is necessary that the pulse duration be from 80
ns to... well, let it be up to 300 ns.
Oh, I have LA3 there, in the original LL1+LH1, but that’s not the essenceменяет.

KF>> nailed it, please publish it. Drawing is a bummer.

RM> Here is a stub of your letter:

This is also nonsense. Everything is useless.

RM> More specifically, this is probably what you should do:

You need to set it to INT.

The Z80 processor in IM2 mode will accept up to 7 different interrupts.
Their priorities are set by a 256-byte interrupt table. In the cycle
of reading a vector from the bus, A0 must be set to 0. And INT must be formed
from signals [non-IRQ]0..7 via AND. Everything will work just like with
a real interrupt controller!

Kirill Frolov. [ZX]

KF> You need to set it to INT.

KF> The Z80 processor in IM2 mode will accept up to 7 different interrupts.
KF> Their priorities are set by a 256-byte interrupt table. In the cycle
KF> of reading a vector from the bus, A0 must be set to 0. And INT must be formed
KF> from signals [non-IRQ]0..7 via AND. Everything will work just like with
KF> a real interrupt controller!

Almost right, only 128 interrupts (256/2), and priorities are set by connecting the IEI- and IEO-chips of the Z80 kit in series. Although
this has nothing special to do with Spectrum. And a method with 8 (!!!) interruptions
(and even a 9th - still framed with the #FF vector) is quite possible on the Spectrum,
the priorities in this case can be determined by the interrupt table. It is
this method that is used in DMA sound.

Sincerely, Dmitry.