Interest in a DiscFerret?

[Guy Dunphy]

At 07:34 PM 9/01/2019 -0800, you wrote:
>On Thu, 10 Jan 2019, Guy Dunphy via cctalk wrote:
>>  ...
>> What other all-formats floppy R/W and data recovery tools do people here know of?
>> Comments of their functionality?
>
>A couple of questions to discuss.  Believe it or not, they are not 
>rhetorical questions.
>
>1) Do you like to re-invent the wheel?

I used to. These days with years growing short, I try to avoid such 'purely for fun' projects.
'Try', but often fail. Too easily sidetracked. But there are some things I want to do before I
get too old, and they're not all going to be possible. Sidetracks just shorten the list.

>You CAN make a better one, and have fun doing it.

Sure, I agree. I think many existing things are crap, hence the tendency to want to improve them.
But there's not enough time. Gundam Syndrome.

For _this_ project, I just want to
 1. Get my old Apple II fully working again. 
    More to that than you'd expect: http://everist.org/NobLog/20190106_hacked_appleII.htm (only just started)
    Currently setting up a logic analyzer for this. Wish I'd had one back then! 
    Now I have a choice among several. I sort of collect logic analyzers like some people
    collect scopes. I'll probably use my trusty OLD HP 1630G, just to give it some exercise.
    BTW, does anyone have any spare disassembly ROM packs for the Tek 1240? Seeking any! See:
    http://www.eevblog.com/forum/testgear/im-updating-a-wiki-site-for-the-tektronix-1240-1241-and-i-need-your-help/
    I post as TerraHertz there.

 2. Recover what files I can from all my old Apple II floppies.
    I want all of them to end up as files on a PC, with as little effort as possible.
    SOME of them I'll want to create new disks of, for use in one last Apple II project.
    Which is mostly just a demonstration of some things I did long ago.
    Not interested in simulators. The point is to demonstrate and take pics/videos of
    stuff running on that particular (highly modified) Apple II. And also to rebuild
    EPROMs for a few things.
    I do know a fair bit about the internals of Apple II disks (or rather, did)
    but now I don't much want to know. No way am I going to do manual file reconstructions
    from sector data. 
    For this pile of floppies: http://everist.org/NobLog/pics/20181001/20181223_1961.jpg

 3. Similar for the HP LIF disks. Recover the files to PC, create fresh disks exactly the same,
    post online any of the files (and/or disk images) that are not already.
    Pretty high chance most of them won't be.

    

>2) Do you want to image the disks, for later recreation of a duplicate 
>disk?
>OR
>3) Do you want to extract FILES?  (to be viewed/edited/used on PC)

Apple II:  Extract all files AND create duplicates of a few of the disks.
           All for my use. Unlikely to be much of interest to others.

HP LIF:    Extract all files (not many. I think no more than six 3.5" floppies.)
           Also create disk images for posting. So others have both the images
           and the files.


>The majority of the flux-transition products were developed around #2.
>I don't know which, if any, ever completed the software for #3.
>
>#2 and #3 are actually not mutually incompatible.
>If you make images of the raw content of the disks, you could work from 
>those images, rather than from the physical format on the disks themselves 
>for extracting files.  That is especially an issue for formats such as 
>Apple2, which can not be read by stock PC hardware.  And, if you succeed 
>in creating a 140K file of the bytes on an Apple disk, then you do not 
>need to worry about whether it will survive any more read attempts.

Sure, but for me this is only practical if tools exist to treat the image
file as a virtual disk, to read the files. I _could_ write it (would take
me months, or even years given how little time slices the project would get)
but do not have time. More urgent things take priority.

This is what I'm asking - does any such utility exist? Capture the image, and
give access as files, allowing them all to be saved as files, one folder per
original floppy. On a PC.

Another path would be a software pair, some on the Apple II and some on the PC,
with some channel between. RS232, or a dual port RAM, or whatever. This would
actually be a lot simpler for me to write. I never did have a serial card for
the Apple II back then, but that can't be hard to find.


>For example, David Small's "Magic Sac" Macintosh emulator originally used 
>MFM images of Macintosh GCR disks.  Not his first choice for a name for 
>it, but that was as close as Apple's lawyers would let him get.  Later, he 
>created "Spectre GCR" to be able to read the Mac GCR disks.
>
>If you can image the Apple disks, so that you can wade through the raw 
>content on a PC, the details of the raw physical format, the logical 
>format, and the file system are documented.  MOST of that is present in 
>"Beneath Apple DOS".

Heh. You didn't read this: http://everist.org/NobLog/20181001_missing_wave.htm#dos
And I have that book btw.

>With the GCR structure (they changed it between DOS 3.2 and 3.3) you can 
>convert, and extract the bytes, to get 13 or 16 256 byte sectors per 
>track.
>You then need to look at the data structures of the Directory (track 17?) 
>to figure out which sectors comprise each file.
>Apple DOS, PRO-DOS, P-System, and Apple CP/M each have different data 
>structures for their directories.

All my Apple II disks are DOS 3.2. When 3.3 came out, it was a) too much trouble
to convert everything up, and b) ... read that 'missing the wave' story.
It gave me a sour feeling about 3.3. Totally my own fault, but still.

