home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Acorn User 3
/
AUCD3.iso
/
funland
/
emulators
/
c64
/
d64imagefs
/
!D64FS
/
!Help
< prev
next >
Wrap
Text File
|
1997-08-03
|
9KB
|
228 lines
D64FS - An Image Filing System for C64 disc images (V0.10)
==========================================================
This program is NOT Freeware. For more see below.
(Changes in version 0.10 see below)
Now with a native RISC OS C64-Emulator available there's the question
of how to get software for the emulator. The most common source data
are files in T64 and D64 format. The former are tape archive files
with a very simple structure, used mainly for programs that don't
load any additional files after startup. The later are byte-for-byte
copies of VC1541 disc images used mostly for programs that do load
additional files. In contrast to T64 archives extracting files from
a D64 disc image is considerably more complicated than 10 seconds
worth of editing. Therefore I chose to write this image filing system
which does the job for you and also shows why a modular OS is a
really good idea.
All you have to do is start the module (type "help d64fs" at the
command line to see if it's active) and give the disc images the
file type &164 (D64Image). This filetype, the module name and its star
commands are all registered at Acorn, therefore this release is
official.
That done you merely have to double-click on the image to open a
filer window with its contents. Accessing files is considerably
slower than with native RISC OS files. One reason for this is that
the data blocks contained in a file can be spread over a large area of
the image file. The other one is that C64 disc images don't give the
_exact_ size of a file with its directory entry (only the number of
blocks which doesn't even have to be correct). RISC OS has to know
the exact size of a file _before_ loading, however, so when loading
a file it has to be scanned first; that means the file will have to
be traversed twice, hence the delay.
Of course I might have claimed lots of RMA space for buffering but I
decided against this on the grounds that D64FS is not supposed to be
a high performance FS for everyday use but a convenient and RISC OS
compliant way of accessing this type of data. If you're doing lots
of operations on a disc image you can always speed things up a lot
by copying it into a RAM disc.
D64FS is read _and write_ so you can also copy stuff into disc images
or create new ones. The disc image size is not fixed to the standard
35 tracks but may be any value between 18 and 40 (or 70 in V0.10). If
the number of tracks lies between 36 and 40 the format used for the BAM
will be that of Dolphin DOS (that means essentially that the BAM entries
for tracks 36-40 start in Block 18,0 at offset &ac).
Discs aren't recognized if the image is less than 18 "tracks" long
(no directory track) or the first two bytes in block 18,0 are not 18,1.
I used to check for the full 18,1,65,0 as given in the VC1541 manual
but discarded that again when I came across disc images that didn't
conform with this.
Name conversions:
-----------------
This is a bit tricky since the character sets used by RISC OS and by
the C64 are rather different. You shouldn't experience any trouble if
you stick to non-accented (top bit clear) characters (with the exception
of char #152 (—) and char #156 (†) which are OK), best to keep them lower
case as well. Some CBM-characters are translated to the same RISC OS
characters, however, so there might be name clashes (for instance `.' and
<arrow left> are both translated to `_'). So far I haven't experienced any
trouble but be warned that there may be.
Filetype conversions:
---------------------
This is even trickier. The C64 knows 5 different filetypes, namely DEL,
SEQ, PRG, USR and REL. I don't think using up 5 RISC OS filetypes just
for this is a good idea and besides hardly anything but PRG is used
anyway (with the exception of DEL which is only used on empty files,
though). So I chose the following mappings (changed in V0.10):
DEL <--> &ffe Command
SEQ <--> &ffd Data
PRG <--> &064 (the filetype used by !Breadbox)
USR <--> &ffc Utility
REL <--> &feb Obey
If you copy a RISC OS file with a different filetype into a disc image
its type will default to PRG (&064).
Warning: D64FS can only write sequential files in the broader sense (everything
but REL, AFAIK). It'll still write REL files but those will be unusable on a
C64. Also reading existing ones will probably not yield the desired results.
I don't feel like changing this ATM since I never used REL files even when I
was still using a C64...
Command Line options:
=====================
D64FS offers two commands:
D64create [-t x] <filename> <discname,id>
This command creates a disc image file named <filename> with
x tracks (x between 18 and 40 or 70, default 35). The disc name (up
to 18 chars) and id (2 chars) are stored in the image; everyone
who ever worked with a C64 will know what they are.
D64tidy [-v -r -c] <filename>
This does various operations on a C64 image file. Be warned
that these operations might take some time (very much dependent
on what kind of device the image is stored on - this should be
a harddisc or a RAM disc). The aim of these operations is mostly
to discard any unused space and thus make the image file compress
better. Be warned that if the disc contains information not stored
in files this data will be lost irretrievably (-c,-r) or exposed
to overwriting (-v). Neither problem can arise with images created
by D64FS. When in doubt don't tidy up the disc!
-v Validate disc. That means update the BAM (block allocation
map), i.e. scan all files to determine which blocks are
used and which are not and write the result on the image.
This operation may be used if the BAM has been corrupted
for some reason. If the disc image contains data not stored
in files a following write-operation might overwrite it!
-r Clear unused rest of partially filled blocks. The last
block of a file is usually not filled to the end. The data
contained in the rest of the block has no purpose whatsoever
if the disc image contains only files and thus may be deleted
(i.e. overwritten with 0s).
-c Clear unused blocks. The most dangerous operation which will
fill entire blocks with 0s if they're marked unused in the
BAM. If the disc image contains data not stored in files
or a corrupt BAM data will be lost permanently so handle
with care!
If you specify more than one switch the operations will be executed
in the following order: first -v and/or -r in parallel, then -c.
E.g. -v -c will first update the BAM and then clear unused blocks.
LIMITATIONS:
------------
To keep down the workspace size the maximum number of open D64Image files is
currently set to 32. If the module complains about there being too many open
images you'll have to close some of them, for instance by typing *close at
the CLI (which closes all open files on the current FS).
The number of open files within D64 images is limited to 32 as well. This
should usually not be a problem, though, since there's hardly ever more than
one open (unless some program messed up).
CHANGES IN VERSION 0.10
=======================
1) Fixed some bugs concerning full discs: the correct error message is passed
back and a file that didn't fit entirely will be deleted automatically.
2) D64FS now can handle 1571 images as well. Those are double-sided disc-images
with a length of 349696 bytes, corresponding to 70 tracks. Unlike with the
single-sided discs there is no variation allowed here, it has to be exactly
this size. Double-sided discs can also be created with D64create and cleaned
up with D64tidy.
3) Changed the filetype-mappings a little.
4) Fixed "bug" in the directory-code that could lead to certain files not being
displayed in some cases.
KNOWN BUGS:
-----------
1) Files with zero length will take up one data block nonetheless. But that's
not really a bug since files like these are pretty senseless anyway.
2) None I found so far (...and are still present...)
LEGAL ISSUES and CONTACT:
=========================
Since Videoware failed this program's status is hereby changed to SHAREWARE.
That includes all previous versions, you can't avoid registering by not
upgrading.
You may use D64FS for a trial period of two weeks. After that time you must
either delete it or register. The registration fee is 5 UK Pounds or 15 German
Marks (if neither currency is native to you I prefer Marks). Cash or Eurocheques
are fine with me. My snail mail address is
Andreas Dehmel
Am Schorn 18
82327 Tutzing
Germany
email: dehmel@informatik.tu-muenchen.de
(for now...)
I refuse any responsibility for any kind of damages resulting from the use of
this program. So far nobody has reported anything serious to me but bear in mind
that usage is entirely at your own risk.
Happy nostalgia,
Andreas Dehmel, August 97.