CD-WALK: Announce.

PH, July 9, 2001, 23:39:00, Vlad Sotnikov -> All
subj: CD-WALK: Announce.

VS> Minimum configuration:
VS> - Scorpion 256.
VS> - SMUC.
VS> - Professional ROM 4.01

Why 4.01? After all, support for the screw comes with ProfPZ 3.9f (Code #5e).

Damn... and in almost all auto-detects it is considered that support
begins with version code #60 :(((And accordingly, nothing works for me...
I have to edit it manually "|-7

Although in the instructions for ProfPZ, at the end there is a list of versions and everything is
clear in it said...

The moral of the story, I think, is clear ;) Fix it, please ;) And tell everyone
;)))

And another question, what is ProfROM used for? After all, restarts in
working with CD-ROM will not help... Or is it needed for comfortable work with
TRD images?

VS> - CD-ROM.

VS> As you can see, for now The program only supports the
VS> SMUC controller. In future versions,
VS> may support other controllers.

VS> Vega / ex-Style Group July 9, 2001
VS>

Vlad, don’t be boring! Siril/4D.

IV> Why 4.01? After all, support for the screw comes with ProfPZU 3.9f
IV> (Code #5e).

Hmm... There are just very few such ROMs, and 4.01

IV> Damn... and in almost all auto-detecters it is believed that
IV> support begins with version code #60 :((( And accordingly,
IV> doesn’t work for me... I have to manually edit "|-7

I know where it came from :) I wrote the first auto-determiner. I did a test for byte "195" in the 8th cell, code #60 in ProfPZU... Because I had 4.01 and
I couldn’t imagine anything else :) Then I published this auto-determiner everywhere... In
in principle, as a way out, you can buy 4.01...

IV> Although in the instructions for the ProfPZU, at the end there is a list of versions and in
IV> everything is clearly stated...

Right, I’ll fix it, and I’ll fix it in the article... Although no, it will
be difficult to do in the program - everything is already in the editor, so do it yourself. There
you will need to unpack the code and find a check for #60... You don't need to do anything else - everything should work...

IV> The moral of the story, I think, is clear ;) Fix it, please ;) And tell everyone
IV> tell everyone ;)))

Good.

IV> And another question, what is ProfPZU used for after all
IV> restarts are used in working with? CD-ROM will not help... Or is it needed for comfortable
IV> work withTRD images?

Not at all. The reason is very banal: work with the IDE bus is carried out through hidden tr-dos ports. That is, you need to access them with the tr-dos ROM enabled. As
it is known, this ROM is active only if the executing code is located
at that moment in the address #0000-#3fff. That is, in ROM. And that means we need commands to
read/write from the port to the tr-dos ROM. In the standard tr-dos this is not the case (that is, there is, but we are not happy with: INI, etc.). And in the ProfPZU at the address #3ff0,
#3ff3 the commands are located: out (c),a : ret | in a,(c) : ret. In earlier versions of
ProfPZU there is nothing there and when accessing these addresses a reset occurs. This is why the check for #60 is done. If there are such commands in your ROM,
write, I will reconsider my views...

IV> Vlad, don’t be bored! WbW, Siril/4D.

Vega / ex-Style Group. July 11, 2001

Somehow Wednesday July 11, 2001 at 16:03:00, Vlad and Ilya were arguing about CD-WALK:
Announce.

VS> at the address #3ff0,
VS> #3ff3 commands are located: out (c),a : ret | in a,(c) :
VS> ret. In earlier versions

Hmmm... of course I don’t have ProfPZ... but the commands are available... and if such subroutines are needed... wouldn’t it be easier to scan the entire ROM?

[El Capitan Trueno] Yurik aka Jerri / Alien Factory /I \
[No RAR allowed] [SoHm] [Conceptual Minimalism] \ZX/

IV>> ;) And tell everyone ;)))

VS> Good.

Oki.

IV>> And another question, what is ProfPZU for?

VS> Not at all. The reason is very banal: work with the IDE bus
VS> is carried out through hidden tr-dos ports. That is, you need to access
VS> with the tr-dos ROM enabled. As you know, this ROM
VS> is active only if the executing code
VS> is located at that moment in the address #0000-#3fff. That is, in
VS> ROM. And that means we need read/write commands from the port to the
VS> tr-dos ROM. The standard tr-dos does not have this (that is, there is
VS>, but we are not satisfied with: INI, etc.). And here in the Professional ROM at
VS> address #3ff0, #3ff3 the commands are located: out (c),a : ret |
VS> in a,(c) : ret. In early versions of ProfROM, there is nothing there and
VS> when accessing these addresses, a reset occurs. It is for the sake of
VS> that the check for #60 is done.

That's it... I just thought that the presence of procedures for reading records in
arbitrary ports of the TrDos address space is the original feature
of all firmware of Scorp's TrDos...
But maybe in this case it would be more correct to check not the version of the Professional ROM,
but in general the presence of these procedures at addresses #3ff0 and #3ff3? (with the help of restart
#3d13, which moves 13 bytes of the file descriptor from the given location) - This
will be usefulfor those who also have SMUC connected, but either without Professional ROM, or not at all
not Scorpion... - In this situation, everything will work for them without problems!

VS> If your ROM has such commands, write, I will reconsider
VS> my views...

Apparently I still have to reconsider ;)

Damn, with all this talk I forgot to say that it’s a program helmsman!!!
I’m sitting, rubbing my hands, swallowing my saliva, I can’t wait for it to get to me... And
the article is also, apparently, terribly interesting.

VS> Vega / ex-Style Group. July 11, 2001

VS> + Origin: it's as simple as it seems! (2:5030/885.34)
Is everything much simpler? ;)

Bye, Vlad! WbW, Siril/4D.

Thursday 12 Jul 2001 13:51:58, Ilya Vinogradov -> Vlad Sotnikov:

IV> I keep wondering if our project with Faster "Disk
IV> Sources v5.00" has received such little distribution? There
IV> there’s just a crowd of cool procedures with direct
IV> programming of VG’shki by Faster + HDD-turbo-save/load,
IV> TRD-image mounters/dismounters... the procedure for checking the drive
IV> (from which we boot) for virtuality, and the procedure for detecting
IV> SMUC/HDD/ProfPZU in which is so sincere ;) described with which

IV> Yeah... at the valiant company Scorpion it's just
IV> a fabulous pleasure...

