tr-dos sux and must die

Press RESET immediately, All! I was thinking about how to teach cp/m to see tr-dos discs transparently. I came across some difficulties... Firstly, it’s not entirely clear in what form to represent long files (>255 sectors) on disk. Until I decided that albeit in the form of several files with the same name, the only important thing here is that they were on the disk in the same order: the first part, the second, the third... between There may be other files between them, it doesn't matter. It is only important to know which one them first, which second etc... It turns out that you cannot have files with identical names - not very good for tr-dos, I have a lot of disks with identical file names. :-( But nothing else comes to mind here, keep files The way Melon records them is also not the best solution for another reason. Program should it doesn't matter what disk it works with and it has the right to count on what it will have the ability to write to more than one file at the same time. 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 a task that is insoluble for tr-dos... But there is still a solution, if everyone file have more than one handle in the directory. It is clear that the number of descriptors pieces one file will grow quickly and therefore it is more profitable for them to have only onefile name, otherwise there will be a bunch of files on the disk with the same name and different extensions consisting of more than just digits (after all 9 digits have ended will have to change letters), and files with the same names and different letters extensions in tr-dos is also not uncommon. There is also the problem of “holes” between files. For example yes the file is in the middle of the disk, and before and after it there are other files written on the disk. If program truncates this file to a smaller size, then between this and the next file is formed There is unused space on the disk. But in the tr-dos directory between this and next there will be no deleted files and many commanders will perceive this disk as containing errors. Expand the directory to insert the remote descriptor the best solution, there will always be a shortage of space in the catalog... However more, with recording simultaneously into two files, it would be a good idea to back up several at once kilobyte for each new descriptor, and this will also lead to either holes or inconsistencies length in sectors and length in bytes. %-( Finally, the biggest problem - we can confidently say that the concept length There is no file in tr-dos just like in cp/m. Only in cp/m there is more marker for the end of a text file, but in tr-dos it’s not clear what. It's good if in all files length in bytes reflects the actual length of the file. But there are BASIC files,which or the 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 what for hobet (they differ in autostart from tape) BASIC files you need focus on the length in sectors. But with what length parameter to approach to others files, and how to distinguish a BASIC file, for example, from a *.bat file transferred from ms-dos? SABZH... The file extension is also unclear - for some files they are used everything 3 letters, for some only one. If you use all 3 for all files letters in extension, then some files will not be accessible by name at all, if use one letter, then there will be a confusion of files again... :-( There are so many axes being developed for the Spectrum right now that I’ve already been shortchanged a long time ago Has no one really thought about the subject matters? :-/ At best, I can only access files with the extension only of 3 letters, files with the same names will be merged into one, access to BASIC there won't be no, and after writing to such a disk, no one will defragment it commander %-( Well, why do I even need this tr-dos then? But I do. *Crossposted in REAL.SPECCY

Press RESET immediately, All! I was thinking about how to teach cp/m to see tr-dos discs 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, with minimal memory and time consumption, r/w access to a file described by several tr-dos files. There is 16kb of memory _for_ _everything_ both code and data: disk driver, file systems, 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 ; memory initialization 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 namesMaybe 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 dimensions program and memory used, but on the other hand, then a situation is possible, when a file descriptor is missing from memory, I don't know if that's good or bad. You also probably need to connect the disks (it’s not entirely clear how...) and flush everything that is not recorded on the disk (is it necessary?). Did the Spectrum writers do this? How? *Crossposted in REAL.SPECCY