>About 30 years ago, I wrote the software to extract and copy files from 
>those formats on Apple disks, using a board [made by somebody else] in a 
>PC. ("Apple Turnover", later just "Turnover" when Apple's lawyers spoke 
>up).  The publisher and vendor of the product screwed both of us.

Dear me, my sympathies. More in common. Part of this effort involves writing
up a product of mine for the Apple II 
  (an EPROM programmer, EPROM bank and battery-backed RAM card)
  See http://everist.org/NobLog/20181001_missing_wave.htm#promr
that was pretty good but got commercially sabotaged to death by a 'friend.'


>The majority, but far from all, of the other formats use MFM, with a track 
>structure that is compatible with the NEC and WD track format.  Most, but 
>not all of those can be done using PC hardware.  (Some, such as FM/"Single 
>Density" and 128 bytes per sector, can be done on some PCs and not others)
>
>Apple's GCR (it is NOT MFM) is different between AppleDos 3.2 and 3.3, and 
>is different from the GCR used by Commodore, Sirius/Victor, and some 
>others.

Ha, this I know well. Having reverse engineered Apple DOS 3.2 hardware and software
myself from curiosity. In Australia, the DOS 3.2 manuals did not arrive for a
loooong time after we got the actual hardware.
Some of the disks I want to recover contain the disassembly and my own code
from that reverse engineering, and the patches I made to DOS 3.2 to increase
the data density.

>Some file system data structures, such as CP/M, TRS-DOS, P-system are 
>documented.  Some are not.    Some claim to be documented, by telling you 
>sectors per track, bytes per sector, and what track the dirctory is on, 
>but not the data structures of it.

Yeah. I have at times done hand dissections and debugs of PC floppies and
hard disks (only the FAT varieties) but would rather not do that again.
There's a bunch of books in my library about PC DOS disk structures, and I'll
be happy to never open them again. I thought the whole thing was ghastly.
Every. Single. Improvement. was always so shortsighted and limiting. Bah.


>Oh, yes.  and, . . . 
>4) You will need to write additional code to work with the content of 
>those files if you want to load word processor or spreadsheet files into 
>any of the "modern" office programs.  Word processors, even Wordstar, did 
>NOT store the documents as ASCII text.

Sure, I know. But there's just ONE not-quite ASCII file format I'll be
converting. The Assembler I used on the Apple II was primitive, and kept source
files in a form with mixed binary and text per line. They saved a bit of space
that way. I'll want to write a converter to get them into plain text. So I can
build them with a _real_ cross compiler on a PC, if needed. 

Almost ALL the files on those Apple disks will be like that.
I have the format documented, because I disassembled the assembler and patched
improvements into it. It didn't implement all the 6502 addressing modes, for one
thing. Also lacked some important directives. It became a patched mess, but worked.
God how I hated that Assembler and it's non-ascii format. I didn't change that
annoyance, because memory space really was a critical shortage.

>
>I wrote XenoCopy, but it is NOT STILL AVAILABLE and I got out of that 
>aspect a few decades ago, so I remember some details, but not all of the 
>really important ones.  At the time, I estimated that there were about 
>2500 different floppy disk formats, and I implemented 400 of them.

That's very impressive. And you didn't put the source online for free when
you terminated the project, because...?

>Chuck did 22Disk (Sydex).  He seems to have stayed involved, had greater 
>mastery, and remembers much more than I do.
>Grumpy Ol' Fred     		cisin at xenosoft.com
>http://www.xenosoft.com


Guy