And they are engaged in this (production/sale) of ProfPZU? And for a long time now there has been no answer or greeting from them...:((

IV> That's it... I just thought that the presence of procedures
IV> for reading writes to arbitrary ports of the address space
IV> TrDos is the original feature of all firmware
IV> of Scorp's TrDos...

I thought correctly:) For example, in version 2.92 (naturally not ProfPZU) these
procedures have already happened.

IV> Damn, in all this talk I forgot to say that
IV> the program is steering!!!
IV> I’m sitting, rubbing my hands, swallowing my saliva, I can’t wait for it
IV> to get to me... And the article, too, apparently, is terribly interesting.

And I also don’t have a CD-ROM connected:(

2Vlad: It was previously discussed here that it’s far away Not every CD-ROM can be connected to
SMUC, and this is most likely due to the imperfection of the software and the large number of
nuances of working with different CD-ROM models. And now this problem has been solved? If
not, then what should be the requirements for the connected CD?

ps/ Will there be an AudioCD player in the ZX-News app? Otherwise it hasn’t reached us yet:(

I wish? good luck!
Sincerely, Fyodor Odegov aka FION.

YP> Hmmm... of course I don’t have ProfPZ... but the commands are available...
YP> and if you really need such subroutines... wouldn’t it be easier to scan everything
YP> ROM?

Hmmm... What kind of ROM do you have and at what address are these commands located? And in
the standard ROM there are no these commands - I already scanned.

Vega / ex-Style Group. July 15, 2001

IV> That’s it... I just thought that the presence of procedures for reading records in
IV> arbitrary ports of the TrDos address space is the original
IV> feature of all Scorp’s TrDos firmware...

Nope, in versions 2.xx this is not the case, for example. And there was no need. The need
for these commands appeared only when SMUC was developed.

IV> But maybe in this case it would be more correct to check not the version
IV> of the Professional ROM, but in general the presence of these procedures at addresses #3ff0 and #3ff3? (with
IV> with the help of restart #3d13, which moves 13 bytes of the file descriptor
IV> from the given location) - This will be useful for those who also have SMUC connected,
IV> but either without Professional ROM, or not Scorpion at all... - In this
IV> situation, everything will work for them without problems!

Hmm... Not a bad idea. In the next version of the program I will do so. And
the next version will be released soon - I want to support the Nemov controller. Or
make a driver structure. But this will work slower... In general, I myself don’t like the connection to Scorpio. This is what I've been thinking about lately:
what if you insert SMUC into non-Scorpio cars? People, metal workers: do you think it will work? Here, however, you will still need commands to work with ports
from under tr-dos, but thisThe problem can be circumvented: open ports, for example... But anyway, most likely, I’ll make a driver program. Then checking for Scorp
will no longer be necessary, and solder the controller hardware yourself, whatever you want :)

FO> And I also don’t have a CD-ROM connected:(

Don’t rush...

FO> 2Vlad: Previously it was discussed here that not every CD-ROM can be
FO> connected to SMUC, and this is most likely due to the imperfection of the software and
FO> a large number of nuances of working with different models CD-ROM. And now
FO> this problem has been solved? If not, what should be the requirements for the
FO> connected CD?

Unfortunately, the problem is not solved. Therefore, I do not advise you to rush into
purchasing CD-ROMs. Try it on my program first.

- First of all, not all CD-ROMs are ATAPI. I only support
ATAPI devices. For example, I know for sure that CREATIVE is not ATAPI. Although
they are on many offtopics. Here is a test criterion - if it responds to
CD-Player, then it means ATAPI.

- Secondly, I came across one 8x CD-ROM. The lid was closed tightly. I was not able to synchronize reading in it. I spent a month and a half with it. Then I told the people: if you want the program to come out, then you need to release it in this form. Otherwise, I’ll spend another year. Moreover, it works on most CDs. versions.

- The program was tested on 52x and 32x CDs. Everything worked with a bang. I think
the other models will work. The main thing is that the year of manufacture of the CD is newer.
The whole point is thatatapi is not yet a completely established standard.
The driver structure on the PC solves this problem. A floppy disk with a driver is supplied with each CD. Now, if CD manufacturers also supply CDs with drivers for the Spectrum :)

- In short: take the CD, see how it works on my program, and if it works, take it. All reviews are for me. I will fix everything and release new
versions.

FO> ps/ Will there be an AudioCD player in the ZX-News app? And then he
FO> never reached
FO> us:(

No, it won’t. Because the program is crooked and very widespread. I
adhere to the ideology of the collapsed Style Group: the program in the appendix to the
newspaper/magazine must be new and not published anywhere before spread. Otherwise
what's the point of making it an application?

FO> I wish you good luck!
FO> Sincerely, Fyodor Odegov aka FION.

FO> Uh-huh;) This is the first time I've heard about him;) Can you be more detailed?

Why more details? Maybe just throw it here?
A set of sources in text format without using specific
assembler directives, in the sfx-hrip archive - 57 sectors.

Disk Sources v6.00 is currently being prepared...

IV>> [some blah-blah about ProfPZU]

FO> Are they involved in this (production/sale) of ProfPZU? And
FO> there has been no answer or greeting from them for a long time...:((

You should ask ZS about this - apparently, he recently learned about GMX
from them.

15 Jul 01 13:28, Vlad Sotnikov wrote to Fyodor Odegov:

VS> - Firstly, not all CD-ROMs are ATAPI. I only support
VS> ATAPI devices. For example, I know for sure that CREATIVE is not
VS> ATAPI. Although they are on many offtopic sites. Here is the verification criterion - if
VS> responds to CD-Player, then it means ATAPI.

VS> is an established standard. The driver structure on the PC solves this problem
VS>. Each CD comes with a floppy disk with a driver. Now, if
VS> CD manufacturers also supply discs with drivers for the Spectrum
VS> :)

The Linux kernel comes with a certain amount of raw wood.

YP>> scan everything
YP>> ROM?
VS> Hmmm... What kind of ROM do you have and at what address are
VS> these commands located? And in
VS> the standard ROM does not have these commands - I already scanned it.

Tr-Dos 5.3 MOA edition

there they are right at the end

One Sunday July 15, 2001 at 12:28:00, Vlad and Fyodor were arguing about
CD-WALK: Announce.

VS> Hmm... But at 2.75 it definitely wasn’t! But good, I will check
VS> for the presence
VS> of these commands in the ROM, and not for the version number. By the way, no one
VS> can tell me the address
VS> of the subroutine that transfers 13 bytes from tr-dos to RAM?

16 bytes... this is function #08 TRDOS... transfers 16 bytes from the address in HL to the address
#5cdd

VS> No, it won’t. Because the program is crooked and very
VS> widespread. I
VS> adhere to the ideology of the disintegrated Style Group: the
VS> program in the appendix to the
VS> newspaper/magazine must be new and not previously distributed anywhere
VS>. Otherwise
VS> what's the point of making it an application?

and the new NON-BUGY version of the software?

this is also important...

IV> Beauty...
IV> 2VEGA (Vlad): It turns out ProROM is not needed at all?

If this is really the case, then it is not needed. You plug in SMUC, and on a standard
ROM you work with: CD-ROM, clock (via ports) and with a screw (via my Vega
Commander). The only thing is that you won’t be able to launch games from the screw. But the Professional ROM can be purchased later... In general, I do this: I change autoconfig in such a way that it will check not the ROM version number, but the presence of read commands from the ports at address #3FF0. In principle, the Scorp test can also probably be removed.
Then there is a possibility that a SMUC plugged into, say, the Pentagon and a ROM from Scorp will ensure work with the CD.

VS> the next version will be released soon - I want to support the Nemov controller. Or
VS> make a driver structure. But this will work slower... In general
You need to place a procedure for reading the entire block in the driver, for example on
my sector controller you can read the 512th INI.
By the way, how is it read for you? I can suggest this thing;):

ld sp,tab:jp #3d2f
exit ...
tab defw l1,l2,l1,...,exit ;the whole table is 8 kilos
l1 equ #3ff0 ;in a,(c):ret ;22
l2 ld (hl),a:inc l:ld bc,nnl:jp #3d2f ;7+4+10+10+4+10 = 67
l3 ld (hl),a:inc l:ld bc,nnh:jp #3d2f ; ^nop:ret

3.5*10^6/67= >50kb/s, (if you put #3d30, then 60kb/s without a turbo!), in general on
3.5*10^6/67= >a turbo should probably read the flop 5-6 times faster.
It’s possible to speed up this procedure (I don’t know how it is with you senior/junior
selected)

VS> I myself don’t like the connection to Scorpio. Lately I've been thinking about this: what if I insert SMUC into non-Scorpio cars? Folks, hardware people: it doesn't work;(, it's too expensive to use for this. You'll have to write software for NVRAM
(for kmos and the Isa connector, well, at least it's not necessary) and support for screw images (it's still torn;(. It will be easier to install #1ffd and flash the professional software, damn it's just there
there's some kind of tricky chip...

VS>Do you think it will work? Here, it’s true, you’ll still need commands to work with
VS> ports from under tr-dos, but this problem can be circumvented: open the ports,
you will have to change the ROM in the lumbar style
VS>, for example... But anyway, most likely, I’ll make a driver program. Then
VS> checking for Scorp will no longer be necessary, and solder the controller hardware yourself, whatever you want
VS> :)
on the one hand this is good, but for some reason the drivers have taken root only in
printers. Remember how many attempts there were to make high memory drivers, and
what was the result? There is only one din with an external driver - the Land of Myths. Everyone
others use a curved driver and a Spectrophone;(.
In general, the point here is that if you are going to make a driver structure, then you just
need a set with ready-made drivers for different controllers.

VS> Yes, the program is cool. When I wrote it (a year ago), when I counted
VS> the first
VS> sectors from the group... when I then brought out the catalog disk... made an output of
VS> subdirectories... read as text the first file from the company... copied
VS> the first demo from inside the demos.trd file, launched it on Speck, and it
VS> worked!..
it’s high time to run programs directly from a CD or from a network drive;)

VS> habitually. But I can’t imagine Speck without a CD. As
VS> did not imagine it at one time without a screw.
pts captivates with its convenienceworking with data - I’d like to completely forget about floppy disks, but
in light of the release of the subject, it’s time to return/keep people on real life, but
we need to start producing cheap controllers...

FO>> Otherwise, there has been no answer or greeting from them for a long time...:((

VS> Perhaps not. And if so, then their prices for
VS> Professional ROM are so astronomical that it’s easier to buy a
VS> programmer and flash it yourself - and it will be cheaper :)

And how much will Pzukha cost approximately? on 512 - 256 KB?

VS> No, it won’t. Because the program is crooked and very
VS> widespread.

But it’s not a fact... She was very lucky if, as an independent unit, she went further than St. Petersburg, but as an application to a newspaper, she will go much further

Even if it was launched in FIDO or Inet - after all, in networks. a smaller
percentage of Spectrumists than is commonly thought. In addition, the example of the non-distribution
of our "Disk Sources v5.000" shows that the Spectrumist
Internet community and FIDO-ppl overlap minimally.

VS> I adhere to the ideology of the collapsed
VS> Style Group: program in appendix to the newspaper/magazine must be new and not previously distributed anywhere. Otherwise, what is the point of making it an application?
For many people it will be new! Moreover, it will be logical to receive such a nice software package for SMUC + HDD/CD ROM in the application.

IV>> check not the ProfPZU version, but the general presence of these
IV>> procedures at addresses #3ff0 and #3ff3? (using
[skip]

Using restart ld c,#13: call #3d13

The restart is standard, designed to copy a file identifier of
16 bytes from an arbitrary address to the work area at addresses [#5cdd-#5cdc],
for example like this:

═══════════════════ SMUC-io .a ══════════════════

org #6000

ld hl,#3ff0
ld c,#13
call #3d13
ret

;16 bytes from the TrDos ROM were for'ldir'en
;at #5cdd.
════════════════════ ════════════════════════════

This restart calls the procedure at address #28e0 in the TrDos ROM (At least in my version of TrDos it is located at this address):

org #28e0

xor a
jr l28e5
ld a,#ff
l28e5 ld de,#5cdd
ld bc,#0010
or a
jr l28ef
ex de,hl
l28ef ldir
ret
══════════════════════ ══════════════════════════

As can be seen from the text of the procedure, in principle, it would be possible to call it from
address #28ef, through the entry point #3d2f, and copy as many bytes as you like anywhere, however, there is a danger that in other versions of TrDos, this fragment may
be located atother addresses, therefore this method will not work there, while restart ld c,#13:call #3d13 is in all firmware and, in principle,
with it you can scan at least all TrDos ROMs (through a 16-byte window).

VS> Hmm... Not a bad idea. In the next version of the program I will do the same
VS>. And the next version will be released soon - I want to support the Nemovsky
VS> controller.

Same thing.

VS> Or create a driver structure.

Imho, you can simply provide two modes of operation: optimized for
Scorpion + SMUC (since this is the platform on which everything was developed, the author can
speed up everything as much as possible), and driver mode, which may be
slightly slower, but can work on any IDE controllers...

VS> But this will work slower... In general, binding to
VS> I don't like Scorpio myself. Lately, this is what I've been thinking about
VS>: if you insert SMUC into non-Scorpio machines?

It seems that this has been practiced for a long time, if not for HDDs (there is no software for this purpose), then for CMOS clocks, NV-RAM, interrupt controller, and for connecting
Hayes Modem to the ISA Bus.

VS> Folks, hardware people: Do you think it will work? Here
VS> iron workers: do you think it will work?

It should, and why not?
VS> Here you will also need commands to work with portsfrom under
VS> tr-dos, but this problem can be circumvented: open ports,
VS> for example...

Imho, you shouldn’t open ports - it will only create conflicts...

VS> But anyway, most likely, I’ll make a driver program.
VS> And then check for Scorpio will disappear, and solder the controller hardware
VS> yourself, whatever you want :)

VS> Unfortunately, the problem is not resolved. Therefore, I do not advise you to rush into purchasing CDs. First try it on my program.
I suggest using the program to distribute a list with the models of all tested drives
(this is what they did in Condor with screws).

I was with you .┌─┐┌─┐┬┌ .┌─┐ aka J7n/4D
│┼─┼│ ├┴┐│├┤
jtn_dog_mail.ru
└┘┘ └└─┘┴ ┴└└─┘
sp...@fbi.com

VS>> of these commands in ROM, and not by version number. By the way, no one
VS>> can tell me the address of the subroutine that transfers 13
VS>> bytes from tr-dos to RAM?

YP> 16 bytes... this is function #08 TRDOS... transfers 16 bytes from
^^^
this function (ld c,#08: call #3d13) reads header
of the file from the directory by its number, and moves 16 bytes from:

YP> address in HL to address #5cdd

restart #13 (ld c,#13: call #3d13).

VS>> No, it won’t. Because the program is crooked and very
VS>> widespread. I adhere to the
VS>> ideology of the disintegrated Style Group: the program attached to the
VS>> newspaper/magazine must be new and not previously
VS>> distributed anywhere. Otherwise, what's the point of making it
VS>> an application?

YP> and a new NON-BUGY version of the software?
YP> this is also important...

And how important it is!

YP> [El Capitan Trueno] Yurik aka Jerri / Alien Factory
YP> -+- [ZX] Lara Croft with a white cane of 4.50 caliber mm

VS>> commands for working with ports from under Tr-Dos, but this
VS>> problem can be circumvented: open the ports,
VK> you will have to change the romka in lumba

Not necessary - in many versions of Tr-Dos there are commands to read/write to an
arbitrary port, and you don’t need more.

VK> In general, the point here is that if you are going to make a driver
VK> structure, then you just need a kit with ready-made
VK> drivers for different controllers.

This kit won’t appear right away - at first you can do without it, just with
instructions on how to make these same drivers.

VS>> copied the first demo from inside the file demos.trd,
VS>> launched on Spec, and it worked!..

VK> it’s high time to launch programs directly from cd

Without tinkering with the hardware, imho, it’s problematic, although on Scorpio you can
try rst8 to intercept... (and the whole #3d13 drives through rst8).

And all the fun from Scorp with SMUC (for hardware nerds like me ;) the
is that you don’t need to tinker with anything ;)))

VK> or from a network drive;)

yes, yes, and offtopic’s emulator for fun =)

VS>> Hmm... But it definitely wasn’t at 2.75! But good, I will do
VS>> a check for the presence
VS>> of these commands in the ROM, and not for the version number. By the way, no one
VS>> can tell me the address
VS>> of the subroutine that transfers 13 bytes from tr-dos to RAM?

VS>> solves the problem. Each CD comes with a floppy disk with
VS>> driver. Now, if CD manufacturers supply discs with
VS>> drivers for the Spectrum :)

KF> The Linux kernel comes with a certain amount of raw wood.

This is understandable. But I meant drivers for ASMA Z80.

VS>> counted the first sectors from the group... when then outputted the directory
VS>> of the disk... outputted subdirectories... read as text the first
VS>> file from the group... copied the first demo from inside the file
VS>> demos.trd, launched it on Speck, and it worked!..

VK> it’s high time to run programs directly from a CD or from a network drive;)

