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-tektr…
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