im2 and call 3d13
ZXNet echo conference «code.zx»
Hello Sonic
Son> If you use the address table from RAM, then when accessing TR-DOS
Son> you will naturally fall. The thing is that after
Son> enabling interrupts in the TR-DOS ROM, a bunch of other actions are performed
Son> (restore the system environment). During this process, the code from works
Son> TR-DOS ROM. The first interrupt will disable it (because a transition will occur
Son> in RAM for your handler). When you return from the interruption you will no longer be in the same ROM
Son> in which you need.
Thank you so much! This answers all my questions. It's a pity that none of them
I didn’t come across this information in many of the documents that I had previously read - this is
would save a lot of time on investigation.
Hello, All
upon exiting call 3d13, are interruptions automatically enabled?
Hello, moroz1999
Interrupts enable functions to read and write a sector to disk at the end of its
execution. There is DI at the input, EI at the output.
Magic service functions do not allow interrupts, but they have a disadvantage:
if any error occurs on the disk, they stupidly make 20 attempts then
hang (HALT). No requests, nothing.
Perhaps I forgot some other places, but I don’t think so.
The problem can be solved simply: register I points to the ROM. We get two different
interrupt handler. One of them is called from the BASIC-48 ROM, the second from
TR-DOS. The second must return via EI; JP; #3D2F.
On older machines with an unstable data bus (on which the passive
not in #FF condition) unfortunately this will not work.
Hello, moroz1999
If you use an address table from RAM, then when accessing TR-DOS you
It’s completely natural that you’ll fall. The thing is that after permission
interrupts in the TR-DOS ROM, a bunch of other actions are performed (restoring the system
environment). During this process, the code from the TR-DOS ROM runs. The first interruption
will disable it (because there will be a transition to RAM for your handler). Will you return from
interrupts you are no longer in the ROM you need.
The problem has no solution because inside the interrupt handler it is impossible to determine
which ROM it was called from.
If you want functionality on older machines, turn on IM 1 before
accessing TR-DOS.
I don't know for sure about RETI.
Hello Sonic
wait, I don’t quite understand - what if I already have IM2, with a table of addresses?
for an unstable bus, then I need to disable or enable it when reading from
disk (c=#5)? There is nothing hanging on the interrupts, there are only EI and
RETI.
I'm just trying to understand why everything works for me with IM1 set, but
with IM2 set but disabled, when accessing 3D13 everything is periodic
falls.
By the way, another question, a little off-topic - is it necessary to do EI before RETI, like
I read that RETI itself allows interrupts?
Hello, moroz1999
and I’ll just add that there are computers that will not read floppy disks even with
IM1 if vector I is in slow memory (for example #40-#7F)
Hello deathsoft
так может стоит её выложить хотя бы на VT? :)
Hello, moroz1999
Yes, as much as I’ve been asking - well, good
Hello, moroz1999
Yes, I have already created many topics on this topic - good author, well written
books "How to write a game..." - long, without the most modern techniques, but
good! And all the happy owners insist that the scan is unnecessary. At least djVu
-- they made the image!.. :( :( ;) :( :( ;) :( :( ;) :( :(
Hello TomCaT
Tom> "How to write a game..."
Look here (first 2 lines) http://trd.speccy.cz/book.htm
Hello, moroz1999
mor> so maybe it’s worth posting it at least on VT?
So for this you need to at least scan it, and who will do this...
Hello Sonic
Son> The problem has no solution because it is impossible inside the interrupt handler
Son> determine which ROM it was called from.
Son> If you want performance on older machines, turn on IM 1 before
Son> by accessing TR-DOS.
Son> I don’t know for sure about RETI.
How does it not?
Does anyone use ROM procedures?? :)
You check the stack, if the return address is ROM, return it to TR-DOS.
Hello klondike
klo> Check the stack, if the return address is ROM, return it to TR-DOS.
Bravo! Simple and tasteful! :)
Hello Sonic
Son> I don’t know for sure about RETI.
This is written about in the book by Larchenko and Radionov again - “ZX for users
and programmers." Quote:
-+----
Returns from maskable interrupts are performed using the RETI command. She is recognized
special peripheral microcircuits*, which allows you to organize
multi-level interrupt system. But, since in the ZX Spectrum this system is not
is used, you can return from interrupts using the RET command.
*- Zilog has developed microcircuits that are included with the Z80 CPU in
kit under the general name Z80.
-+--
If only they could indicate what kind of mikruha this is ;).
Hello, acidrain
aci> If only they could indicate what kind of mikruha this is ;).
All chips included in the Z80 family kit;
Z8410; (Z80DMA) - direct memory access controller;
Z8420 (Z80PIO) - parallel interface controller;
Z8430 (Z80CTC) - programmable timer;
Z8440 (Z80SIO) - serial interface controller;
Z8470 (Z80DART) - dual asynchronous transceiver.
Hello NovaStorm
Nov> I didn’t find them on Zilog.com...
You'd better look on www.efind.ru.
They are traded by all and sundry.
Hello NovaStorm
Nov> Shit, they don't make them anymore.
They produce and sell :)
In Promelelectronics:
Z84C2006PEG (Z80B(A)-PIO) - 144 rub.
Z0844006PSC (Z80B-SIO/O) - 282 rub.
Hello caro
So this is probably from old stock? I didn’t find them on Zilog.com...
Hello klondike
klo> Check the stack, if the return address is ROM, return it to TR-DOS.
It seems that it’s not a fact that this will work. made it simpler, put it in the interruption
ei:jp #3d2f. then if there was a call from the tr-dos ROM, it returns there and that’s it
works. if the call is from RAM, then it will simply return to RAM via RET(#3d30). HO(!),
If there was a call from a BASIC ROM, then it's a bummer. for turboloaders it worked,
because they didn’t use the BASIC ROM, but for #3d13 it definitely won’t work.
as an option - put the interceptor on #5cc2 or whatever, or wherever RET is located,
so that it switches between ROMs and changes jp #3d2f to RET in the handler
interruptions.
Here:)
Hello deathsoft
dea> Look here (first 2 lines) http://trd.speccy.cz/book.htm
I've already seen this. And it’s great that the computer. there are some, but they are also in my bookstore
yes. And "ZX S and TR-DOS for items and items." -- No. Nowhere and no, here it is
sad.
Hello, acidrain
Z80DART/Z80DMA/Z80GPIO or whatever they are...
One hell of a lot, they don't make them anymore. And you can read it in the series “Microprocessor
Z80 kit"
Hello, psb
I did something like this before im2 + #3d13, but I forgot 8-)
Hello, psb
psb> it seems that it’s not a fact that this will work. made it simpler, in interruption
psb> set ei:jp #3d2f
psb>
And that's true!
By the way, I remembered something else interesting from im2 and the stack.
Namely, the stack could end up in the data area (stack throw) + im2 +
EI
On return from the interrupt, the current stack address was checked and if
data range - recovery of a data dump corrupted by a stack plus
return by jp
Hello, psb
psb> It seems that it’s not a fact that it will work this way.
I was thinking... are Im2 and #3d13 actually real? IMHO no :) why, because
according to #3d13, if there is an error, tr-dos crawls headlong to track 0 and back. and at im2
Such errors will happen all the time... that's why they used turboloaders :)
although, with a #3d13 screw, it might work. but the drive doesn't work :)
klo> the stack could end up in the data area
This, of course, is a feature, but.. has nothing to do with tr-dos :)))
Hello, psb
psb> this is, of course, a feature, but.. has nothing to do with tr-dos :)))
to im2+trdos has :)
Hello klondike
klo> to im2+trdos has
hmm..
and in more detail? ;) where does tr-dos use data transfer through the stack?
Hello, psb
psb> hmm..
psb> and in more detail? ;) where does tr-dos use data transfer through the stack?
:)
what is there in more detail?
im2+ei+referring to tr-dos+SP in the data.
In short, let's go :)
Hello klondike
klo> in short, let's go
and why did we pass? I didn’t catch up, why put a stack in the data if you use tr-dos?
some kind of bullshit...
if you throw something over the stack (a picture or whatever), then how then
tr-dos? If you use tr-dos, then why stack the data?
I don't understand!
Hello, psb
psb> why did you pass? I didn’t catch up, why put a stack in the data if
psb> do you use tr-dos? some kind of bullshit..
psb> if you throw something over the stack (a picture or whatever), then
psb> how then tr-dos? if you use tr-dos, then why stack the data?
psb> no idea!
and what is not clear? :)
boot with disk change verification.
on im2 - music
in the main loop - polling tr-dos + pushing data over the stack.
Hello klondike
klo> in the main loop - poll tr-dos+push data over the stack.
well... I thought... tr-dos and data transfer by stack do not intersect :) this
a special case:) and some kind of wrong one;) (in the sense that if it
graphics were transferred, it had to do it synchronously with interruptions;)
so as not to twitch ;)
Hello, psb
psb> well... I thought... tr-dos and stack transfer are not
psb> intersect :) this is a special case :)
psb>
Well, I’ll interrupt, it’s still not known whether it grabbed control from TRDOS or
no?
That's why there was a check of both the SP and the return address.
psb> and some kind of wrong one;) (in the sense that if it
psb> graphics were transferred, it had to do this synchronously with
psb> interruptions;) so as not to twitch;)
But it didn’t work out any other way. I don't remember why :)
It was even funnier. It is not connected with im2 and DOS at all, but it is connected with
'incorrectness':
the cycle: "reset + halt + clear" gave a torn image, and
"transfer + cleanup + halt" - stable :)
This is in the rotating "chess" fields in OVERDEMO.
Hello klondike
klo> Well, I’ll interrupt, it’s still not known, it was snatched from trdos
klo> control or not?
it depends on the approach ;) I would do it differently :) but it doesn’t matter..
klo> It was even funnier.
so there’s nothing funny here :) it’s all about the beam, it’s _absolutely_ normal :)
It’s only clearer if you start with halt;
halt; cleaning, transfer - the beam hits the cleaning, we see a glitch
halt, transfer, cleanup - it manages to transfer, but the cleanup is NO LONGER visible :)
although who knows if it didn’t fit into the int..
It's offtopic anyway :)
Hello klondike
the topic has grown into a delusional stage - no one has ever drawn sprites with
enabled im2 via trdos
klo> "transfer + cleanup + halt" - stable
This is the method that most 48k games work by.
Hello, The Exploited
The> topic has grown into a delusional stage - no one has ever drawn sprites with
The> enabled im2 via trdos
The>
Sprites via trdos? This is original.
But DOS + data stack + im2 is boot with disk change check, above
wrote.
Those. It is obvious that two points are fulfilled simultaneously:
either im2+dos or im2+stack on data, not all three.
This was about my original proposal to check the return address.
The check was needed for this purpose, to understand whether to return to DOS and
Should I restore the data table? Although it was possible to limit ourselves only
checking SP and returning by ret to DOS, but I was too clever then.
About the beam - it turns out how simple it all is...
I wish I knew sooner :)
For several years it was a mystery to me why the rewritten 1 in 1 file
The tape load procedure does not work at addresses below 49152 on my zx.
What? and working with borders with multicolor remained a secret.
Hello, psb
psb> well... I thought... tr-dos and stack transfer are not
psb> intersect:) this is a special case:) and some kind of wrong;) (in
psb> in the sense that if graphics were thrown, it should have been this
psb> do synchronously with interrupts;) so as not to twitch;)
Well, you see, there were problems with understanding why synchronization did not
is happening.
By the way, it turned out quite smoothly.
See for example these intros:
deflector/sabotage [http://zxaaa.untergrund.net/intrip.html]