The idea was being considered :) Look: you can run code blocks from a CD without
problems. Problem with basics. But here there were such crazy thoughts: we remove emulation from the drive, for example, “C”. Next, at the error address (237xx, I don’t remember), we put the request, for example, at address xxxx. In this address we place a jump to, say, the 15th page of the scorpion. And there we install the CD-ROM
driver (port driver). Next is the following: launch BASIC from drive "C" from the .trd image on the
company. According to #3d13, he tries to overload himself. Emulation is removed, naturally
we get a TR-DOS error. There we fly to xxxx. From there we go to page 15. From there we look at what to download and where. And we ship. Result: any program from the company is loaded. That is, we simply emulate loading TR-DOS into RAM.
That is, theoretically, as you can see, this is possible. Another question: everything is happening in a way that is too complicated, there are a lot of “buts”. So I decided that there was no point in being ostracized like that. Will slow downpleasure platform.

VK> I propose to distribute with the program a list with the models of all tested
VK> drives (this is what they did in Condor with screws).

There are not many of them. And in general, I think it’s easier to cut the CDs and see whether my program works with them or not. And then you can make a database of CDs running on my program :)

Vega / ex-Style Group. July 19, 2001

ZXNet: 500:8462/1 ~/ <~ http://zs80.chat.ru/
Fido: 2:5057/21.93 /_ _> ftp://zx-museum.org.ru/zs/

[Killed.]
VS> Yes, the program is cool. When I wrote it (a year ago),
VS> when I counted the first
VS> sectors from the group... when I then output the disk directory...
VS> made an output of
VS> subdirectories... read as text the first file from the
VS> group... copied the first
VS> demo from inside the file demos.trd, launched it on Speck, and it
VS> worked!.. I couldn't sleep at night
VS> from excitement. I couldn’t believe that this
VS> was possible on Spec! And how pleasant it was
I initially believed, but did not believe that someone would take it up.

VS> the idea that there is no need to store a catalog of a lot of games in the
VS> section of the GAMES screw - on the shelf
VS> there is a bunch of people collected with
VS> games/demos/systems,
And this idea was as soon as I had it The first screw is 40MB. :)

VS> and if you need
VS>, for example, the Exolon toy, I copy it from the company, play
VS> it, and wash it. Screw
I am ready to provide you with such a compact. :)

VS> immediately unloaded 90 percent. Screws for 80-100 meters have become relevant again
VS> This is now all familiar to me. But I can’t imagine
VS> Speck without
VS> CD. How could I not imagine it at one time without a screw.
And if I also launched toys from a CD, then it would simply be a problem. But if you do it like MOA, butit won't work, because... you need to register the sector of connected
devices... Or am I wrong.

ZXNet: 500:8462/1 ~/ <~ http://zs80.chat.ru/
Fido: 2:5057/21.93 /_ _> ftp://zx-museum.org.ru/zs/

YP>> addresses in HL
YP>> to address #5cdd
VS> IMHO, still #13. Transfers 16 bytes to address 23773.

maybe so... but you guessed it :)

I usually copy all 16 kb, and then look for everything I need in the ROM :)

VS> Hmm... But it definitely wasn’t at 2.75! But good, I’ll check for

At 2.5s it was accurate (100%, I used it myself). In 2.3j - it was kind of the same (not
100%). In 2.92 - this was also the case, but I note that in all ROMs the procedures were hanging at different
addresses.

