Subject: Image2file
Path: lobby!newstf02.news.aol.com!portc01.blue.aol.com!portc03.blue.aol.com!news.maxwell.syr.edu!newsfeed.icl.net!newsfeeds.belnet.be!news.belnet.be!skynet.be!newsfeed1.uni2.dk!uio.no!news.kth.se!tybalt.admin.kth.se!merope.saaf.se!not-for-mail
From: pausch@saafNOSPAM.se (Paul Schlyter)
Newsgroups: comp.sys.apple2
Date: 20 Jul 2000 10:02:24 +0200
Organization: Svensk Amat|rAstronomisk F|rening (SAAF)
Lines: 75
Message-ID: <8l6bmg$2v6$1@merope.saaf.se>
NNTP-Posting-Host: merope.saaf.se




 
> Paul Schlyter wrote:
> [re: Image2File]
>
>> Is the code portable? 
> 
> Unfortunately no.  Image2File is written in Yerk, an object
> oriented Forth specific to the Mac.  Well, I'll change "no"
> to "perhaps" since much of Yerk's structure has been added to
> Win32Forth, a Windows Forth.
> 
> You'd be much better off starting from scratch.
 
Well, I already did, with my FID utility, written in portable ANSI C,
which currently only handles DOS 3.3 .dsk images.  But I do have plans
to add support for some other Apple disk formats as well.
 
> BTW, Image2File
> will also read Pascal format disk images and disk images stored
> in ProDOS order.
 
Pascal and ProDOS disks store the sectors in the same order -- they also
both logically use 512-byte "blocks" where eahc such "block" consists
of two sectors on the disk.
 
Apart from that the structure of the disks are quite different, and
Pascal disks have the simplest structure (no subdirectories, files
are *always* stored in contiguous sectors, and sparse files are of
course not allowed).  But the Pascal disk format does have one quirk:
on text files, no line of text is allowed to cross a 512-byte block
border, Which means the end of each 512-byte block must contain a
"filler" to the end of the block, so the next line can start on the
very first byte of the next 512-byte block.  I experienced this
directly when I, many years ago, wrote a utility for Turbo Pascal
under Apple CP/M, which transferred text files from Apple Pascal
disks to Apple CP/M disks, to transfer those few Pascal programs I
had written under Apple Pascal.
 
 
> It extracts Applesoft files as text, ie in de-tokenized format.
 
FID converts "all" DOS file types to ASCII form: it de-tokenizes
Applesoft and Integer Basic files, it converts S-C Assembler source
files to ASCII, it converts binary files to a hex dump in Apple
Monitor hex dump format, and it clears the high bit and converts the
$8D end-of-line byte to whatever end-of-line used on the OS you're
running FID on.  "I", "A" and "B" type files are converted to ASCII
form in such a way that they later can be transferred back to Apple
II disks (or disk images) as Text files, and then be EXEC'ed back to
"I", "A" or "B" files.
 
Since both Integer Basic and S-C Assembler Source files are stored as
"I" type files, you probably wonder how FID distinguishes them.  It's
actually quite easy to do that: each Integer Basic program line (in
tokenized form) ends with a $01 while each S-C Assembler line (in
"coded" form) ends with a $00.  In some cases (e.g. Integer Basic
programs with embedded machine code, or S-C Assembler Source which
has become corrupt) this rule may not work: if so, the user is asked
how he wishes to "list" that file.
 
 
 
> Image2File can be found here:
> 
> http://www.geocities.com/oneelkruns/
 
Thanks -- I'll check it out (as much as I can... :-)
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se   or    paul.schlyter at ausys dot se
WWW:     http://hotel04.ausys.se/pausch    http://welcome.to/pausch