Home Page Forums MAME MAME How digital magnetic recording works

Putting this here so it doesn't get scrolled off the shoutbox, additions / corrections welcomed.

Saturation magnetic tape and disk recording works in essentially the same way. A bulk-erased piece of media is magnetized with an AC electromagnet, resulting in a random arrangement of flux transitions on
the surface. When a track is recorded, a DC erase magnet straddles the width of a track, putting the media in a known magnetic state. The write head produces alternating polarity magnetic fields which are
transferred to the magnetic surface of the media through a gap in the write head. The flux reversals in the media are later detected by using that same write head as a transformer through a differential amplifier.
That signal is low-pass filtered then passed through a differential active filter, which applies a 90 degree phase shift to the signal. That differentiated signal goes to a comparator which detects the peaks of the flux
transitions (maximum dv/dt). That pulse stream is sent to a time-domain filter which attempts to reconstruct the original FM/MFM/GCR encoded bitstream as a pulse train with fixed pulse width, which is then
further decoded into the actual stream of 1's and 0's originally recorded. Typically in recording formats with embedded clock information, a bit clock will be derived from the bitstream in the digital data separator
which often has an analog phase-locked loop in the clock generation circuit to attempt to correct for variations in the bitstream rate due to speed variations on the media.

At least, in theory, that's how it works. But the physical medium may have problems like dropouts, speed variations, and in the case of random-access devices like disks, spots where new data is recorded over
the previously laid down format for the sector, resulting in non-deterministic 'write splices'. Or, it is deliberately tampered with, as is the case when copy-protected media is produced.

This also points out the fact that a lot of analog processing has been applied to the signal coming off of the head by the time a digital 'flux-transition' timing analyzer ever sees it. In particular, the time domain filter.

Len Shustek and I did a bunch of work a few years ago recovering old magnetic tapes using analog digitization. Len made a video about it for VCF West in 2020, and the code is on gitHub
https://github.com/LenShustek/readtape

-- to be continued

It's not much and I don't know if anyone will appreciate it, but here are my thoughts on representing magnetic media.

1. Without consideration of the drive, the representation of a track of the media will consist of a certain quantity and density of cells or sample points. Ideally these are evenly spaced, either as points in time or points in space. This also defines a beginning and end of each track.
2. These cells or samples will have a value. To be represented, these will need to be a discrete set of values. Hopefully there are some thresholds that can reduce this to a smaller amount of values, although not likely that it can be reduced to a set of two values (e.g, positive, negative).
3. Run length encoding could then be used to reduce the size of the data to store.

In general, there is no "beginning" or "end" of a track. It's just a sampling of flux transitions. Where a track begins is determined by the controller that looks for certain sync marks (those could be embedded, like in GCR on the C64, or external, like the sync hole on 5.25 inch floppies). Sampling the cells directly is probably very hard if not impossible, and it is not really needed. All you need to represent are the time intervals between flux changes, and the "offset" of one track to the next, which can be determined by sampling while the head moves from track to track and then aligning to that (the head step time is usually known). If you can do half-track stepping, even better, you can use the intermediate tracks to improve the sampling of the actual tracks.

Interpreting the sampled data to determine unformatted tracks, weak bits, etc., now that is the real art, but it can be skipped by storing enough revolutions to fake the randomness.

"storing enough revolutions to fake the randomness."

No, actually it can't. the randomness is 'noise' in the read channel making it through the time-domain filter
What you need to do is flag that region of the track as 'weak'

These problems exist in software driven floppy controllers, like the Apple II. Most of the time, a floppy will
have perfectly decodable sector information, particularly when an LSI floppy disk controller was used, because
the controller would just throw a 'bad sector' error.

There are copy protection hacks in those types of controllers, like embedding a sector within a sector or
writing on a track past the last one.

Copy protection in the bane of archivist's existence. Of the thousands of disks I've archived, I have a fairly small
pile of them that I've had to wait for something like an Applesauce to analyze. But, I also have stayed away from
doing much with Apple II, since others deal with that.

I do wonder now how much PC software that I've archived that has 'sector in sector' encoding. Probably not
much, since that would have shown up in a bad track using Imagedisk, which can't handle different sized sectors
on the same track.

"In general, there is no "beginning" or "end" of a track. It's just a sampling of flux transitions."

Of course there is. If you look at the graphical representation of a digitized track on an Applesauce, you will often see the
synchronous bitstream start with the sync bits, the sectors, then noise before you come around again to the starting sync
bits where the erase head has never touched.

obviously, there are exceptions, like floppy interfaces that always record a track at a time, but even then there has to be
a small gap so the erase head doesn't wipe out the start of the track.

My thoughts are from a point of view of emulating magnetic media (e.g. disk, tape) as a sample passing under the read/write heads at a particular time. This would hopefully avoid requiring any special interpretation of sampled data, leaving this interpretation to the emulation of the rest of the drive. At issue is how much simplification can be allowed and still represent any situation that can occur with real media, while also determining if there is value to a common representation for various media amongst various computer systems.

Further consideration also needs to be given as to whether this is compatible with the means of sampling the physical media.

Yes, I understand what you mean, but there are copy protections for which this is not true, like the Vorpal copy protection on the C64 for instance. Also, if all you have are sector start marks, and factoring in interleave, you can't really tell where the track starts, as it's just a bunch of sectors, one after another. If the gap between sectors is about the same, where do you define the "start" of the track?

My point was more that there doesn't have to be an absolute position where a track starts, and that the relative position between tracks is more important than defining a particular "start of track" (e.g. for Fat Track type protections, where the head moves between tracks and the software expects to still read a valid stream of bits)

Regarding 'beginning' and 'end', I am aware that with a circular track there is no 'beginning' or 'end' inherently defined by the track itself. The point would be that for situations in which some reference was needed (likely when the head is allowed to move while reading or writing), such a representation would have a way to provide the reference.

From what I've seen, floppy drives before perpendicular recording did not have an erase head. The read/write is supposed to be powerful enough to change the magnetic orientation as needed, and slightly *behind* that head are two trim erase heads which demagnetize the disk on the sides of the track (which explains why half-tracks are usually clear and not a mix of the two neighbouring tracks). Perpendicular recording drives (the 2.88M ones) otoh do have an erase head in front of the read/write one, which required making the gaps between sector header and sector data bigger. You don't want the erase head to already be over the sector data when you just finished reading and validating the sector header for the sector you want to write.

sorry.. I was thinking about magnetic tape as I was writing that and forgot about how tunnel erase heads work on disks