VS> the presence of these commands in the ROM, and not on the version number. By the way, no one
VS> can tell me the address of the subroutine that transfers 13 bytes from tr-dos to RAM?

#3d13. :)

17.07.01, 19:00:35, REAL.SPECCY, Yuri Potapov -> Vlad Sotnikov
Subject "CD-WALK: Announce.".

YP>>> Hmmm... of course I don’t have ProfPZ... but the commands are available... and
YP>>> if you really need such subroutines... isn’t it easier scan all ROMs?

Tue, July 24, 2001, 23:49:35, Valerij Kozhevnikoff -> Ilya Vinogradov
subj: CD-WALK: Announce.

IV>> Brrr... =) Well, what's the difference? If everything
IV>> works fine on it... Except for some newspapers/magazines with
IV>> auto-detect, which believes that the screw is supported from
IV>> version 4.01 (I don’t mean this with an evil intonation, honestly ;)

VK> Screw support is available in versions with code from #60 (96) and
VK> higher. This is official, the test versions started from #5E.

What do you mean by “screw support”?
Is it considered that on firmware 3.9f _everything_works_normal_? ;)
Or is it more important for you that somewhere it is written that “officially there is support for the screw
from version #xx” ???

And I don’t understand where you read about “officiality” ;) In the book “Brief
description of the Professional Extension of the Shadow Monitor of the computer “Scorpion ZS
256 Turbo””, about version 4.00 only what is written in it implemented
"hard disk operation in LBA mode" - fffsss! ;)
In LBA mode, the speed increased only very slightly (due to the fact that
there is no need to recalculate the logical address of the sector).

Even if it was written somewhere else that version 4.00 (#60) is official, since
the moment of publication of the fact that people also use 3.9f(#5e), it would be more logical
to use more recent information. Isn't that right? =)

VK> Code #60 is version 4.00 in my opinion. I have one like this. I don’t remember
VK> exactly, I need to look at the description.
VK> By the way, what is your controller version?
VK> Probably 1.0, since the ROM is 3.9f.

I have SMUC v1.3.

VK> I dug this firmware, there are different ports. In any case, it didn’t work with my SMUC 1.1.

Here’s what is written in the “instructions for connecting and operating v1.2”, p. 10, in
the frame: “Attention! An error was made on SMUC 1.1 and lower controllers.
Bit A8 of the IBM slot address bus is controlled not by bit D2, but by bit D3
...[SKIP]...". I don’t know if the port addresses can change because of this, but
apparently this is why SMUC 1.1 did not work for you.

By the way, due to the fact that in Melon it was SMUC 1.1 that was supported with an error in
the circuit, #7b was written to port #ffba instead of #77 (when the com port address was specified),
had to be fixed (again _one_ byte in total, even half a byte ;).

VK> Do you have the screw status register at address #F0BE (or
VK> #F8BE)? I have #FFBE. In general, read the contents of all these
VK> three ports, which of them contains #50 - that is the
VK> status register. And if its address is different from #FFBE --
VK> the subject will not work for you.

I won’t even read #50 ;)#ffbe.

[El Capitan Trueno] Yurik aka Jerri / Alien Factory /I \
[No RAR allowed] [SoHm] [Conceptual Minimalism] \ZX/

VK> tab defw l1,l2,l1,...,exit ;entire table 8 kilos
VK> l1 equ #3ff0 ;in a,(c):ret ;22
VK> l2 ld (hl),a:inc l:ld bc,nnl:jp #3d2f ;7+4+10+10+4+10 = 67
VK> l3 ld (hl),a:inc l:ld bc,nnh:jp #3d2f ; ^nop:ret

VK> 3.5*10^6/67= >50kb/s, (if you put #3d30, then 60kb/s without a turbo!), in general
VK> on a turbo should probably be read 5-6 times faster than the flop. It’s possible to speed up
VK> this procedure (I don’t know how you choose senior/junior)

Ugh, what a drag.
Have you heard about the DOS port opener? I did it myself 3 years ago. See:

DI
LD BC,#1FFD ;on. dos
LD A,4
OUT (C),A

[skip]

;main pump.
;reads A*8 words to address HL. When A=#20 - full sector.
_INI_
PUSH DE
LD DE,#D8F8
_INP
LD B,E ;4
INI ;16
LD B,D ;4
INI ;16
LD B,E
INI
LD B,D
INI
LD B,E
INI
LD B,D
INI
LD B,E
INI
LD B,D
INI

LD B,E
INI
LD B,D
INI
LD B,E
INI
LD B,D
INI
LD B,E
INI
LD B,D
INI
LD B,E
INI
LD B,D
INI

DEC A
JP NZ,_INP
POP DE
RET

We have 20 clock cycles per byte. This is 175 kB/s without turbo. In the turbo - about 240 kB/s, and
if the driver is put into ROM or cache, then even 350 kB/s. How many cycles does a flop have per exchange cycle? 112 in my opinion? And this is 30 kB/s on disks of normal density.

VK> screw (it’s still waving;(. It will be easier to put #1ffd and flash the professional file, here
VK> damn it, there’s some kind of tricky chip there...

The “cunning chip” is very similar to ID7...

And how it all began...
In the summer-autumn of 1998, I spent nights in the disassembler, poking around in the shadows,
I learned the SMUK circuit and the screw doc by heart, I still figured out these addresses
ports... I wrote a driver for Isdosa, climbing directly, until the last second
did not believe that it would work, even said goodbye to the screw in advance...
It worked!!! I was simply amazed by the speed, because at that time I was still using MOA-shny
Mhdd, which slows down specifically.
Then this info got into the echo of CODE.ZX, after that conversations began about
direct access to the screw, connecting CDs and so on... So in the appearance
of the subject there is also my contribution =) After all, I laid the cornerstone.
By the way, The information on ports in Newsk is incomplete; there are many of them not mentioned there. There is no information
about the control register of the controller, and there is not much else.

IV> I can imagine... I remember that I was amazed by the fact that on the spec
IV> it became possible to read/write MsDos disks (for the first time in IsDos). The next
IV> shock is the acquisition of Scorpion with a shadow monitor, HDD and
IV> RomDisk...
IV> I would like to unload mine... I have it at 80mb...

I have it at 130. It's all full.

VK> Wow, what brakes.
it’s clear that this is not the limit
VK> Have you heard about the port opener? I did it myself 3 years ago. Look:
heh, I'm not Scorpio ;)

VK> DI
VK> LD BC,#1FFD ;on. dos
VK> LD A,4
VK> OUT (C),A
so only you have this!
It turns out that you still need an external driver?
VK> [skip]

VK> We have 20 clock cycles per byte. This is 175 kB/s without turbo. In the turbo - about 240
VK> kB/s,
I had 16t/b
VK> and if the driver is put in ROM or in the cache, then even 350 kB/s. And how many cycles does the flop on
VK> have? 112 in my opinion? And this is 30 kB/s on regular disks
I looked at the R80, there are about 200tacts

VK> By the way, the information on ports in the news is incomplete, there are many of them not mentioned there. There is no
VK> information about the control register of the controller, and there is not a lot of other things.
the description of the ide controller is in the same format (and many other places), but as for the confusion, its ports should be in the manual...

VK> Uh-huh. Once my VG died, because one idiot dropped the floppy drive
VK> right on it.
VK> I got by with one screw for six months until I got around to finding a new one.
my screw with the sources died;-(, now I have to use PC

24 Jul 01 22:27, Valerij Kozhevnikoff wrote to Vassili Klimov:

VK>> in real life, we just need to start producing cheap controllers...
VK> Nemovsky consists of only six microcircuits... True, it doesn’t work everywhere
VK>.

I already wrote - in the circuit errors. They can be fixed.

VK> I am tormented by vague doubts that it will not pull out a screw with a CD on one
VK> cable.

We read a little higher:

VK> We have 20 clock cycles per byte. This is 175 kB/s without turbo. In the turbo - about
VK> 240 kB/s, and if the driver is put into ROM or cache, then it’s even 350
VK> kB/s.

This means PIO mode 0 in the fastest version. This should be supported by
any
IDE device, be it a CD or an iron...

VK> And how it all began...

Yes, how it all began...

VK> In the summer-autumn of 1998, I spent nights in the disassembler, poking around in
VK> the shadow market, I learned the SMUK diagram and the screw doc by heart, I dug out
VK> after all, these port addresses...

From the very moment the screw appeared, it infuriated me that there was no boot
allowing me to switch images of the screw. I had to go into the shadows. After
a thorough study of RST 8 and a personal conversation with MOA, I realized that I would have to work only through ports.
Gavrilenko gave me the ports. He said that he split the scheme. I don’t know.
Misha Zharov gave the document. With wishes for everything to work.

VK> I wrote a driver for isdos, climbing
VK> directly, until the last second I didn’t believe that it would work, I even said goodbye to the
VK> screw in advance...

I started this work in August. I have never heard of parallel development.
However, the is-dos driver already seemed to exist. I didn’t understand: if someone wrote such a driver for is-dos, why isn’t it in tr-dos?

VK> It worked!!! I was simply blown away by the speed, because back then I was still using the MOA Mhdd, which slows down
VK> specifically.

Yes, yes. The speed confused me and confused me: everything couldn’t work so quickly through RST 8
!

VK> Then this info got into the CODE.ZX echo, afterThis is where the conversations began
VK> about direct access to the screw, connecting CDs and so on...

By this time I was already reading the sectors with all my might, trying to figure out the sector
connecting images... And I came across conversations in CODE.ZX. I realized that in Moscow they are also doing this, except for me. I remember there was no way to achieve
correspondence between LBA addressing and sec/cil/head. I solved this problem and was terribly proud of it!

But problems were ahead. In September 1998, Vega_Commander was made.
Only the goal for which I did everything was never achieved: to connect the image, it was necessary to correctly enter the checksum. I never managed to break the algorithm. Later, in November, I got it from MOA. The drives began to connect! And in December, due to life circumstances, I was forced to leave
home, found myself without a computer, and Vega_Commander turned out to be unreleased.

2 years have passed. Spring, 2000. I am completely sure that the spec communicates with the screw only through ports! After all, it took me about a month to understand all the technology. And now 2 years have already passed! Imagine my surprise when it turned out that no one had done anything in this area, and the spektrumists with the screw remained at the same level as before! In a couple of weeks, I insert into the commander
the function of working with two screws, and release it in this form, like a copier
screw-screw.It's funny, but I could have done the same thing 2 years ago!

In the summer I started writing an article. It came out in the winter of 2000. And earlier, in the summer of 2000, a CD copying program had already begun to be written. And in the summer it was, in general terms, completed. Then the interface, interface, interface... Little by little
over the course of a year. CD-WALK was written in the spring, I’m writing an article. It's going slowly, but at the end of June
I finish it. And so, in August 2001, ZxNews51 should be published with my article about
CD and CD-WALK in the appendix.

VK> So in the appearance of the subject there is also my contribution =) After all, VK> laid the cornerstone. By the way, the information on ports in the news is incomplete; there are a lot of them
VK> not mentioned. There is no information about the control register of the controller, and there is not much
VK> at all.

Of course not. But I wrote to you on this topic: add more! Of course, one person
cannot know everything, especially when he is engaged in research.
Only by synthesizing various points of view and visions of different researchers
is the completeness of the picture of the phenomenon achieved. I am the only one who published such information! Formulate everything, formalize it, I think Arthur will be happy to publish your article in ZxNews.

VK>> will pull it out.
VK> judging by the diagram from the 8th format, everything is buffered there (addresses/signals
VK> control). Then what are the problems?

In decoding control signals. The problem is that the IOWR signal for the controller
is not buffered.
And the second is most likely. Let RESET directly, and through 1533AP5
connect IOWR, and I
am sure that it should work.

YP> you know and ask?

How do I know what MOA managed to release there? :) He made a thousand
versions of shadows alone. ;)

YP> 5.03, standard shorter

And what did MOA edit there? Did you register two routes in the top addresses? Or
something else?

Sincerely, Alex Noman.

VS> From the very moment the screw appeared, it infuriated me that there was no boot
VS> that allowed me to switch images of the screw. I had to go into the shadows. After
VS> a thorough study of RST 8 and a personal conversation with MOA, I realized that
VS> would have to work only through ports.
VS> Gavrilenko gave me the ports.

And shortly before that, a plump archivist flew to St. Petersburg across the expanses of ZXNet. =)
Mine was listed as the sender's address ;)

VS> He said that the circuit was split. I don't know.

Are you kidding me? ;-D The circuit is _inside ALTERS!!!_
If SMUC were made of powder, then the circuit could still be split. I
tried. Figurines. I had to torment the disassembler, studying the behavior of the shadowman in
different situations.

VS> The doc was given by Misha Zharov. With wishes for everything to work.

Well, to hell with it, the main thing is that everything works!

VK>> I wrote a driver for isdos that climbs directly, until the last second I didn’t believe that it would work, I even said goodbye to the screw in advance...
VS> I started this work in August. I have never heard of parallel development. However, the is-dos driver already seemed to exist.

Through rst8 - it was already in 1996, Mhdd.blk was called.

VS> I didn’t understand: if someone wrote such a driver for is-dos, why is it not in
VS> tr-dos?

I don’t understand. INAre there tr-dos drivers?

VK>> It worked!!! I was simply blown away by the speed, because at that time I was still using the MOA-based
VK>> Mhdd, which slows down specifically.
VS> Yes, yes. The speed confused and confused me: everything couldn’t work so quickly through
VS> RST 8!

Did you use my driver? On your computer? But it’s for open ports!

By the way, rst8 can be different. There is r8-dos, which works with 256-byte
sectors and is not much different in speed from #3d13, and there is direct reading
512-byte sectors from a partition, which is two times faster.

VS> By this time I was already reading the sectors with might and main, trying to figure out the
VS> image connection sector... And I came across conversations in CODE.ZX. I realized
VS> that in Moscow they are also doing this, except for me. I remember there was no way
VS> to achieve correspondence between LBA addressing and sec/cil/head. I solved this
VS> problem and was terribly proud of it!

And how? I always had a spread of plus/minus three sectors.

By the way, if anyone says that this is not standard, then know that it is not so :) In
GMX this same bit is responsible for the same thing;) Only it also includes the TR-DOS ROM.

