Software emulation 1818VG93

January 03, 2003 (and it was 02:52 then)
Maxim Timonin in his letter to All wrote:

MT> The minimum requirements for Specky for the new firmware are 1024Kb RAM.

This is not good.

MT> Optimal - 1024Kb RAM and IDE HDD, otherwise why is this new
MT> firmware needed at all?

Why is 256 not enough?

MT> In the future, perhaps a modification of the firmware will be made for clones with
MT> memory of 512 and 256 kilobytes. A solid TRD, of course, will not fit into such memory
MT>, but it will be possible to place smaller SCL files, which is already
MT> good.

Clear. You store the image in memory. How about working directly with the screw?

And one more thing: do you fully support the MFS hard drive standard (as in Scorpio)?
Then Scorpio users could switch to your operating system
by simply flashing the ROM. Or not?

Vega/ex-Style Group.

FIDO: 2:5030/1006.19 ZXNET: 500:812/19 E-mail: veg...@mail.ru

The whole beauty of the new TR-DOS with the VG93 emulator is that it doesn’t care what
file system is on the screw. The firmware will work exclusively with the top
memory, and it doesn’t care at all how the TRD image gets there. And
it will get through the utilities of other axes. Here we take KAY's
option of working with TRD from a screw, but at a new level. That is, it will be enough
under iS-DOS, CP/M or the Scorpov monitor (in SCORPION-1024) to write
a utility that will load an image with an understandable FS into memory, then
save the configuration and itself as a resident plugin there,
then install the TR-DOS configuration and transfer control to it. And it will be possible to get the
resident by MAGIC and RESET, for which the firmware contains
interceptors that transfer control to the resident if available (scheme as in
ATM). The resident will change images if necessary (save changes)
or ensure the restoration of the old configuration, or, more simply put, output
back to the source axis.

--
Timonin Maxim

MT> Now it’s clear why the meter...
MT> You can work directly, but compatibility drops almost to #3D13
MT> with a small difference, and full emulation (namely emulation!) VG93
MT> is impossible to achieve - too different devices, timing parameters and
MT> a bunch of other crap.

What kind of a bunch of crap is this? Modern storage drives are faster than Spectrum RAM. They cache the entire image of the Spectrum disk at once. Moreover, it is not necessary for absolutely all programs to accurately maintain all
time characteristics of the 1818VG93. Or the program does not have to
work in real time.

MT> And owners of meter computers can already be rubbing their hands in anticipation of
MT> rulez.

Can not rub.

VS>> And one more thing: do you fully support the MFS hard drive standard (like
VS>> in Scorpe)? Then Scorpio users could switch to your operating system by simply flashing the ROM. Or not?
MT> The whole beauty of the new TR-DOS with the VG93 emulator is that it doesn’t care
MT> what file system is on the screw. The firmware will work
MT> exclusively with the upper memory, and how the TRD image gets there is of no concern to
MT> at all.

What kind of resistance to failure does such a system have? What happens if there is a power outage, user program failure, orerrors in the VG93 emulator? And it will
be that the user did something for 5 hours in a row and recorded it on the RAM-disk, and then
@#$@#% came. Why do we need such an emulator, it’s better to write to the GMD, it’s more reliable.
This, by the way, is the problem with all modern Spectrum emulators - the image is written at once and
only upon exit. If a failure occurs while recording the image, then you are left
without the old disk image and without the new one.

MT> And it will be obtained through utilities of other axes. Here we take
MT> KAY's version of working with TRD from a screw, but at a new level.

Kevsky means the most flawed.

In general, this is the case - the firmware is built according to this principle: in all places where
there were calls to the VG93 ports, jumpers were installed. So when substituting
entry points #3D13, you can simply insert an entire subroutine for reading the sector
from the screw. If only everyone limited themselves to using this point, there would be no problems. And
here there is emulation at the level of each byte. This is where all sorts of super-duper loaders show their temper - one of them needs to calculate the value of R
(the ripping program in VINNY PUH) upon returning from the TR-DOS subroutine (and
since when inserting a jumper the subroutine is narrowed, the register R
takes on a different value), then it determines the location of the PC register upon arrival
interrupt (and when When using the emulator, it often ends up in non-standard addresses)
as in RDS... In general, even with ideal VG93 emulation, problems arise
precisely because gentlemen programmers love to pervert the ROM.
But one way or another, at the moment, with the exception of programs that use
a non-standard flop format, 98% of the software works. Another percentage will earn
soon, and only 1% is in question...