Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple
Subject: Re: MacTransGS
Message-ID: <1990Mar4.050629.25788@spectre.ccsf.caltech.edu>
Date: 4 Mar 90 05:06:29 GMT
References: <17670@boulder.Colorado.EDU> <NAGENDRA.90Mar2193644@bucsf.bu.edu> <14221@phoenix.Princeton.EDU>
Sender: news@spectre.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 30

blackman@phoenix.Princeton.EDU (Scott Michael Blackman) writes:

>Anyway, since I use this often, I have (for my own benefit as well as
>anyone else's) slimmed down the code, made it work on a IIgs, and
>have a few quick hacks to improve the useability of the program.  I've
>put out one "new and improved" version whose main improvement is that it
>works on the IIgs.  It is a quick fix to make it work on 800K MFS disks
>(yes, these creatures exist ... I've made a few).

I got a copy that gave bizarre errors when it was reading the files.
This was running on a GS.

Could you send me or post the new version? It would be more convenient
than my current method, which is to use a basic/ml hack to dump the disk
into a text file, and then run that through binscii.. newly written to
HFS disks have no fragmentation so I can read the files intact with no
lookup necessary -- just have to clean out or ignore the garbage.

Also, how do you make an 800K MFS disk? One of those would be my preferred
methoed of getting downloads from the mainframes to my room (I don't have
a 9600 baud terminal link so I have to use a 2400 baud modem or walk to
the lab, and for downloads I usually gratuitously waste time on a Mac II
and its hard drive to do so.) AFE Mac to ProDOS is slow by design, it could
have been written to write blocks without seeking track 0 before each one
(listen to it, that's what it does!).

Thanx in advance.

Todd Whitesel
toddpw @ tybalt.caltech.edu