VK> We have 20 clock cycles per byte. This is 175 kB/s without turbo. In turbo
VK> - about 240 kB/s,

Oh, but on GMX it will be even faster :)

VS> In principle, I like the idea of open ports.
VS> The only thing is that not everyone likes/knows how to solder.

It’s not necessary to solder, you can also buy GMX;), although at the same time I’m not sure that
xxFD ports will be available.

VS> And you need to write software to the existing standard.

Well, how I wrote that open ports are also a standard :)

VS> From the very moment the screw appeared, it infuriated me that
VS> there is no boot that allows you to switch images of the screw.
VS> I had to go into the shadows. After a thorough
VS> study of RST 8 and a personal conversation with MOA, I

By the way, what is MOA doing now? Can we wait for new versions of the ROM?

VS> I remember there was no way to achieve correspondence between
VS> LBA addressing and sec/cil/head. I solved this problem and
VS> was terribly proud of it!

By the way, if I use your article to program the screw, will
everything work on the LBA screw (there is nowhere to check:()? As I understand it, the difference is only in
the position of the emulation sector? Will it be enough to just read the LBA port flag to determine this position? states?

VS> function of working with two screws, and release it in this
VS> form, like a screw-screw copyer. It’s funny, but I could
VS> do the same thing 2 years ago!

By the way, what is the latest version of Vega Comander?

VS> Of course not, but I wrote to you on this topic:add!
VS> Of course, one person cannot know everything, especially
VS> when he is engaged in research.
VS> Only by synthesizing various points of views and visions
VS> of different researchers is the completeness of the picture
VS> of a phenomenon achieved. I am the only one who published such information
VS>! Formulate everything, formalize it, I think Arthur will be happy to publish your article in ZxNews.

A few more questions about the article :)
1) When should the screw's readiness bit to receive/send data
(DRQ?) be checked? In your READ_S procedure, it is not polled at all, but nothing
worked for me until I started polling it:( Is it enough to poll it only
before the start of the reading procedure or before each received byte?
2) Is it correct to take the address of a subsection (connected) not from the table
of subsections, but from the emulation sector?
3) Is it possible to switch the subsection without the participation of TM? (Otherwise, neither the shadow machine is friendly with the
extended screen at all:((() Or will you have to connect partitions when
starting the program?

ps/ Did my soap reach you about NetWalk?

I wish you good luck!

VK> Screw support is available in versions with code #60 (96) and higher. This is
VK> official,
VK> test versions started from #5E. Code #60 is version 4.00
VK> in my opinion. I have
VK> like this. I don’t remember exactly, I need to look at the description.
VK> By the way, what is your controller version?
VK> Probably 1.0, since the ROM is 3.9f. I dug this firmware, there are different ports.
VK> In any case, it didn’t work with my SMUC 1.1.

My SMUC 1.3 and ProfPZU 3.9d worked perfectly together with a 125 MB screw. And quite officially :).

Sincerely, Dmitry.

IV> Well, what for??? Why did it give in to me? To old detectors, which

There are fewer glitches there. I don't recommend 4.01. Some of my programs don't work =)

IV> Does everything work for you on SMUC 1.1? Why don't you change it to SMUC 1.3
IV? 8)

Already changed it. I changed it with a soldering iron. =) There is work for 5 minutes.
Here is a piece of my docket, which I am currently finishing:

······------====== Monitor glass cutter ======------······
By the way, it is worth mentioning the version history of the SMUC controller.

