tr-dos sux and must die

I was thinking about how to teach cp/m to see tr-dos disks transparently.

[...]

Or maybe someone can tell me the algorithm? (see previous letter) Well, in general terms.
What functions/parameters may be needed?

The goal is to provide
r/w access to a file described by several tr-dos files with minimal memory and time.

There is 16kb of memory _for_ _all_ both code and data: disk driver, file
system, cache.

So far I have provided:

public trinit ; hl=free mem ptr, bc=maxsize, a=max_files_opened
; -> hl=free mem ptr, a=max_files_opened

; initializing memory

public open ; hl=*name, de=mode -> hl=handle ?error
public close ; hl=handle -> hl=?error
public create ; hl=*name, de=mode -> hl=handle ?error
public stat ; hl=*name, de=*statbuf -> hl=?error
public dup ; hl=handle -> hl=dup_handle ?error
public chmod ; hl=*name, de=mode -> hl=?error
public unlink ; hl=*name -> hl=?error

public read ; hl=handle, de=*buffer, bc=size -> hl=bytes_read
?error
public write ; hl=handle, de=*buffer, bc=size -> hl=bytes_written
?error
public seek ; hl=handle, debc=offset, a=mode -> dehl=offset ?error

; It seems clear from the names

Maybe it’s worth moving seek and dup to a higher level? Then you can
refuse
from storing several handles from one file - this will reduce
the size
of the program and the memory used, but on the other hand, then a situation is possible
when the file descriptor is not in memory, I don’t know whether this is good or bad.

You also probably need to connect disks (it’s not entirely clear how...) and flush
to the disk of everything what is not recorded (is it necessary?).

Did the Spectrum writers do this? How?

* Crossposted in REAL.SPECCY

