driver ms-dos<->tr-dos

VG>>> It understands absolutely any
VG>>> ms-dos format and allows you to work with long
VG>>> (>>255 seconds) files on TRdos!!!!

[skip]

YV>> And what standard did you choose for long
YV>> files on a tr-dos disk? ;)
VG> Simple: if the first file is called
VG> XXXYYYZZ.C, then the next one after it will be
VG> called exactly the same... ;)

I guessed it, no other way ;-)

VG> That is. There may be identical
VG> files on the disk, but they will belong to the same one.

Almost correct, because they may not be completely
the same.

VG> You can also do it like in ZX_ZIP.
VG> After the file there will be files with asterisks...

In no case - a lot of minuses!

VG> Here, advise the best way. So far I haven't gotten to this
VG> yet.

Only according to the "Melona standard".
It can be even better, a little bit, but no one has commanders
that fully work with
the pseudo-three-character extension.

[skip]

Happily. Mikhail.

MZ> Only according to the “Melona standard”.

how is that? I don’t know.

MZ> It could be even better, a little bit, but no one has commanders
MZ> that fully work with the
MZ> pseudo-three-character extension.

There will be, there will be a commander for you!

Banana in your ear, Mihail .... :)
You were terribly -=STS=- of VSp...

VG> how is that? I don’t know.

There is a software like this: “Melon_v*.**” - a high-end
terminal for real-life developers. So when receiving
a file more than 64k, from offtopic-PC, it
cuts it exactly according to this “standard” ;-)
There is a program PK_UNZIP, don’t you
use it? So she “sees” the pc-zip archives cut
after Melon, as one file.

VG>> There will be, there will be a commander for you!
MZ> Oh! Is it also spelled commander?
MZ> Otherwise, you have a multi-tasking axis. ;-)

Not written yet. But it will be...
I have already developed a turbo loader (advanced), it can work with
allowed interruptions, and even very quickly!

[skip]

VG> Well, in short :), on the disk (or in the current
VG> directory) there cannot be 2 files with
VG> the same names (as in MSDoS)
VG> this will be correct, I think...

Maybe, maybe you forgot about the extension.

VG> this will be correct, I think...

I understand that you want in name counter
to make sure that there is no same name on the
tyr-dos disk? Then the situation:
I bring, say, from a familiar offtopic
an ms-dos disk, where there is a pc-zip-archive file,
more than 64 kilos. I copy with your driver. And
then forced to deal with the hassle of renaming so that the current
zx-prog "pk_unzip" can "see" it
and unzip it.
- it is better to support the current "standard".
Even better, modernize the current
"standard" and support both the old one and the new one.

MZ> The digit begins to be substituted into the extension
MZ> only from the _second_ file, which, like
MZ> all subsequent ones, is inactive.
MZ> It/they are nothing more than appendages to the first
MZ> file/header, in which there are no changes -
MZ> no is being done.

What then is the point of inserting the number?
The files must be the same.

MZ> You still haven’t answered the question: haven’t you
MZ> never used the program “pk_unzip”?
MZ> And accordingly, you haven’t seen large pc-zip archives
MZ> in Tyr-DOS?

Used it, but didn’t pay attention to how it works there... :(

I have already decided that as long as there are identical files standing next to
each other (the first sector length should be #ff), it will be seen
as one long file.

VG> What then is the point of substituting
VG> number?

Hello, we’ve arrived - how do I know the sequence? Or do you suggest canceling
commanders with priority marking of files?
(it’s easy to make a mistake, but to restore
there will be a lot of hassle: “maybe this is the second one...
no... maybe then this one, etc.)

VG> The files should be the same.

Not at all.
(We entered a cycle ;)

[skip]

VG> used, Yes, I didn’t pay attention to how it
VG> works there... :(

Yeah, let’s invent a new wheel.

VG> I have already decided that for now there will be
VG> identical files standing behind
VG> each other (the first sector length
VG> should be #ff),

We are losing another advantage of the current standard
...

VG> to see as one long file.

[skip]

VG> And the new commander will be a thing! You'll see... :))))

Give me a screenshot, evaluate the design.

[skip]

VG> It's a good thing, I've been using it for a while.

That's not the question. Question - why?

Phrase number two. They contradict each other. No? Or do you want to redo the entire
tp-dos software?

VG> I have already decided that as long as there are identical files standing next to
VG> each other (the first sector length should be #ff), I will see
VG> as one long file.
Hmmm... The whole point is that the use of counters was “decided” 3-4
years ago. You're just reinventing the wheel now. Moreover, it looks more like a
scooter.

Good luck! Evgeny.

■ The night is shorter than the day... The day will kill me... The world of illusions burns down in it. (C) Aria.

there should not be #ff in the sectors, the main thing is that the entire last
sector of this file is filled with the necessary information, and at least one
sector

With best wishes, Max Shashkin.