Question for cool coders

Imagine this situation:

The program is running and at one fine moment we press a certain button
“MAGIC-2”, which generates NMI and substitutes memory
of type CACHE instead of ROM. Moreover, the button cannot be blocked by anything; at the moment
it is pressed, the computer configuration can be any.

So the question itself: how can a program running in the cache determine
whether the interrupted program was in the tr-dos ROM or in the BASIC ROM?

Through ports TR-DOS is not possible, they coincide with the 580BB55 ports (extension
for pros, etc.). Maybe through AY? But here there may be
a conflict with the TR-DOS ports... I don’t know how :-(

So I want to solve the riddle, I really want to...

If anyone has any thoughts - write.

But!!! I don’t need to write that the button in the ROM in general or in TR-DOS
does not work, that you can solder a pure hardware one determinant...

* Crossposted in ZX.SPECTRUM
* Crossposted in ND.STATION.LOCAL.946
* Crossposted in REAL.SPECCY

Kirill Frolov [ZX]

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

KF> The program is running and at one wonderful moment we press a certain button
KF> “MAGIC-2”, which generates NMI and substitutes memory for ROM
KF> type CACHE. Moreover, the button cannot be blocked by anything; at the moment
KF> it is pressed, the computer configuration can be any.

KF> So the question itself: how can a program running in the cache
KF> determine whether the interrupted program was in the tr-dos ROM or in the BASIC ROM ?
KF> So I want to solve the riddle, I really want to...

Well, there are several options:
1. If you have such a button, then most likely you know how to hold a soldering iron,
We make some kind of read port, and get data from a trigger that determines
which ROM is enabled.
2. If you provide that the cache is not included in the entire lower 16kb, then from the remains of the ROM dump you can determine what is included.
3. (Suitable for some tasks and if you have a Pro) Just enable access to
VG ports to read/write, and... exit to the program. So, the ROM
that was enabled will be saved, but the data in the #DFFD port will still have to be determined.

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

KF> ?

the trigger is switched off via M1 from RAM, therefore, the trigger will retain
its state. hang a bit on the port :) you can organize a latch where
the state of the trigger will be rewritten at the moment of NMI.

All the best.
Dmitry.

... LD..X-TRADE... [ZX]

KF>> BASIC? So I want to solve the riddle, I really
KF>> I want...

SK> Well, there are several options:
SK> 1. If you have such a button, then most likely you know how to hold
SK> a soldering iron. We make some kind of port for reading, and get data from
SK> a trigger that determines which ROM enabled.

I wrote it in plain English - there is no need for hardware add-ons.
I can solder 486 percent there...

SK> 2. If you ensure that the cache is not included in the entire lower 16kb, then
SK> from the remains of the ROM dump you can determine what is included.

Cache turns on instead of 16kb, soldering iron EXCLUDED.

SK> 3. (Suitable for some tasks and if you have a Pro) Just
SK> enable access to the VG ports to read/write,

If you have enabled them, you will never know what you had
enabled before.

Now first I read from ports 3F and 5F, then I turn on DOS and read again,
then I turn off DOS and read again... The result may be different:
1. I determined the current bank. 2. I identified it incorrectly (unlikely)
3. I know for sure that I did not determine it.

Kirill Frolov. [ZX]

Dmitry Lomov once wrote to Kirill Frolov, and I decided to cross out a couple
lines:

KF>> "MAGIC-2", which generates NMI and substitutes memory
KF>> type CACHE instead of ROM.
DL> there is a difficulty - you need to know when exactly substitute if it
DL> sucks up a long command from the ROM, and you slip it in...

