Terrible glitch!!!

I conducted experiments here on the MAGIC button from TR-DOS and discovered an interesting
thing... (it makes sense to look at my letter to Dmitry Lomov in REAL.SPECCY)

Take the following program:

DI
L1 LD HL,(#3D14)
LD A,L
OR H
JR Z,L1
EI
RET

It spins in a loop and reads 2 bytes from 3d14h. In BASIC-48 there is
0000,
in TR-DOS there is another number.

The technique is simple: Press the MAGIC button, then “4”, this is if
TR_DOS
5.12 or 5.13 is installed and so on several times. Sooner or later, the program will crash
back.
If you have a different TR-DOS, then you may have to write a dozen
memory dumps to disk.

The reason for the program exiting the loop is clear - it read from 3D13 not 0000!
Well, it’s not difficult to guess how this happened, at the moment of pressing MAGIC, the ROM was
replaced...
Let me put it simply - at the moment of pressing the MAGIC button, the interrupted program can
read incorrect data from the ROM area (only for one command). COP
always
is read correctly due to the fact that NMI generation occurs only under
the condition
PC is greater than or equal to 4000h.

The consequences may also not be the easiest for an interrupted program....
And looped commands such as LDIR, LDDR, CPIR, CPDR, OUTI, OUTD, INIR,INDR
will
work just fabulously! It is impossible to correct the situation in the NMI
processing program; reverse tracing in the Z80 is impossible.

Let us doubt everyone and remind those who want to check the subject that they need to check
only
on a real spectrum. Nothing will work in the emulator.

Hint: fixing the glitch is very difficult, a simple circuit using small logic
is not enough here
. :-(

* Crossposted in ZX.SPECTRUM
* Crossposted in REAL.SPECCY

Kirill Frolov. [ZX]

Kirill Frolov once wrote to All, and I decided to drop a couple of lines:

KF> Hint: it’s very difficult to fix a glitch, a simple circuit on small
KF> logic is not enough here. :-(

Elementary with a pencil ;-)
You just need to switch the ROM after the NMI trigger has fired and caught the reading of the command
at address #0066

At first you will need another trigger and logic to check the address, M1, MREQ
ideally in 5-6 You can fit in the buildings. BUT no one will do this :-(

True, if the trigger does not have time to switch the ROM before the Z80 starts reading
the command, then you will have to assemble something else with WAIT.

That's all. /Sergey/ []
With a large carload of registers and vishesov.
(Pickup from SVERDLOVSK-SORTING station wagon #659839002)

KF>> fine logic is indispensable here. :-(

SK> Using a pencil is elementary ;-)
SK> You just need to switch the ROM after the NMI trigger is triggered and the read
SK> of the command at address #0066 is caught

I already wrote - JP 0066h... -> glitch guaranteed.

Wrote once by Kirill Frolov to Sergey Kovinov, and I decided to drop a couple
lines:

SK>> You just need to switch the ROM after the NMI trigger is triggered and caught

^^^^^^^^^^^^^^^^^^^^

SK>> reading the command at address #0066
KF> I already wrote - JP 0066h... -> a glitch is guaranteed.

I wrote that reading should be checked only after pressing the button. And in
this situation, JP #0066 will go to the usual included ROM

SK> I wrote that you need to check the reading only after pressing the button.
SK> And in this situation, JP #0066 will go to the usual turned on ROM

Okay, and so:

0065 ED
0066 70

Or the button can be pressed only when PC >=4000h ?

... no day without speccy!

24 Jan 00 21:01, Dmitry Pavlukhin wrote to Kirill Frolov:

DP> It looks like the thing is as follows - nmi is processed only at the end
DP> of the next command, therefore, if reading is in progress at
DP> a certain address, then the processor will first finish reading the byte from
DP> memory, and Only then, with the start of a new machine cycle, will the
DP> process the NMI. But your scheme for switching/disabling the ROM
DP> is triggered upon pressing the magic button, and not upon the fact that the
DP> processor begins processing the NMI signal.

It doesn’t /look like/, here it is. Only the circuit is _not_mine_,
it is in any Spectrum with a MAGIC button...

DP> Remake the magic connection circuit so that it
DP> switches/disables the ROM only after confirmation
DP> by the process of starting processing of a non-maskable interrupt.

And look what this confirmation cycle is like!
It’s no different from the usual reading of the COP, one name :-(

DP> If you can’t, then come to me with soap, before I leave for Novosib for the session
DP> Well, it doesn’t reach you :-(

DP> P.S. Try it like in the diagram. It’s certainly not ideal (it’s not processed
DP> the button bounces and there is a certain period of time (about 300 ns) during
DP> during which it may glitch, but the idea itself should becorrect).

It cannot glitch, why, see below. But it does not save the ROM from the problem with switching
. It works during the L-H transition of the M1 signal, but do you know
how many of them there will be, for example, when performing LDIR? As much as is in BC,
if it is not zero. Yes, and any command that accesses memory after reading
COP can be processed incorrectly - the ROM BANK will be replaced after reading
the next byte of COP...

DP> the nmi signal is perceived by the processor when the CLK signal goes to 1 on
DP> the last clock cycle of the last machine cycle of the command.

NO! The H-L edge of this signal is recorded by the triggers in the processor
immediately! But it is processed as you wrote - on the last clock.

DP> The moment when CLK goes to 1, and M1 is still equal to 1, my
DP> circuit does not catch - if at this moment you press magic, then the nmi percent will not
DP> process, but the trigger will switch, maybe someone will come up with a better idea, but

No! The percent will react, because it has a trigger at the input.

DP> Here it seems that the matter is as follows - nmi is processed only at the end
DP> of the next command, therefore, if reading is in progress at a
DP> specific address, then the processor will first finish reading the byte from
DP> memory, and only then, at the beginning of a new machine cycle, will it start
DP> processing NMI.

SK>> button. And in this situation, JP #0066 will go to the usual turned on
SK>> ROM
KF> Okay, so:
KF> 0065 ED
KF> 0066 70
KF> Or the button can be pressed only when PC >=4000h?

Yes, it will break off, but IMHO in the ROM specs There is no such thing, but if RAM is enabled instead of
ROM, then such situations need to be monitored there; an interrupt vector is still needed.

SK> Yes, it will be a bummer, but IMHO there is no such thing in the ROM spec, and if the RAM is enabled

Not now, but then it will appear?

IMHO it’s better to solve everything programmatically.