1.0 is a terribly crude test test, the ports are crooked, there is no #7FBA at all.
Released in small quantities.
The ProfROM version for it is 3.9x, with 4.x it is not able
to work in principle.
1.1 - All addresses listed here are valid for it.
1.2 - Fixed a bug with addressing the ISA slot and INT flag.
1.3 - Cheaper version. There is no connection to the CMOS
clock clock and contacts for the battery, so only DALLAS can be installed
into it. The rest is a copy of 1.2
······------====== Monitor glass cutter ======------······

VK> not a fact.

The information was received from Timofey Lapo, a man, albeit a crazy one, but well-known in
many circles.

VK>>> the romka will have to be re-edited anyway
VK>> Why?
VK> ahh... here the conversation was about installing the smook on _not_ scorpio
VK> the new software must be somewhere!

In RAM, of course.

VK>> dropped. I got by with one screw for six months until I got around to finding a new one.

It was something. Someone is pushing a new program into the echo, and everyone is happy except me. A
why? The turboloader does not come from the screw.
A strange sight for some: people are using Speck, playing games, reading mail, etc.
against the background of a board with an empty socket for VG. ;)

One day Thursday July 26, 2001 at 10:27:33, Alex and Yuri were arguing about CD-WALK:
Announce.

AN> How do I know what MOA managed to release there? :) He made a thousand versions of shadow people alone. ;)

and the fact that trdos was plowed is not indicated anywhere there.

YP>> 5.03, standard shorter

AN> And what did MOA edit there? Did you register two routes in
AN> top addresses? Or something else?

There is no free space left. there is a lot of everything from their driver for
brake, and ending with pieces of the service monitor

FO> A few more questions about the article :)

Come on :)

FO> 1) When should the readiness bit of the screw
FO> to receive/send data (DRQ?) be checked? In your READ_S procedure, it is not
FO> polled at all, and nothing worked for me until I began to
FO> poll it:( Is it enough to poll it only before the start of the
FO> reading procedure or before each received byte?

If you follow the structured programming algorithm, then in the case of a
screw, the following:
1. A read command is sent to the screw.
2. The screw sets the BUSY (busy) signal and reads data from the disk.
It places the first sector in the memory buffer (There is such a buffer on the screw, it
size is 512 bytes. It is through it that operations take place. read/write).
3. Removes the BUSY signal and sets the DRQ signal. Now the computer must pull out 512 bytes from the screw's RAM one byte at a time. In principle, now the screw needs time to
put the next 512 bytes into the buffer, then it sets the DRQ signal. Whether it sets BUSY at this moment. I know. Most likely, it doesn’t.

As you can see, the fact that it didn’t work for you indicates that you have a
slower hard drive than the one I worked with. And ask for DRQ after
reading the next sector (512 bytes).

FO> 2) Correct.will
FO> take the address of the subpartition (connected) not from the
FO> subpartition table, but from the emulation sector?

Take it from anywhere. In both cases the address is correct, it is the same. So
take it from the emulations sector, of course!

FO> 3) Is it possible to switch
FO> subsection without the participation of TM? (Otherwise, neither the shadow machine with an extended screen
FO> is friendly at all:((() Or will you have to connect partitions when starting the
FO> program?

Really. You change the emulation sector, put the correct check
sum there. And with C=1, CALL #3D13 or converting from BASIC to 8 page
the changed sector is duplicated.

FO> ps/ Did you get my message about NetWalk?

I still can’t register the NetWalk mailing list.

Vega / ex-Style Group. of the year

FO> worked until I started polling it:( Is it enough to poll
FO> only
FO> before the start of the reading procedure or before each received
FO> byte?

Yes, it is enough only once per sector.

[ skip ]

Nikolaj.

VS>> the visions of different researchers achieve a complete picture of the phenomenon.
VS>> I am the only one who published such information! Formulate
VS>> everything, formalize it, I think Artyp will gladly publish your article in
VS>> ZxNews.

VK> Everything is presented in a rather dry way, it doesn’t look like a newspaper article.
VK> One word - proof.

In Paragraph her!!!!!!!!!

Stanislav

FO>> In your procedure> READ_S it is not polled at all,
FO>> and nothing worked for me until I started to
FO>> poll it:(

VS> As you can see, the fact that it didn’t work for you,6
VS> indicates that you have a slower
VS> hard drive than the one with which I worked with. And poll DRQ
VS> after reading the next sector (512 bytes).

It didn’t work for me either, which confused me: the first
sector was read normally, but instead of all subsequent ones there was nothing,
and besides, the indicator for accessing the screw did not go out. It was enough
to add one (!) access to the status register. after
reading the next sector for everything to work (however
the LED never went out). That's why I abandoned this topic for about
a year ;) Until alternative docks appeared.

VS> Vega / ex-Style Group. July 27, 2001
VS>

Vlad, don’t be bored! WbW, i┌i└/4D.

VS>> deal with the image connection sector... And
VS>> came across conversations in CODE.ZX. I realized that in Moscow
VS>> they are also doing this, except for me. I remember that there was no way
VS>> to achieve correspondence between the LBA addressing and
VS>> sec/cil/head.
VS>> I solved this problem and was terribly proud of it!
VK> And how? I always had a spread of plus/minus three sectors.

What is the problem? Are you talking about the translation of LBA ->
cyl/heads/sectors? There are only 2 divisions that need to be completed... At least that’s how it works for me.

VK> There are inaccuracies in your article. In particular, about the descriptors of
VK> sections. Here are some of mine. Because it's been so long, I no longer remember exactly where I read them from. Maybe we're just talking about
VK> different things?

About different things ;)
What you give below are not partition descriptors
(which are stored in the first sector from the beginning of MFS), but
descriptors returned to the address specified in hl by the function
С=35, a=#10, rst 8:db #81
The structure of the descriptor differs from what is stored in
the MFS table (directory) (or TrDos section). Its length is 25 bytes:

VK> DEFB #03, #00,#00,#00,#00, #00,#00,#00,#00
VK> type start coordinate end coordinate

DEFM "Name_01", "Name_02"
namePartition, image name TRD or 6 spaces.

DEFB #00,#00,#00,#00
four unused bytes.

VK> And also, the tr-dos disk image descriptor seems to be allocated
VK> 25 bytes, but not all of them are used.

All descriptors take up 25 bytes, “but not all of them are used” =)

26 Jul 01 11:00, Valerij Kozhevnikoff wrote to Vlad Sotnikov:

VS>> I remember that there was no way to achieve correspondence between the addressing
VS>> LBA and sec/cil/head. I solved this problem and was terribly proud of it
VS>>!
VK> And how? I always had a spread of plus/minus three sectors.

So that’s why your driver for isdos (for the Nemov circuit) is incompatible with
Leontief?
Mine is not compatible.

July 28, 2001 (and it was 10:52 pm then)
Ilya Vinogradov in his letter to Valerij Kozhevnikoff wrote:

IV> Yes... At that time I was only understanding the internal structure
IV> of sections/descriptors. The emulation sector
IV> independently dug up... All this without analyzing the ROM ;) However,
IV> figured it out... I wanted to write a hard connection... But only
IV> this trick with CRC really screwed me up ;(

Me too then. Only it was easier for me: I went to the Scorpion company, found
Zonov there, and gave him a long lecture on the topic “Why "The developers don't want to support programmers? That's why your computer is selling so poorly." Apparently,
Zonov then stuck MOA, and when I called him, he immediately agreed with me about a time to hand over a printout of the CRC calculation. We met in the office of the company. and he gave me a piece of paper with a listing of the procedure. At the same time, Zonov said: “Here, you say that we don’t support programmers!”

KF> In decoding control signals. The fact is that the IOWR signal for the
KF> controller is not buffered.
well, I don’t know... there it doesn’t come directly from the computer (on a professional controller
IOWR and IORD are just WR and RD driven through IR22), by the way, there are a bit too many resistors there...
KF> And the second one is most likely. Let RESET directly, and through 1533AP5
KF> connect IOWR, and I
KF> am sure that it should work.
is it buggy for someone?;)

С Вами был .┌─┐┌─┐┬┌ .┌─┐ aka J7n/4D
│┼─┼│ ├┴┐│├┤
jtn_собака_mail.ru
└┘┘ └└─┘┴ ┴└└─┘
sp...@fbi.com

29 Jul 01 14:32, Vlad Sotnikov wrote to Ilya Vinogradov:

VS> you say that we don’t support programmers! byte :)

Why isn’t it anywhere in the ROM?

VS> It worked for me too. As I assumed, Kozhevnikov had
VS> just a buggy procedure for dividing a 32-bit number.

KF>> 1533AP5 connect IOWR, and I’m sure it should work.
VK> is it buggy for anyone?;)

It didn’t work for me otherwise.

VS> A standard is what everyone has.

Then the screw is not a standard :)

VS> For example, my ports are not open.

This is the main obstacle...

VS> He is most likely engaged in off-topic matters. And the new version of
VS> ROM is in GMX. And, it seems, the last one.

At least he fixed his glitches...

