no, just listen...

26 Sep 1999 you wrote here:

FK> Here you meant compatibility with *correctly* written software. I'm still
FK> about the "latch" #7ffd for 1MB.

OK. Let's talk about it.
Even if an ancient program for some reason tries to install a latch, then for me, s
1M, it is not dangerous, it then squirms around in these 48K and does not change pages. That is,
there is compatibility.
And if I suddenly decide to write a program that needs a lot of RAM, then I _know_ how
others use this bit and will try to ensure compatibility.
The only problem is to run the program in 48K mode, for example, to
check whether it works in it. But I don’t have such a need.
And for those who are especially picky, one OR element is installed, and then, with
bit 2 #EFF7 (128K latch) set, bit 5 #7FFD works like a 48K latch.

FK> Yeah, that was it. This happened in 1989. They sold me the
FK> BASIC_48 firmware with the sonorous name “Firmware from 1989” :). For a long time
FK> they complained that they had fixed “a bunch of proprietary glitches” in it
(quote).
FK> Everything worked with it except ELITE. :)

It sucks. But I wonder what kind of glitch she really needs?

RM>> modern monsters of ROM can be very plowed...

FK> This is what is alarming. For TR-DOS I have 27256:
FK> installed in onein the other half sits "Rodionovsky" (aka branded) 5.03 with a fixed
FK> positioning error for #3D13, and
FK> in the other - 5.13F.

Is this the one that was described in the 4th (or 5th?) ZF?
By the way, if you fix it, then the “Plole of Miracles”, which is on the entire disk, does not work.
Hmm, but in 5.13F this also seems to have been fixed...

All the best.
Sincerely Roman.

FK>> fixed positioning error for #3D13, and in another -
FK>> 5.13F.

RM> Is this the one that was described in the 4th (or 5th?) ZF?
RM> By the way, if you fix it, the “Plole of Miracles”, which covers the entire
RM> disk, does not work. XM, but in 5.13F this also seems to have been fixed...

Regarding the error and ZF:

=== I quote the file README.FIX ===

included: new sp_emu.bin (read emu.doc for more info)
TR-DOS error (excessive drive positioning) has been fixed when
reading/writing 40/60/80 sectors. Read more in detail emu.doc
It indicated the wrong way to fix the error :-(
Which ZX FORMAT told the whole country about :-(((
I fixed the Dock and ROM, my love :))
=== End of quote ===

Fixed by MaxSoft.
So the wrong method of solving the problem is described there.

And in 5.13f, I remember, he did everything true.

Located in the bugfix sheet for the UKV emulator.

Best regards,
Renat

RM> OK. Let's talk about her.

[skip]

Okay, let's call it a day. Initially, the conversation began with the fact that I
supported you with your statement that the use of the latch bit
#7ffd for 1MB of RAM is, to put it mildly, another “oddity” of the new
high memory standard for Speck.
Now the arguments from your side have moved to a different plane.

I still have a number of toys that were crippled by the Poles
(or someone else) multiface.
They only work with blocked port #7ffd, for which there is a
corresponding modification in the bootloader. On a machine with 1 MB "on
latch" these programs WILL NOT work. Here we are not talking about getting into the code of toys and fixing it.

RM>> disk. HM, but in 5.13F this also seems to have been fixed...

RM> Regarding the error and ZF:

RM> === I quote the file README.FIX ===

RM> included: new sp_emu.bin (read emu.doc for more info)
RM> TR-DOS error has been fixed (excessive positioning
RM> of the drive) with
RM> reading/writing 40/60/80 sectors. More details
RM> read emu.doc
RM> It indicated an incorrect way to correct
RM> errors :-(
RM> Which ZX FORMAT told the whole country about :-(((
RM> I corrected the doc and ROM, my dear :))
RM> === End of quote ===

RM> Fixed by MaxSoft.
^^^^^^^^^^^^^^^
Isn't this the same MaxSoft that fixed poor F-Commander_v4.01
(FC_v4.01) to an even more inoperable state (F-Commander_v4.04) :-)

RM> So the wrong method for solving the problem is described there.

RM> And in 5.13f, I remember he did everything right.

I used THREE possible options for fixing this TR-DOS bug:

- from ZX-FORMAT
- from some version (2.95) of the firmware for Scorp (LD_B,8: JP_#....)
- as in TR-DOS_v5.13F

All of them work fine on “Field of Miracles”, I didn’t check it. there is no such noise.

FK> I used THREE possible options for fixing this TR-DOS bug:
FK> - from ZX-FORMAT
FK> - from some version (2.95) of the firmware for Scorp (LD_B,8: JP_#....)
FK> - as in TR-DOS_v5.13F
FK> All of them work great. I didn’t check “Field of Miracles”, there is no
FK> such a fuss.

As for “wonderful”, I seriously doubt it. Also there was a typo...

Sincerely,
Renat