So, you just need to disable NMI generation in the presence of M1 and prefix bytes
on the data bus. Thus, NMI will be guaranteed to work after
the command, though checking 4 bytes is an overhead thing :-(

DL>> it sucks a long command from the ROM, and you slip it a bye...

SK> So, you just need to disable the generation of NMI in the presence of M1 and
SK> prefix bytes on the data bus, Thus NMI will work
SK> guaranteed after the command, True, checking 4 bytes is an overhead thing
SK> :-(

no need to complicate the task so much ;)
I used to think in a similar way and even made a device on this
principle (catching prefixes).
In fact, the algorithm is simple - NMI can be set when there is an MREQ, but
there is no M1.

18 Jan 00 12:49, Dmitry Lomov wrote to Kirill Frolov:

KF>> the “MAGIC-2” button, which generates NMI and substitutes CACHE type memory instead of ROM
KF>>.

DL> there is a difficulty here - you need to know when to substitute it. if it
DL> sucks up a long command from the ROM, and you slip it in...

There is this :-( And not only a long command, data for the command too. :-(

Any ideas on how to fix it? It’s just simple - there are 2 triggers and
the logic is small. It seems like the Z80 doesn’t have commands where it first writes,
and then reads ? So you can switch by recording (it will just start writing to
the stack). But no... there are also all sorts of LDIR... :-(

Now there is a trigger, R--RESET, C--reading FB and 7B, D--A7.
At the input S is turned on when the button is pressed... No ideas... :-(

It is necessary to create a complex circuit to catch NMI and subsequent
cycle of reading the cop, and if the command is with prefixes, then M1 changes several
times :-( There is a feeling that the ROM
can be replaced correctly only if you install a circuit on the bus that will analyze the COP.
You can, of course, allow NMI only with PC>=4000h, but the problem
remains - when replacing the ROM at the wrong time, one processor command
can read incorrect data if it reads it from the ROM area.
If it were possible to traceprograms back, then the glitch
could be eliminated programmatically, but this is not provided for in the program. :-(

In the book there is a “non-maskable interrupt confirmation cycle”,
but I don’t know how it can be distinguished from the COPA reading cycle in a command with the prefix
:-( All that remains is to catch all the COPs from the data bus and
from them try to understand what the processor is doing. At address 0066h to catch
NMI is also unrealistic, the program itself can make JP 0066h...

I picked up the scorpion circuit, looked at it and I was in deep shock...
There is the same problem. Launching NMI and switching the ROM immediately after
WAIT (it’s just unclear whether the data is direct or inverse
). read incorrectly from the ROM :-(

The classic scheme on a single-shot (like in the Pentagon) also has a glitch :-(

The TR-DOS developers screwed up badly...

However, the likelihood of encountering a glitch is extremely small, especially if
the button is blocked when PC>=4000h.

Once, Thu Jan 20 2000 13:00, Kirill Frolov wrote to Dmitry Lomov about [Question for
coolers]:

KF> It is necessary to create a complex scheme to catch NMI and the subsequent
KF> reading cycle, and if the command has prefixes, then M1 changes several
KF> times. :-(

but M1 never appears “every other” time. Only in a row.

KF> There is a feeling that it is possible to replace the ROM correctly
KF> only if you put a circuit on the bus that will analyze the COP
KF>.

You’d better analyze the commands with your head ;)

KF> The book shows a “confirmation cycle” non-maskable interrupt",
KF> but I don’t know how it can be distinguished from the COPA reading cycle in a command with the prefix
KF> :-(

_no way_. in my book they wrote that in the INTACK cycle the processor does not respond to WAIT;
it seemed real to me, and I made a special circuit. Hell, it reacts as
usually ;)

KF> All that remains is to catch all the COPs from the data bus and
KF> from them try to understand what the processor is doing. At address 0066h, catching
KF> NMI is also unrealistic, the program itself can make JP 0066h...

at first I did just that. Then I caught prefixes on the bus, and now I know that it’s possible without them. but no longer necessary :-)

SK>> is guaranteed to work after the command, although the check is 4 bytes
SK>> an overhead thing :-(

DL> there is no need to complicate the task so much ;)
DL> I used to think in a similar way and even made a device based on
DL> this principle (catching prefixes). in fact, the algorithm is simple - NMI
DL> can be set when there is MREQ, but not M1.

There is only one problem:

LD A,B
LD C,B
LD B,E
...

^^^^^ in such a section you will never wait for an interruption.

Even more:

DI
HALT

wait...

Kirill Frolov. [ZX]

DL>> on this principle (catching prefixes). in fact, the algorithm is simple
DL>> - NMI can be set when there is an MREQ, but no M1.

KF> There is only one problem:
KF> LD A,B
KF> LD C,B
KF> LD B,E
KF> ...

KF> ^^^^^ in such a section you will never wait interruptions.

and this doesn’t happen ;) for a long time, of course.

KF> Even more:
KF> DI
KF> HALT

doesn’t roll :) you can shoot by the presence of the HALT signal.

DL> doesn’t work :) you can shoot by the presence of the HALT signal.

Well, you see, the circuit is getting more complicated...

And you still haven’t answered what to do if data is read from the ROM?

Example:

DI
LD HL,#3D14
XOR A
CP (HL)
JR Z,$-1
EI
RET

try ^^^ this. after all, it’s not an eternal cycle....

KF> LD HL,$+3
KF> JP (HL)
KF> And so?

bummer :(

KF> And you still haven’t answered what to do if data is read from the ROM?

KF> Example:

KF> DI
KF> LD HL,#3D14
KF> XOR A
KF> CP (HL)
KF> JR Z, $-1
KF> EI
KF> RET

change the NMI scheme to normal ;)
and let JP (HL) wait :-)

DL> change the NMI scheme to normal ;)

For the allocated section, is there a normal option? IMHO no, just like for
LDIR.

DL> and let JP (HL) wait :-)

It’s useless, it’s not even a matter of COP, but a matter of changing the ROM bank at the time of reading
data from there. No simple circuit can fix this, at least I don’t
know how.

IMHO the only correct solution is to switch ROM banks only
programmatically.
That is. in the Basik-48 ROM at address 0066 place a program that will save
registers
and switch to TR-DOS.

What to do with the Kondratieff modem connection diagram is also not entirely clear,
you need to somehow fix the interrupt source - on the bus or on button.

Firstly, in any section except _DI_, any
interrupts will work. And besides, there is no command that could
disable _NMI_ .

KF> Even more:

KF> DI
KF> HALT

KF> wait...

This will not work against NMI - _non-masked_ interrupts
cannot be disabled by anything.
It is only INT that can be disabled by the DI command.

Sincerely, Sasha.

DL> and this doesn’t happen ;) for a long time, of course.

KF>> Even more:
KF>> DI
KF>> HALT

DL> doesn’t work :) you can shoot by the presence of the HALT signal.

Wait, what are you talking about? If about INT, then everything
is correct. But NMI, as far as I know, cannot be banned.

Sincerely, Sasha.

KF> There is this :-( And not only a long command, data for the command
KF> too. :-(
KF> Any ideas on how to fix it? It’s just simple - there are 2 triggers and
KF> the logic is small. It seems like the Z80 doesn’t have commands where it first writes,
KF> and then reads? So by recording you can switch (the stack will just start writing in
KF). But no... there are also all sorts of LDIR... :-(

In the manual for the z80 it is written that the nmi and int signals are analyzed at the end of
execution of the last machine cycle of the command. If I'm not mistaken ;) this
means that there is no need to invent anything - the processor will handle everything just fine.

Yours sincerely, Dmitry.

KF> ^^^^^ in such a section you will never wait for an interruption.

KF> Even more:

KF> DI
KF> HALT

KF> wait...

Kirill, read the docks on z80. M1 is not at 0 all the time, even when executing single-byte commands. During regeneration (and it happens after each command fetch), M1 is set to 1. In general, nmi is a non-maskable interrupt, so it doesn’t care about your di-halt :).

Sincerely, Dmitry.

AP> Wait, what are you talking about? If about INT, then everything
AP> is correct. But NMI, as far as I know, cannot be prohibited.

It cannot be prohibited, but that’s not the point.

The fact is that when you press the MAGIC button, the BETA-DISK system switches
ROM bank at the wrong moment. If the DATA for the command currently being executed is in ROM, then the command will be executed incorrectly. In the case of LDIR there will be
a particularly difficult case...

... no day without speccy!

KF>> interruptions.

AP> Firstly, in any section except _DI_, any
AP> interruptions will work. And besides, there is no command that could
AP> prohibit _NMI_ .

You did not understand the essence of the conversation. We were talking about generating the NMI
signal only at the moment of reading data (not the operation code) from memory.

KF>> teams too. :-( Any ideas on how to fix it? It’s just simple -
KF>> there are 2 triggers and the logic is small. It seems like the Z80 doesn’t have commands
KF>> where it first writes and then reads? So you can switch
KF>> by recording (it will just start writing to the stack). But no... there are also
KF>> all sorts of LDIR... :-(

DP> In the manual for the z80 it is written that the nmi and int signals are analyzed at the
DP> end of the execution of the last machine cycle of the command. If I am not
DP> wrong ;) this means that there is no need to invent anything - the processor
DP> itself will handle everything perfectly well.

You don’t understand.

I’ll explain it again:

You press the button MAGIC, this is only at the end of the command
execute
correctly. And the BETA DISK-GLUCODROM switches the ROM bank immediately after pressing the
button.

TEST:

DI
XOR A
LD HL,#3D14
L1: CP (HL)
JR Z,L1
EI
RET

So there won’t be an endless loop... The tenth time it will definitely fall out.
You just need to press MAGIC.

P.S.: Doesn’t the soap work for you?

The internal NMI trigger is latched on the edge of the NMI signal regardless of the progress
of the cycles, but checking the reaction to the installed NMI trigger actually
occurs at the end of the command.

KF> You can’t block it, but that’s not what we’re talking about.

KF> The fact is that when you press the MAGIC button, the BETA-DISK
KF> system switches the ROM bank at the wrong moment. If the DATA for the command
KF> currently being executed is in ROM, then the command will be executed
KF> incorrectly. In the case of LDIR there will be a particularly difficult case...

IMHO, in the case of LDIR it will be the same as in the case of regular commands.

s?

KF> IMHO the only correct solution is to switch ROM banks only
KF> programmatically.
KF> That is. in ROM BASIC-48 at address 0066 place a program that
KF> will save
KF> registers
KF> and switch to TR-DOS.

It is already in 48 BASIC :). You just need to correct the error in the ROM and everything is OK.
By the way, it is fixed in Scorp. At the address #5сb0 and #5сb1 you place the address of your
nmi processing procedure. After that, when you click on magic (you will have to add another button so as not to crash in TR-DOS), control will be transferred to your program. This is the most correct way.

Sincerely, Dmitry.

KF>> commands currently being executed are in ROM, then the command will be
KF>> executed incorrectly. In the case of LDIR there will be a particularly difficult case...

DL> IMHO, in the case of LDIR it will be the same as in the case of regular commands.

Well, you better think about it. At the moment you press the magick (and after M1) your
bank will switch, and LDIR may take data from the wrong ROM bank.
And this is a fact. Just as regular commands are buggy (I provided a test), so is LDIR.

KF>> only programmatically. Those. in ROM BASIC-48 at address 0066 place
KF>> a program that will save registers and switch to TR-DOS.

DP> It is already in 48 BASIC :). You just need to correct the error in the ROM and

It doesn’t fit.

DP> on the magic (you’ll have to put another button so that it doesn’t
DP> crash in TR-DOS) control will be transferred to your program. This is the most

In TR-DOS and you need to crash!

At the moment the idea is this:

Switching cans by pressing MAGIC is thrown away. The ROM changes.
The program, upon receiving NMI, saves the registers, tries to determine whether the MAGIC button is pressed
and goes into TR-DOS if it is pressed, otherwise it works as expected
(needed for the Kondratiev modem connection scheme).

It is necessary to make it possible to read the state of the MAGIC button, I don’t know how... :-(

KF> Well, think better. At the moment you press the magick (and after M1) your
KF> bank will switch, and LDIR may take data from the wrong ROM bank.

only one byte. if there was an NMI, immediately after sending one (current) byte
an interrupt occurs - _independent_ of the BC.

KF>> your bank will be switched, and LDIR may take data from the wrong bank
KF>> take the ROM.

DL> only one byte. if there was an NMI, immediately after sending one (current)
DL> byte an interrupt occurs - _independent_ of the BC.

How? Are you sure?

I wrote the program:

di
ld bc, 0
ld de, 0
ld hl, 0
ldir
ei
ret

I launch it and it works for ~1.5 seconds. If you press MAGIC, then after exiting
from NMI it takes the same amount of time. :-/

I have a suspicion that when an LDIR operation is interrupted, the address of this command is
saved
on the stack, am I right?

But in any case, there is a glitch. We need to fix it.

Once, Fri Jan 28 2000 15:17, Kirill Frolov wrote to Dmitry Lomov about [Question for
coolers]:

DL>> only one byte. if there was an NMI, immediately after sending one
DL>> (current) byte, an interrupt occurs - _independent_ of BC.

KF> How? Are you sure?

of course. At any stage of LDIR execution, an interruption is possible. as you understand,
returning from the interrupt will switch the ROM back.

KF> Wrote the program:

KF> di
KF> ld bc, 0
KF> ld de, 0
KF> ld hl, 0
KF> ldir
KF> ei
KF> ret

KF> I launch and it works for ~1.5 seconds. If you press MAGIC, then after
KF> exiting NMI you need the same amount of time. :-/

I don’t understand.

KF> I have a suspicion that when the LDIR operation is interrupted, the address of this command is saved on the stack
KF>, am I right?

yes.

KF> But in any case, there is a glitch. We need to fix it.

Well, well. climb into millions of Specs with a soldering iron? :-)

DL> well, well. climb into millions of Specs with a soldering iron? :-)

Is there another solution? After all, MAGIC on a Scorpio turns out to be
the most dangerous button after a reset... Well, “@” is not always
able to be reset correctly.

But what about MAGOS-like ones, for example, this glitch bothers them too.

One day, Sun Jan 30 2000 04:04, Kirill Frolov wrote to Dmitry Lomov about [Question for cool coders]:

KF>>> I launch it and it works for ~1.5 seconds. If you press MAGIC, then

DL> is interrupted.

Cool! Now I checked - indeed.

But IMHO not in all processors, like in the Soviet processor
I had problems with this - the music howled during interruptions, but instead of LDIR
I installed a bunch of LDI and everything became ok. Maybe there was just a short INT. :-/

KF> Cool! Now I checked - indeed.

KF> But IMHO not in all processors, like in the Soviet process I
KF> had problems with this - the music howled during interruptions, and instead of LDIR
KF> I installed a bunch of LDI and everything became ok. Maybe there was just a short INT. :-/

yes, probably.
they couldn’t change the principles of its functioning when the processor was ripped off.
the LDIR command is executed by jumping to itself if the BC is not zero;
thus, it is executed anew each time, therefore, it is
interruptible :)

03 Feb 00 00:33, Dmitry Lomov wrote to Kirill Frolov:

DL> functioning. The LDIR command is executed by the method of jumping to
DL> itself, if BC is not zero; thus, it is executed anew each time
DL>, therefore, it is interruptible :)

You can do the same effects!!!

If you LDIR a piece of memory where the command is located!!! %-)

Sat 5 Feb 2000 at 00:42, Kirill Frolov ═> Dmitry Lomov:

KF> You can do the same effects!!!
KF> If you LDIR a piece of memory where the command is!!! %-)

congratulations, you have invented the wheel...

[ WBR, Oleg. ]
[ 20:03 5 February XXXV A.S. ]