FO>> 2) Is it correct to take the address of a subsection
FO>> (connected) not from the subsection table, but from the
FO>> emulation sector?
VS> Take it from anywhere. In both cases the address is correct, it is the same. So, of course, take it from the emulations sector!

Just, as I remember, if you enter _only_ the name of the section into the emulations sector and
do not enter the address and so on, then everything will still work :)

FO>> 3) Is it possible to switch the subsection without the participation of TM?
FO>> (And even the shadow market is not friendly with an extended screen
FO>> completely:((() Or will you have to connect partitions when
FO>> starting the program?
VS> Really. You change the emulation sector, put the correct checksum there
VS>. And with C=1, CALL #3D13 or
VS> access from BASIC to the 8th page
VS> the modified sector is duplicated.

It doesn’t work for me :( More precisely, it doesn’t work when dismounting the disk. That is, I
first write zero to the emulation sector for the current drive (there is no emulation).
Next, I count the CRC and write the sector.I'm trying to switch the drive (C=1, #3D13),
the drive doesn't start, but the screw "twitches". And then, whenever you read from
this disk, everything freezes. Even after the reset, if you look at the table of
connected partitions, you can see that disk A (which was dismounted) is physical.
But you can’t count anything from it: be it from a shadow drive or from BASIC. In
the latter case, he generally writes that supposedly No Disk :) Although in fairness
it is worth noting that the drive is already twitching;)
Moreover, if you insert Rst8 in the appropriate place, then everything works
normally, but the GMX screen disappears, and this is unacceptable:(
In principle, it is logical that the shadow guy knows nothing about the fact that I did something with
the emulation sector, and still thinks that the disk I was accessing is virtual. But then the question arises: where does the shadow guy get information about which disk is physical and which is not? Most likely, this information is not stored in the eighth bank, because if the eighth bank crashes, then the programs that access physical drives work fine, but those that access images fail... will tell you the most optimal way out of this situation,
I will be very grateful :)
As a last resort, you can do this: use Turbo-loader for floppy disks,
and rewrite the emulation sector only when exiting the program. This,Of course,
it will be less convenient, but it’s transparent for the program, since I don’t use shadow subroutines there...

PH, July 30, 2001, 14:29:10, Fyodor Odegov -> Vlad Sotnikov
subj: CD-WALK: Announce.

FO> But then the question arises: where does the shadow person get
FO> information about which disk is physical and which is not?
FO> Most likely, this information is not stored in the eighth
FO> bank, because if the eighth bank is crashed, then
FO> programs that access physical drives
FO> work normally, but those that access images
FO> fail...
FO> If anyone can tell me the most optimal way out of
FO> this situation, I will be very grateful :)

Information about whether the A/B drives are real or virtual (0,1) is stored in the 2nd most significant bits of port #7fba (TRDos address space), which operates on
read/write (that is, when connecting/disconnecting an image in drives
a/b, the shadow operator writes information there, and when accessing them, reads it in order
to make sure whether they are real or virtual). If the drive is real, then
it is set to one, otherwise - zero. Bit 7 is responsible for drive A, bit 6 is for drive B. Only these two bits work for reading/writing, the rest are always at
1. That is, if the monitor counted %1011 1111, then it assumes that A-real,
B-image.
C/D drives are always virtual (according to the Scorpion developers), therefore their status is entirely determinedcontents of the emulation sector. And, in theory,
your method should turn them off without problems.

FO> As a last resort, you can do this: use
FO> Turbo-loader for floppy disks, and rewrite the emulation sector
FO> only when exiting the program. This,
FO>, of course, will be less convenient, but for the -
FO> program it is transparent, since I don’t use shadow subroutines there...

Imho, turboloaders/savers are a good thing only if it is possible to disable them, because All sorts of glitches are possible. (True, there are turboloaders that I
trust ;) From the collection "DiskSourses v5.00" by Faster - a very reliable thing and
_never_ failed ;)

FO> Sincerely, Fyodor Odegov aka FION.

Fyodor, don't be bored! WbW, i┌i└/4D.

FO> It doesn’t work for me :( More precisely, it doesn’t work when dismounting the disk.
FO> That is, I first write zero to the emulation sector for the current drive
FO> (there is no emulation). Then I count the CRC, write the sector. I try
FO> to switch the drive (C=1, #3D13), the disk drive does not start, but the screw
FO> “jerks.” And then everything freezes when reading from this disk.

Everything is correct. Because #3d13 works through the 8th bank and it says
that there is emulation on your disk.

FO> Even after the reset, if you look at the table of connected ones. partitions,
FO> it is clear that disk A (which was dismounted) is physical. But
FO> you can’t read anything from it: either from shadow or from BASIC.

There are different types of resets. Try a “cold” one (with the “left” key).

FO> In the latter case, it generally writes that it is supposedly No Disk :) Although
FO> in fairness it is worth noting, that the drive is already twitching;) With
FO> in this case, if you insert Rst8 in the appropriate place, then everything
FO> works fine, but the GMX screen disappears, and this is unacceptable:(

Since RST 8 helps, then the problem is in the 8th page.

FO> In
FO> principle it is logical that the shadow guy knows nothing that I did something
FO> with the emulation sector, and still believes that the disk to which I
FO> contacted - virtual. But then the question arises: where does the shadow
FO> get information about which disk is physical and which is not? Most likely
FO> most likely, this information is not stored in the eighth bank, because if
FO> the eighth bank crashes, then programs that access physical
FO> drives work normally, but those that access images
FO> fail...

And where is it (the information) stored? It's definitely not on the screw. And TR-DOS at MOA
constantly consults the 8th page. In case the disk we are working with is emulated. Most likely (I assume) that there is some
control byte in the 8th page, and if TR-DOS does not find it (the 8th page
is crashed), then it does not access it and works with the disk as if it were a physical one.

FO> If anyone can tell me the most optimal way out of
FO> given the current situation, I would be very grateful :) As a last resort, you can
FO> do this: use Turbo-loader for floppy disks, and rewrite the sector
FO> of emulations only when exiting the program.

You can do this. Then, by the way, you can safely crash TR-DOS variables - also
extra memory :) (if you read through ports. RST 8 also seems to
use them).

FO> This,
FO> of course, will be less convenient, but for the program it is transparent, since
FO> I am not there with shadow subroutinesI use...

In general, I think you need to deal with the problem of switching the screen
when addressing the Shadow - for you, I see, this is the source of many troubles. This means that this problem will continue to bother you in the future. As an option (I don’t know the essence of the problem), maybe after contacting the shadow you can manually restore the screen?

FO> Sincerely, Fyodor Odegov aka FION.

Vega / ex-Style Group. July 31, 2001

load capacity. but, IMHO, the problem there is not in the number of devices, but in the compatibility of temporary huts. if the m/s “pulls” the cable, it can easily pull an additional
TTL load, if this does not lead to risers and ringing in the cable.
We seem to have done it right - low-resistance resistors in the circuit of the most critical
signals.

All the best.
Dmitry. [ZX] [Quake]

np: The Beatles - Julia [stopped]

IV> Information about whether drives A/B
IV> (0,1) are real or virtual is stored in the 2nd most significant bits of port #7fba (Address
IV> space TRDos)
[skip...]

Thank you, it almost helped :) However, not everything is so simple: the sector is re-registered,
the disk drive is installed as real. But here the following problem arises:
now, when accessing #3D13, the shadow engine does not turn on (on the one hand, this
of course is good :)) and therefore does not re-register the emulation sector in the 8th
bank. However, the floppy disk can already be read :) But this will not happen yet
appeal to the shadow user, who will find himself in a double position: on the one hand, the image is registered in the
eighth bank, on the other hand, the disk is accessed as if it were a
real one:(
Let's think...:)

IV> C/D drives are always virtual (according to
IV> the Scorpion developers), this is why their status entirely
IV> is determined by the contents of the emulation sector. And, in theory,
IV> using your method they should be turned off without problems.

But I don’t have anything to test it with;)

IV> Imho, turboloaders/savers are a good thing only if
IV> there is a possibility of turning them off,

So I don’t want to bother with this for now...:)

I wish you good luck!

FO>> physical drives work fine, but those
FO>> that access images fail...
VS> And where is it (the information) stored? It's definitely not on the screw
VS>. And MOA's TR-DOS constantly consults the 8th
VS> page. In case the disk with which we
VS> are working is emulated. Most likely (I assume) that
VS> there is a certain control byte in the 8th page, and if
VS> TR-DOS does not find it (the 8th page is crashed), then it does not contact
VS> it and works with the disk as if it were a physical one.

We've already figured it out :) There is a port #7FBA.

VS> It could be like that. Then, by the way, you can safely crash
VS> TR-DOS variables - also extra memory :) (if you read through
VS> ports. RST 8 also seems to use them).

There is enough memory for now. Reading through ports makes it possible to use much
larger amounts of memory: up to 2Mb;)

