Re: CP/M .com & .arc files to apple II?

[pausch@saaf.se (Paul Schlyter)]

In article <453d1691$0$34559$742ec2ed@news.sonic.net>,
Andy McFadden  <fadden@fadden.com> wrote:

> Paul Schlyter <pausch@saaf.se> wrote:
>> You already have code which reads CP/M files, right?  Writing isn't that
>> much more complex really.  And CP/M allocated new blocks in a quite
>> simpleminded way: whenever a new block was needed, the first free block
>> from the beginning of the disk was allocated.  I think it's OK to only
>> write non-sparse new files to a CP/M disk --- even CP/M's own PIP utility
>> isn't able to transfer a sparse file from one unit to another....
> 
> Writing is more complex because, if you do it wrong, you destroy the
> disk image. :-)

Writing must be tested more carefully because of that, true -- but
that's not the reason writing is more complex.  Writing is more
complex because you may have to allocate new space on the disk - you
never need to do that when reading.  But writing isn't really THAT
more complex -- it's merely less forgiving if you do any errors.
 
> If CiderPress can't open a disk image or displays a file incorrectly, I
> can fix it.  If it subtly corrupts files in ways that don't get discovered
> until much later, I can't.

True - but you handle that situation with DOS and ProDOS disk images,
don't you?

> Adding write capability to a filesystem raises some other issues as well.
> When DOS became writable I had to deal with conversion of text files
> from ProDOS format to DOS format.  The actual conversion is trivial,
> but deciding when it should and shouldn't be done, making sure it got
> done everywhere it needed to be, and adding UI to deal with edge cases,
> took some doing.  CP/M has potential issues with text files from other
> filesystems (do they need to end in Ctrl-Z?

Only if the text file length isn't an even multiple of 128 bytes; then
you must fill the extra space of the last CP/M 128-byte sector with
something.  Digital Research filled it with Ctrl-Z.  Microsoft filled
it with one Ctrl-Z, followed by binary zero bytes to the end of the
sector as needed.  But if the length of a text file already is an even
number of 128 bytes, you don't need to add any extra Ctrl-Z at the end.

> If I find a Ctrl-Z in a DOS text file, do I need to remove/escape it?).

Positively no!  Copying any file from DOS to CP/M should just do a
verbatim copy, preserving any byte values including Ctrl-Z's.  After
all, DOS did inherit the Ctrl'Z "end-of-text-file" convention from
CP/M (in MS-DOS verison 1, file sizes had to be an even multiple of
128 bytes too, just as in CP/M.  MS-DOS 2 removed this limitation,
allowing files to have any byte length, but the Cltr-Z convention was
kept for backwards compatibility).  The only "conversion" you need to
do is to fill any remaining space in the last sector with Ctrl-Z's --
this works even for .COM files.

> At the very least it needs to be better about preserving CP/M volume
> numbers on copied and extracted/added files.  Should the "edit attributes"
> dialog morph to allow you to change the volume number?

How do you deal with the volume numbers today, when you read CP/M
disks?  Several files can have the same name on a CP/M disk if their
volume numbers are different - can Ciderpress distinguish these files
as different even though they have the same name?  And what about of
the files have several extents(*) each, intertwined with one another in
the CP/M directory?

An easy way to preserve the volume number of a CP/M file is to embed
it in the extracted file name: suppose you extract the file MYLIFE.TXT
from a CP/M disk where it has volume number 11 - the extracted file
could then receive the file name V11.MYLIFE.TXT.  If you, in Windows,
rename the file to, say, V13.MYLIFE.TXT and stores it on the CP/M
disk, it will be stored under volume number 13.  If the file lacks any
volume number indicator, just store it under volume number 0 (files
extracted from volume number 0 could also receive filenames without
any volume number indicator, which would give you some backwards
compatibility).  From the Ciderpress point of view, the volume number
can just be considered to be a part of the file name.

In the CP/M world, volume numbers weren't used much -- everyone
(myself included) almost always used only volume number 0.  The most
sensible use of volume numbers was by ZCPR (a popular CP/M command
shell replacement) which created an illusion of subdirectories,
mapping each named "subdirectory" to a volume number.  But most CP/M
users didn't use ZCPR.

When storing new files on a CP/M disk you must make sure that the CP/M
filename is legal though: it must follow the 8+3 naming convention (8
characters, a dot, 3 characters), and the characters in the filename
must be A-Z 0-9 plus a small set of special characters.  Note that
lowercase characters are not allowed in filenames on a CP/M disk.  If
you put them there anyway, the CP/M commands will be unable to find
them.  MBASIC didn't observe this: in MBASIC you could create files
with lowercase characters in their names.  But if you did, the
standard CP/M commands and utilities would be unable to find the file
- you couldn't even delete or rename it!  Unless you went back into
MBASIC and deleted or renamed it from there...


> None of this is brain surgery, but there are a lot of little things to
> get right, and a lot of testing to be done.

If you need some assistance, I'm here.....




(*)Extents was the CP/M way to handle large files: each directory
entry had, within itself, an allocation map of the file, up to some
specific size (16 kBytes in the case of Apple CP/M's 140K disks).  If
the file was larger than that, an additional directory entry was
created for that file, to hold the additional parts of the file's
allocation map.  A very long file could then have many directory
entries, however when doing a DIR, only the first directory entry was
visible.  But when scanning through the directory with your own code,
each directory extent becomes visible as its own directory entry.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/