Re: HD-DOS+ Notes
- From: "temp44" <temp44@xxxxxxxxxxx>
- Date: 28 Feb 2006 23:03:07 -0800
Maurice Randall írta:
20 OPEN15,8,15:PRINT#15,"F-P"CHR$(2)CHR$(144)CHR$(101)CHR$(1)CHR$(0)
You're very close. The only difference is the order of the bytes.
The F-P command expects high byte first and low byte last. I know
everyone will think this is odd, however, the block (B-x) commands
basically are high byte first as well. The track value in a B-x
command can be considered the high byte and the sector the low byte.
That is why I kept the same order for the F-P command.
I understand the reason for the big endian arrangement for the block
commands, but not for F-P. The logic says that if P for relative files
has little endian order, then F-P should also, as they are both for
positioning.
Isn't the 32 byte filename extension a major compatibility problem?
No, if there are more than 16 characters in the filename, the normal
@$ or LOAD"$",8 commands will only show the first 15 characters plus
an asterisk. This lets the user know the filename is longer than 16
Yes, now I remember I've seen something similar in some pc fileserver
program for c64. I've totally forgot about this elegant solution ;-)
characters. And any software that tries to load the file will work
due to the ending asterisk. The only time this will be a problem is
when there are more than one file with the first 15 characters being
the same. It's up to the individual user to be careful with the choice
of filenames. To show the directory with long filenames:
@$L
All the other syntaxes that can be used with @$ can also be used with
@$L such as:
@$L:G* to show all files beginning with G.
The formatting of the listing is done in a way to be neatly arranged
on both a 40 column screen and an 80 column screen. Sorry about the
VIC-20, but 22 columns is just tough to deal with sometimes. :)
@$L doesn't break in the other partitions. It works just as if the
L wasn't there.
No, please not another $X hack, like the $0 was by CBM! Please use
something like "$=L", and if someone wants a really detailed list, it
could be formulated something like "$=T=L*=L" for displaying
timestamps, long filenames and detailed timestamps. And maybe add "$=H"
for hidden file display enable.
The root partition dir is an interresting idea, but why does it differ
from a simple "chroot"? Why make a separate directory for top level
directories, if one could just change the virtual root directory?
Didn't you know there is also a directory for the partitions which is
yet another directory level up? The partition directory is stored in
the system partition and is arranged just like a directory on a disk
with 30 bytes for each directory entry. Each directory entry points
to a partition. It has always been this way with the CMD-HD.
Yes, now I see it begins at sector 128 (hw) or so. I thought it's just
a table indexed by the partition number, and it's linked only for the
simple implementation of "$=P".
4GB is a huge partition. I think a way to break it up will be handy
for some people. For those who don't like it, just use the one
default root directory. You'll never have to worry about the
Master directory, just pretend it doesn't exist.
No, there's nothing wrong about changing the root directory. It was
just a design question, I think maintaining a special directory over
using the regular directory structure is just additional complexity.
It seems to me that this extended partition thing is meant mostly to
store disk image files, or for new software which can cope with the
situation. That's sad. But at least the way of handling those image
files is nice ;-)
No, you can copy files to it and then load and run them just like you
would any other partition. LOAD"FILENAME",8 and RUN works just like
you would expect.
FCOPY can copy files to/from an Extended Native partition just as well
as it can with a regular native partition.
Yes of course, first I've thought that the long filename will be a
bigger problem. Ok, it's fine now.
I've read your filesystem description document, but the byte order of
filesize is again wrong. (at least in my eyes) In regular image files
the block count is stored in the correct order, I think it should
better stay so in the new filesystem also. (I know that the partition
sizes in the partition dir are also in the wrong order, but that
doesn't count) The order of sector pointers are fine and
understandable.
.
- Prev by Date: Re: Lurkers..
- Next by Date: Re: Lurkers..
- Previous by thread: Re: HD-DOS+ Notes
- Next by thread: Re: HD-DOS+ Notes
- Index(es):
Relevant Pages
|
