Lara + hdd

Friday 17 Aug 2001, at 02:57:55,
Alexandr Tkachev -> Ilya Vinogradov:

AT>>> Just recently an hdd driver was flying in the echo, channeling under
AT>>> cmos driver for Lara, a good idea but without a clock is bad
IV>> Hehehe ;) It cost me and Mihail Zharov's only a little bit
IV>> hesitated with
IV>> beta testing of the combined driver, as on you ;)))
IV>> Gentlemen, catch the tested drivers + source codes for
IV>> them "first hand" ;))))
AT> Poorly tested there a glitch in the procedure for switching drivers ld
AT> h,0 forgot to do (MOA glitch! ), in short, try pressing
AT> the “i” or “k” button, and then click “e”, “d” and any
AT> and you will see, hear,

How does “e/d” relate to “switching drives”?
Why do my drives switch normally?
For me: Lara and the base are on “B” (virtual), but that’s all the rest
is taken and dropped onto the real “A” - everything works with a bang.
I don’t see or hear anything... ;)

[delete]

Have fun, Alexandr...

... ┌─[ZX]─>─[Scorpion]─┬─[T.]─>─[FDD]─>─[RAM]─>─[HDD]─>─[CD]─┐

Saturday August 18, 2001 at 04:17:29
Mihail Zharov wrote -> Alexandr Tkachev on the topic Lara + hdd

[skip]

MZ> How does “e/d” relate to “switching drives”?

I wrote first press “i” then break then “e” "d"

MZ> Why do my drives switch normally?

Probably because you have a real point.

MZ> For me: Lara and the base are on “B” (virtual), and everything else
MZ> is taken and thrown onto the real “A” - everything works with a bang.
MZ> I don’t see or hear anything... ;)

But I have Lara on the “B” base to “C”, and everything else is dropped out of isdos to
“D” and there are glitches, for starters, look where the program flies off when you press break ??
on the error handling procedure, Lara takes over the error handling
removes the value from the stack, there should be #0d6b on break, she checks
this and if there is #0d6b then repeats the read/write operation from the very beginning
like this Now we have a different driver, not #3d13, and naturally this value will not be on
the stack, but the return address will be there, as a result of which Lara, having not read
to the end of the sector because the break was pressed, crashes out of the
read/write procedure and does not determine what kind of error #9393 is?? = nonsense on the screen.
In general, I’m tired of proving the obvious, do point “D” andyou will see,
the truth is that this glitch will appear only if the read data in the area
of the disk starts from an odd sector or occupies an odd number of sectors
this is also understandable because in functions #05, #06 rst 8:db #81
the break key pressed interrupt is processed, but in functions #24, #25
it seems not This is why such bullshit turns out.

P.S. I have already corrected all the indicated glitches, I did this: if fdd then read/write
via the turbo loader, otherwise via rst 8 and also crammed the cmos write function into these 256
bytes.

With respect, Alexandr Tkachev.

AT> But I have Lara on “B”, the base is on “C”, and everything else from
AT> is discarded to
AT> “D” and there are glitches, for starters, look where the program flies when
AT> you press break ??

My bad, I don’t press break during disk/hdd operations.
And I won’t look - I believe it to you.

[delete]

Thanks for the information.

Have fun, Alexandr...

... ┌─[ZX]─>─[SPbZXNet]─┬─[FIDONet]─>─[INet]─>─[ZXNet]─>─[ZX]─┐