I have files on around 50 5.25" floppy disks. Most are in the Apple II (or ][ Plus), DOS 3.3 formats. I have the Apple ][+ with 64K RAM (48K on MBd plus 16K on the Language Card in Slot 0), and the two Apple Drive ][ floppy drives. Yes, it still runs fine, and most of the floppies still work fine and will boot when commanded to boot.

I inadvertently flubbed the INIT command parameters, thus reformatting the wrong Floppy - in Drive 1 (should have been reformatting the disk in Drive 2.

The disk in question is loaded with a dozen BASIC programs I wrote in 1982-84. I lost them with the errant INIT command trying to copy the floppy, without first sticking a write-protect label on it. (OK, so Fire Me, please!) But here I am with a blank-looking floppy disk, but which isn't really blank because INIT only over-writes the Catalog header so it looks like it stores nothing. And I dearly need to get the source code from this 41 year-old floppy.

BOTTOM Line, I need to know how to enable reading the files stored without looking at the catalog listing to open files. I need a byte/bit level disk editor that displays the file contents (preferably as ASCII) so I can read what's in the disk tracks and sectors and file fragments, still 'stored' on the floppy now. What tools are available? I have "LOCKSMITH 4.1" by Jerry Pournelle, and I have other tools (COPYA, PENULTICOPY, MUFFIN, FREECAT, MASTER CREATE, and many more. Likely I have the tools I need if I can just find the right one.

  • I'm about 2500 miles from my Apple //e at the moment, so I can't check, but I think Essential Data Duplicator (EDD) and/or Copy //+ might have sector editors. I would suspect at a minimum, you should be able to copy the 'blank' disk to a 'working' disk (so you can make mistakes without further damaging the original), and use the sector editor to recreate the catalog track from scratch.
    – Geo...
    Feb 1 at 18:06
  • 1
    "because INIT only over-writes the Catalog header so it looks like it stores nothing" -- unfortunately I'm pretty sure this is not true, and INIT overwrites the entire disk with empty sectors.
    – Chris Dodd
    Feb 1 at 21:42
  • Thanks to Chris Dodd and Geo ! A lot of knowledge can be especially hazardous when, after the passage of time, that knowledge has the texture of Swiss cheese. I will bear that in mind, and pre-test every disk R/W/I/F command with dummy disks before putting anything of value into the drives.
    – JTyler2
    Feb 2 at 18:32

1 Answer 1


The INIT command directs the drive to move the head to each of the first 35 tracks in turn, and overwrite the entire contents thereof. In performing this process, the drive uses two coils: an erase coil and a a read/write coil. The erase coil is turned on at all times when the drive is writing data, it is about as wide as a track, and it forces everything underneath it to one particular magnetic polarization. The read/write coil is just behind the erase cable, and is slightly narrower than it. A current driver attached to that coil is pulsed on and off to write data; when it is on, it will force everything underneath it to the polarization opposite the write coil.

If anything were written on the disk on tracks beyond the first 35, such information would likely be unaffected by init. If one recognized immediately after typing an INIT command that one had made a mistake, data on tracks that had not yet been erased would likewise be unaffected. If the drive on which the INIT command was executed had an unusually weak erase coil, and the head alignment of the drive that executed the INIT was very different from that of the drive that had previously written the data, it's vaguely conceivable that there might be magnetic domain remnants from the earlier data, but they would certainly be too faint to read using a stock drive, and it's likely that all of the magnetic domains on the disk's surface that had previously held data have been saturated by the erase head.

There are some kinds of disk corruption which would not be recoverable with a stock drive, but might be recoverable with specialized equipment. Unfortunately, overwriting via INIT command is not one of them.

  • supercat, Thank You! Although I had hoped for an answer more in line with my optimistic (and gravely misunderstood) nature of the INIT command on Apple ][! Now that I know how Hazzardous INIT is to Floppy Disk data, I will very liberally apply the write protect tab covers and Carefully Review in Every Gory Detail the Syntax and Semantics of the INIT command and all its ilk. So it seems I'm SOL with all the code on that disk. Most of the contents were BASIC apps source code, supplied by Apple and partners. There were 6
    – JTyler2
    Feb 2 at 18:16
  • 2
    @JTyler2: To make the risk more apparent, DOS 3.3 will ignore the presence or absence of a space between a command and a file name; almost any command entry that starts with the letters "INIT" will be treated as an "INIT" command. Also, while I don't think this caused as much data loss as INIT, any access to memory address $C0EF which occurs while a drive is spinning will immediately turn on the write/erase circuitry unless a write-protected disk is in the drive.
    – supercat
    Feb 2 at 19:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .