Rebonding a disengaged Amiga 3.5-inch disk and its hub

[prowler]

I am posting in this forum because you guys know as much as anyone about how floppy disks work and the subject matter is relevant to software preservation.

I have an original Coverdisk B from The One Amiga, August 1993, which was sent to me almost a couple of years ago by Pickaweapon with the Snakes full version disk for salvaging (in the Snakes! thread). The coverdisk features a demo version of the Snakes game, the availability of which contributed significantly via some amazing work by clenched to the eventually successful recovery of the full version.



On receipt, the coverdisk proved to be unreadable, so the demo version of the game used for recovering the full version was obtained from valid dumps of the disk already preserved at nthdimension and on the EAB File Server.

Closer examination revealed the reason for failure of the disk: the stainless steel hub had become detached from the disc. These parts are held together by a ring of double-sided tape, which had become unstuck.

Some time later, I cracked open the Snakes demo coverdisk enclosure just sufficiently to get the disc out so it can be reused without gluing. However, I didn't remove it because I didn't want to risk exposing it before I'd found a reliable way of rebonding it to the hub.

I have now discovered an adhesive which I think may be perfect for this task!



From the back of the pack:
"151 Fantastic Elastic Flexible Glue is ready to use and is adjustable for up to 5 minutes. The glue has a high bond strength on nearly all materials and is ideal for use on metal, glass, ceramics, mirrors, plastics, wood, leather, vinyl & fabrics. Transparent & odourless, the glue is great to use around the home for a variety of jobs.

"The unique formula makes the glue resistant to shock impact, water and extreme temperatures.

"Contains: (3-(trimethoxysilyl)propyl)ethylene-diamine"

I realize that it is absolutely essential to preserve the concentricity of the disc and the hub when rebonding them and to ensure that the disc is not inadvertently "flipped" before doing so. However, my question concerns whether it is equally important to preserve the original angular orientation of the disc relative to the index hole in the hub.

Reading Paul Overaa's BSB Insider Guide 'Amiga disks and drives', in particular the section concerning disk layout in Chapter 16 - How Disks Work, suggests that - for Amiga floppy disks at least - it shouldn't matter.

If it doesn't, is the Amiga floppy disk unique in this respect or would it also not matter for other platforms' floppy disk formats?

The Amiga doesn't read and write sectors individually because that turns out to be too inefficient. Instead, it works with whole tracks of data at once. In doing this, there is a slight problem, because when a read operation is requested, AmigaDOS does not actually know whereabouts on the track the read/write heads are positioned. Knowing that it is effectively starting at some random position, it has to make sure that all the data on that track is recovered. The first bytes of any track read will, likely as not, be halfway through a sector, so what AmigaDOS does is read slightly more data than should strictly be necessary (i.e., it reads slightly more than a whole track). The bytes corresponding to the partial read of the sector first collected in the buffer therefore get re-read as a complete sector near the end of the buffer. The buffer contents are then examined to see how far into the buffer the first complete sector begins and the buffer data is then shifted along so as to align this sector with the start of the buffer.

There's an important point about this track-based arrangement. Although a gap, consisting of a stream of null bytes, is written at the start of a track, there are no similar gaps written between the sectors themselves. When a track is first written to disk, it therefore consists of this sort of arrangement:

<nulls gap><sector 0><sector 1><sector 2><sector 3>....<sector N-1>

The single gap approach turns out to be extremely useful because, when a track is read back into memory, the read starts at some random position, so it is pure chance which sector gets placed into the buffer first. A track might be collected in the buffer in this sort of fashion:

<sector 2><sector 3>....<sector N-1><nulls gap><sector 0><sector 1>

or this:

<sector 1><sector 2><sector 3>....<sector N-1><nulls gap><sector 0>

AmigaDOS doesn't need to worry about all this while it is reading the data because it is reading the complete track. Once in memory, however, it looks at the offset value held in the header of the sector which is at the start of the buffer. If the sector offset value (i.e., the 'number of sectors till end of write' value) is 11 (or 22 for the high density format), then AmigaDOS knows that the first sector in the buffer is actually the first sector that was written to disk. All the other sectors will follow in the buffer without any gap.

In most cases, however, the gap will appear somewhere in the middle of the various sectors, and what AmigaDOS does here is look at the sector offset value and calculate the position of the last legal byte of track data (i.e., the last byte of the last sector of the track). Having done that, it searches past the null bytes forming the track gap area, until it finds the sync byte of the next sector in the buffer. Once found, it block moves the remaining data so that all sectors in the buffer are then contiguous (i.e., follow each other without any gaps).

For example, a track read into memory as:

<sector 1><sector 2><sector 3>....<sector N-1><nulls gap><sector 0>

gets re-positioned in the buffer like this:

<sector 1><sector 2><sector 3>....<sector N-1><sector 0>

This is done so that, once the sectors are physically contiguous in memory, AmigaDOS can calculate individual sector locations more easily and more quickly.

What may surprise you, however, is that when a track is re-written to disk it does not get rearranged so that the original first sector gets written first, followed by the original second sector and so on. Instead, after the initial gap containing a stream of nulls has been written, the sectors are sent back to disk in the order that they appear in tyhe buffer area. This means that a track which was first written as:

<nulls gap><sector 0><sector 1><sector 2><sector 3>....<sector N-1>

might be read into memory as:

<sector 1><sector 2><sector 3>....<sector N-1><nulls gap><sector 0>

and be written to disk in this form:

<nulls gap><sector 1><sector 2><sector 3>....<sector N-1><sector 0>

Why doesn't AmigaDOS rearrange the sectors in the buffer so that they correspond to the track as originally written? It's because it wouldn't help much - after all, the next time the track is read into the buffer area, the start position for the read will be random anyway.

What does matter is that AmigaDOS can work out the position of the gap bytes present between the first and last sectors. It can only do this if the sector offset values (i.e., the 'sectors until end of write' field present in the sector header) are valid for the sectors as they are written. Unfortunately, the sector rearrangement which occurs in the buffer invalidates all of the original sector offset information. If the track were to be written back to disk without taking account of this, the offset values, as written, would no longer reflect the true 'sectors until end of write' situation. AmigaDOS, on re-reading this track, would no longer be able to make the necessary end of track calculations required to remove the track gap and make the sector data contiguous.

The solution is easy - the sector offsets have to be changed prior to each track being written in order that the stored offset values really do reflect the current positions of sectors within the 'track'. This is just a matter of stepping through each offset field in each sector storing and decrementing the offset value as each new sector is encountered.

Even a programmer doesn't normally see, let alone deal with, these type of sector header details. Even if you use a sector editor (a program used to alter the data stored in particular sectors), it is generally only the 512 byte sector data area that you will see or be concerned with.

Rebonding this disk (the content of which is known, a valid image having already been dumped) and its hub is an ideal opportunity to test whether this method is effective.

If I can devise a reliable method of rebonding disengaged 3½-inch disks, then this will have welcome implications for recovering software which might otherwise be lost.

[Keir]

Angular orientation w.r.t. the index hole can matter, as the disk-index signal can be accessed by the CPU, and also the CPU can be interrupted by it. Most Amiga track loaders do not care about it, but some protections do check it -- some versions of Copylock for example. But you are unlikely to see one of those on a coverdisk. If it's a plain AmigaDOS disk then the angular orientation is very unlikely indeed to matter.

[prowler]

Thanks, kaffer!

I'm unlikely ever to be trying to recover a copy-protected disk which has suffered this fate, so using this coverdisk will prove whether the adhesive is effective.

I have seen a couple of posts from other forum users here since I have been a member asking what can be done when a floppy disk has separated from the hub and this test might answer that question.

If I am successful and I can find those posts again I will bump those threads up.

[Keir]

At 135 tracks per inch, it'll be interesting to see whether you can re-bond the hub accurately enough, *exactly* where it was bonded before, to within 1/135".

Bear in mind the original manufacture did not have to be that accurate, or worry *too* much about placing the hub dead centre. The "centre" is by definition wherever the manufacture process ended up placing the hub.

[BarryB]

Also just make sure the adhesive doesn't melt the actual disk, it might say it's safe for 'plastics' but test on a duff disk to make sure

BTW, did you get commission for advertising that glue?

[kipper2k]

The hub would be applied before the data was written so i don't think any slight off centre issues would be a problem as ultimately when the disk spins the tracks would be created by the heads and in a true circular pattern.

Attempting to replace the hub after the fact like mentioned could prove adventurous to say the least

[prowler]

Originally Posted by kaffer

At 135 tracks per inch, it'll be interesting to see whether you can re-bond the hub accurately enough, *exactly* where it was bonded before, to within 1/135".

Bear in mind the original manufacture did not have to be that accurate, or worry *too* much about placing the hub dead centre. The "centre" is by definition wherever the manufacture process ended up placing the hub

While it is true that I have no knowlegde of where the manufacturing process ended up placing the hub originally, I am sure that the process would not have been allowed to continue if the result was noticeably off-centre, so I am hoping that if I can rebond the hub to the disc such that it looks to be concentric once more, then that will be good enough. It could even end up being surprisingly accurate!

We shall see.

Originally Posted by BarryB

Also just make sure the adhesive doesn't melt the actual disk, it might say it's safe for 'plastics' but test on a duff disk to make sure

Don't worry, that thought had crossed my mind too.

Originally Posted by BarryB

BTW, did you get commission for advertising that glue?

No, because I'm not advertising it. If it turns out to be useless for this task, then I shall say so.

Originally Posted by kipper2k

Attempting to replace the hub after the fact like mentioned could prove adventurous to say the least

Nothing ventured, nothing gained!