FO>> This, of course, will be less convenient, but for the program -
FO>> it is transparent, since I don’t use shadow subroutines there
FO>>...
VS> In general, I think you need to deal with the problem
VS> of switching the screen when turning to the Shadow is for you, I
VS> see, this is the source of many troubles.

I'm already used to it :) In version 5.00 of the ROM, turning on the Turbo mode apparently occurs
at interrupts (unlike 4.01). Aon GMX, the bits responsible for screens and Turbo
hang on the same port, and that’s where the glitches come from. Now, if the shadow operator at least read first
the bit values ​​of this port, and then changed what he needed, such glitches could be
avoided. In general, “we wanted the best, but it turned out as always” (c)
MOA;))

VS> So, this problem will continue to bother you in the future.
VS> As an option (I don’t know the essence of the problem), maybe after
VS> turning to the shadow, manually restore the screen?

These will be multi-colors, worse than with 7 screen. Here also the synchronization
will be lost:(

I wish you good luck!

...6
FO> Thank you, it almost helped :) However, not everything is so simple:
FO> the sector is re-registered, the drive is installed as
[skip]
FO> Let's think...:)

When I solved a similar problem two years ago (how long ago ;) I was solving a similar problem, the thought kept popping into my head to directly correct what was contained in the 8th
page. What stopped me was a premonition that in different versions all this could be located at different addresses (although this is not a fact, maybe MOA did not change the location of system variables?). Therefore, I also thought about the following - how to find this place in the 8th bank on any firmware? You can try this, during the (initial)
installation of the commander on a computer, you can simply connect the partition (via the emulation sector) to, say, drive A, then ask the user (or arrange a cold reset by messing up the 8th page) to reset with the "left" key, while the emulation sector is guaranteed to be counted in the 8th bank, and when you repeat startup
(2nd stage of installation) look in this page for what we connected.
Information about partitions in version 3.9f is located from the address #e9f3 in the following
format:

+ 00 (1)- type
+ 01 (4)- first sector of the partition (image)
+ 05 (4)- last sector -//-
+ 07 (6) - section name,
+ 13 (6) - image name

Total 21 bytes, the first descriptor is immediately followed by the second, etc.

Ifthe image is disabled (the drive is real), then #00 is entered into the type.

Information about the partitions is duplicated from the address #ea47, that is, it comes immediately after
the first sequence of 4 descriptors.

These two areas are responsible for the partitions that are included in the TrDos and
R8-Dos areas, respectively, they usually coincide (it seems that since version 4.00 there was even a
special item in the menu Monitor: "synchronization of areas"), but may
become desynchronized when connecting partitions by restarting with = 35. It is in the area of ​​the r8-dos descriptors that the newly connected partition is registered, while TrDos remains untouched, which is why we have all sorts of inconveniences.
Thus, the sequence of actions when hard connecting a partition to
an arbitrary disk is as follows:

We register in the emulation sector,
we register in the 8th bank in the r8-dos descriptor area,
We copy this area with a trivial ldir to the tr-dos descriptor area.

As a result, we have hard (in the emulation sector) and soft (in the 8th bank) and
visually (when entering the H. Hard Disk Utility menu) the same partition, with
which we can work both from R8 and from TrDos.

By the way, on the 8th page, in the partition/image name field you can write anything
anything - this is not critical (though this name will only be saved until the first manual
reconnection of any image).

And I’m wondering what kind do you have addressesdescriptors (in 8-page)?

FO>> Let's think...:)
IV> You can try this, during the (primary) installation
IV> of the commander on the computer, you can simply connect
IV> the partition (via the emulation sector) to, say, disk A, then
IV> ask the user (or arrange
IV> yourself by messing up the 8th page, cold reset) to reset with
IV> the "left" key, while The emulation sector
IV> is guaranteed to be counted in the 8th bank, and
IV> when you restart (2nd stage of installation) look in
IV> this page for what we connected.

If we exclude the case that the format of the emulation data may change...

IV> Information about partitions in version 3.9f is located at the address
IV> #e9f3 in the following format:
[skip...]
IV> And I’m wondering what your descriptor addresses are (in
IV> 8-page)?

The first descriptors are from address #EA14, the second are from #EA68. As you can see, the addresses do not
match:( My version is G5.00

FO> The first descriptors are from address #EA14, the second are from #EA68. As
FO> you see, the addresses do not match: (My version is G5.00

Good ;) The total versions with HDD support are: 3.9f, 4.00, 4.01,
G5.00 - four of them (they say 3.9e worked for someone), so
you just need to shock their owners so that they publish the addresses of the descriptors
in 8th bank, and write out these (4*2)*2= 16 bytes ;) You don't even have to do a cold reset
;)

FO> But there are still problems with disks A and B (although every
FO> time I'm getting closer to my goal):( Now when
FO> dismouting a disk, you can read a directory from it,
FO> select it using C-1 3D13, and even if
FO> enter the monitor and look into the Hard Disk Utility, then
FO> we will see that this disk is physical (there are no emulations), but
FO> if you try to read the
FO> directory from this disk in the monitor, it displays "Bad Disk #1":( Maybe there
FO> what variables change...

And this is all despite the fact that port #7fba Have you sent the necessary bits?
Mmm... yes...

Then this option: disable the partition as standard, from the monitor, and save
the 8th jar, then disable it (under the same initial conditions, independently,
without the participation of the monitor, and again save the jar, and then compare what
turned out...

FO>> My version is G5.00
IV> Good ;) The total versions with HDD support are:
IV> 3.9f, 4.00, 4.01, G5.00 - four (they also say that
IV> 3.9e worked for someone),

The GMX doc also mentions version G4.03 :) However, I very much doubt that
someone else still has it...

IV> Then this option: disable the partition as standard, from
IV> the monitor, and save the 8th jar, then disable it (under
IV> the same initial conditions, independently,
IV> without the participation of the monitor, and save the jar again, and then
IV> compare what happened...

Ugh, it helped :) From the address #FFCC in the eighth jar there is a plate of four
bytes. Each corresponds to its own drive: #E0 - virtual, #C0 -
physical. Naturally, this address is only in G5.00, but I think it won’t be difficult to find it in other
versions :-) Now everything works with a bang.

I wish you good luck!

FO> Ugums, it helped :) From the address #FFCC in the eighth bank there is
FO> a plate of four bytes. Each corresponds to its
FO> drive: #E0 - virtual, #C0 - physical.
FO> Naturally, this address is only in G5.00,

He-he ;) The funny thing is that it seems this address is standard and does not depend on the version of
ProfROM! ;))) I have 3.9f - it is the same, that is, #FFCC!!!

Let's summarize: it turns out that on _any_ version of Professional ROM with support
SMUC/HDD, you can do the following:

- connect/disconnect a partition in the emulation sector,
- write information about whether the Drive is real or virtual in port
#7fba. (7th-6th bits)
- write information about this into variables at #ffcc.

Yahoo! This is already enough for normal/carefree work!!!

However, if we also know the addresses of the TrDos/R8-Dos area descriptors in ram8,
then we can also “visually” connect any image: that is, when entering the
monitor, in the “Hard Disk Utility” menu it will be possible to see the name of the current
connected partition, which previously appeared only after a forced
reading of the sector emulations when manually connecting another subsection from the
monitor.

The addresses in the following versions of ProfROM are now known:

3.9e (#5d) - no
+ 3.9f (#5e) - #e9f3
4.00 (#5f) - no
4.01 (#60) - no

G4.03 (#??) - no
+ G5.00 (#??) - #ea14

2ProfPZU users with screws: Publish addresses in your versions!!! (And the code
of the ProfPZU version).

FO> but I think it won’t be difficult to find it in other versions :-)

already found ;)))

FO> Now everything works with a bang.

Yahooo!!! Kaaalbasa ;)

IV> If the owner provides addresses, it will not be difficult to support
IV>.

It is unlikely that such owners will be found, since flashing the ROM on GMX is as easy as shelling pears.
If only MOA prompts;)

IV> To summarize: it turns out that on _any_ version
IV> of Professional ROM with support for SMUC/HDD, you can do
IV> the following:

IV> - connect/disconnect a partition in the emulation sector,
IV> - write information about whether the Drive is real or virtual
IV> to port #7fba. (7th-6th bits)
IV> - write information about this into variables at the address
IV> #ffcc.

IV> Yahoo! This is already enough for normal/carefree
IV> work!!!

Yeah, some problems still arise: sometimes, though
very rarely, and I don’t understand in what cases it restores the value of 7fba, although
this can already be bypassed in many ways, in any case, it’s not fatal, it’s just
for a while the ROM of the shadow machine turns on, but everything is read
normally from the floppy disk :)

IV> Now known addresses in the following versions of ProfROM:

IV> 3.9e (#5d) - no
IV> + 3.9f (#5e) - #e9f3
IV> 4.00 (#5f) - no
IV> 4.01 (#60) - no

IV> G4.03 (#??) - no
IV> + G5.00 (#??) - #ea14
^^#64

ps/ Now I’ll start mounting :)

I wish you good luck!