I came across some difficulties... Firstly, it is not entirely clear in what
form to represent long files (>255 sectors) on the disk. So far I have decided that
even if it is in the form of several files with the same name, the only important thing here is that
they are on the disk in the same order: the first part, the second, the third... In
the gaps
between them there may be other files, it doesn’t matter. It is only important to know which of
them
is the first, which is the second, etc... It turns out that you cannot have files with
the same
names on the disk - it doesn’t work out too well for tr-dos, I have many disks with
the same
file names. :-( But nothing else comes to mind here; storing
files
as Melon writes them is also not the best solution for another reason. The program
should
be indifferent to which disk it works with and it has the right to count on the fact

it will have the opportunity to write at the same time in more than one file. Let,
for example
the program wants to write to two files, and they are not located at the end of the disk.
It would seem an impossible task for tr-dos... But there is still a solution if for
each
file there is more than one descriptor in the directory. It is clear that the number of descriptors
pieces
of one file. will grow quickly and therefore it is more profitable for them to have only
one
file name, otherwise there will be a bunch of files on the disk with onename and
different
extensions, consisting not only of numbers (after all 9 numbers are gone, you will have to
change the letters), and files with the same names and different letter
extensions in
tr-dos are also not uncommon. There is also the problem of “holes” between files. For example, there is a file in the middle of the disk, and before and after it there are other files written on the disk. If
the program
truncates this file to a smaller size, then between this and the next file
unused space
will be created on the disk. But in the tr-dos directory between this and
the next
file there will be no deleted files and many commanders will perceive such a
disk
as containing errors. Expanding the directory to insert a deleted descriptor is not the best solution; there will always be not enough space in the directory... Moreover, when
writing to two files at the same time, it would be a good idea to reserve several
kilobytes
for each new descriptor, and this will also lead to either holes or discrepancy
length
in sectors and length in bytes. %-(
Finally, the biggest problem - we can confidently say that the concept
length
of a file is absent in tr-dos, just like in cp/m. Only in cp/m there is
an
end of text file marker, and in tr-dos it is not clear what. It’s good if in all
files
the length is in bytes reflects the actual length of the file. But there is.BASIC files whose length in bytes is much (more than a sector) less than the length in sectors, so-called monoblocks, and there are BASIC files whose length in bytes fits into the length in sectors, but the remainder of the last sector still contains the necessary information. It turns out
that
for hobet (they differ in autostart from tape) BASIC files you need
to focus on the length in sectors. But with what length parameter should we approach
other
files, and how can a BASIC file be distinguished, for example, from a *.bat file transferred from
ms-dos?
SABZH...
The file extension is also unclear - for some files
all
3 letters are used, for some only one. If you use all 3
letters in the
extension for all files, then some files will not be accessible by name at all, if
you use
one letter, then there will again be a confusion of files... :-(

There are so many AXES for the Spectrum now that I have already shortchanged
a long time ago,
is no one really looking into the subject matters have you thought about it? :-/

In the best case, I will only be able to access files with an extension
only
of 3 letters, files with the same names will be merged into one, there will be
no access to BASIC
and after writing to such a disk, no
commander will defragment it.
%-( Well, why the hell do I even need this tr-dos then? Aнадо.

* Crossposted in REAL.SPECY

And it all started on 23-Aug-00 at 16:40:02, when Kirill Frolov
talked to All about tr-dos sux and must die

[...]
KF> in bytes. %-( Finally, the biggest problem - we can confidently
KF> say that the concept of file length in tr-dos is absent exactly
KF> as well as in cp/m. Only in cp/m there is also an end marker
KF> of a text file, and in tr-dos it is not clear what. It’s good if in all
KF> files the length is in bytes reflects the actual length of the file. But there are
KF> BASIC files whose length in bytes is much (greater than
KF> sectors) less than the length in sectors, the so-called monoblocks, and there are
KF> BASIC files whose length in bytes fits into the length in
KF> sectors, but in the remainder of the latter sectors still contains the necessary
KF> information. It turns out that for hobet (they differ
KF> in autostart from tape) BASIC files you need to focus on the
KF> length in sectors.

Why not always focus on the length in sectors anyway? you can’t find out whether the program uses the data from the rest of the sector or not.

KF> But with what length parameter should you approach other
KF> files,

So forget about the byte length, finally, everything is sector-by-sector, i.e., as much as
it actually occupies on the disk, that’s a big deal..

KF> and how BASIC file can be distinguished, for example,from a *.bat file
KF> transferred from ms-dos?

Real basics usually have a second and third letter of extension not
from the standard alphabet, if at least one of them is left, and the first is #42,
that means it is.

KF> SABZH... File extension too it is not clear
KF> which one - for some files all 3 letters are used, for
KF> for some only one. If you use all 3
KF> letters in the extension for all files, then some files will not be accessible at all
KF> by name, if you use one letter, then there will again be a confusion of
KF> files... :-(

Can be calculated using the standard alphabet (well + several left
characters), if at least one last character is left, then extension
one letter, otherwise - three.
For example, A-Z, a-z, 0-9, _!$ maybe something else..

KF> In the best case, I can only get access to files with
KF> extension of only 3 letters, files with the same names
KF> will merge into one, there will be no access to BASIC no and after
KF> writing to such a disk, not a single
KF> commander will defragment it. Will they be automatic somehow?

Always yours Combin8or/PHT

YV> Real basics usually have the second and third letters of the extension not
YV> from the standard alphabet, if at least one of them is left, and the first #42,
YV> that means it.

Well, no, the file might just come across just randomly.

And how can I be like that? should I send the parameter as DOWNLOAD ADDRESS?
Through what place???

KF>> SUBJECT... The file extension is also unclear - for some
KF>> files all 3 letters are used, for some only one. If for

YV> it is possible to calculate using the standard alphabet (well + several left
YV> characters), if at least one last character is left, then the extension
YV> is one-letter, otherwise - three.

Possible. But if the download address there coincides with the letters, then again
the file name is completely wrong. :-(

And it all started on 13-Sep-00 at 02:14:12, when Kirill Frolov
talked with Yuri Voynalovich about tr-dos sux and must die

KF> You can. But if the download address there matches the letters, then
KF> again you get a completely wrong file name. :-(

So this is very rare, it’s still better than almost _always_ wrong
file name ;)

KF> I already came up with a terrible perversion: on the disk each file will
KF> be represented by two files - one normal byte file, maybe
KF> even glued together from pieces, and the second file (or several) hobetny and
KF> LAUNCH ADDRESS does not disappear! I puzzled over this for 20 days. It's time
KF> to sit down for ASM...

Hmm, come on, I wonder what will come of this..

Always yours Combin8or/PHT

YV> So this is very rare, it’s still better than almost _always_ wrong
YV> file name ;)

Why is it wrong? The desired one is always correct, and the non-wanted ones
are only for special use...

YV> Hmm, so come on, I wonder what will come of it..

Probably nothing. In general, this is for CP/M based on TR-DOS.

KF> Not suitable for me in any way! I _necessarily_
KF> be able
KF> to read files humanly - byte byte.
But on the contrary, it’s easier for a machine

KF> This is a TR-DOS disk. But I don’t have TR-DOS at all, I need
KF> bytes.
And why are you so impatient with this?

With the best, Dima Boyko.

KF>> then
KF>> is it necessary?
KF>> And it is necessary.
No one argues that TRDOS is Mazda. But it exists for the same reason on the Spectrum that Windows exists on the PC - a large amount of software and ease of use.

With the best, Dima Boyko.

DB> It is indicated by a small b :)

Well, well, all the letters are capital...

DB> No one argues that TRDOS is Mazda. But it exists for the same reason
DB> on the Spectrum that Windows exists on the PC - this is a large
DB> amount of software and ease of use.

The software is just completely useless.

KF>> be able to read files humanly - byte by byte.
DB> But on the contrary, it’s easier for a machine

I don’t care if it’s easier for a machine. It's easier for me to work with
a byte stream.

KF> The software is just completely useless.
useless for you? if so, then say so
are you sitting on the emul?

▒▒▓▓▓ ▄▀█▀▀▀ ▓▓▓▒▒░░░ Sincerely yours, Yuri /I \
▒▓▓▓ ▐▌▀█▀ ▓▓▓▓▓▓▒▒▒░░░░ Jerri / Alien Factory \ZX/

YP> is useless for you?

I only use the Max Petrov boot hardwired into ROM and MMD4.xx

YP> if so, then say so, are you sitting on emul?

Yes, I already forgot when I launched it...

Somehow Sat 23 Sep 2000 at 23:23:54 Kirill and Yuri were arguing about tr-dos sux and
must die

KF> I only use the Max Petrov boot hardwired into ROM and
KF> MMD4.xx

Since when did TRDOS start placing markers? This is not the case with her :)
03 puts ISDOS at the end of the tests, and that’s all...

threat. What is the difference between 03 in decimal and 03 in hex? ;))

Well, that seems to be all for now. Happy!

... Exactly half a sip to nirvana... (C) Spleen