Disk formatters / sector copiers

(edited to remove in-lined images)

Hi,

Slightly esoteric one here, so bare with me please (and dear lord, apologies for the huge images, I can't see a way to restrict the size of them in my post)...

A month or two back I saw someone on twitter who was taking dumps of Apple II disks and rendering them into a circle as though they were pictures of the disk. This struck a chord so I put together a little twitter bot to generate images from the TOSEC Demo collection and upload them, an example below:
image1

As time's gone by and the bot has been churning out a few images per day, I've noticed that it appears many ADF files have text in what I assume were otherwise unused bytes. For example large chunks of red in the above picture are simply "GNU!" repeated. In other images I've seen "D.O.S", "DOS", "XCOPY(DOS)" and others. I've also seen some pretty ones which aren't ASCII but appear too repetitive to be data.

Dee Groove (1990)(Sanity) "DOS"
Mindblasting Vectorballs (1989-09)(Red Sector Inc)[h Warlocks] "(W)XCOPY

The last one above is interesting:
image2

The demo itself resides in the middle of the disk, the red sections are the XCOPY text but the rest of the disk has spokes of colour coming out suggesting (to me) the disk was formatted to a formula (byte offset within the track perhaps).

So, finally, to my questions:
1) Does anyone know what formatter was used to format the RSI disk above?
2) Can anyone suggest formatter programs I could use to generate "empty" disks to see what patterns they produce? XCOPY and the standard AmigaDOS format command didn't produce anything interesting
3) Am I correct in thinking that a vanilla DOS disk has a table somewhere with which sectors are used, and XCOPY amongst others overwrites unused sectors with their tag?

Cheers,
Rob

p.s: Should anyone care, the moiré patterns are annoying, I can render the images much larger to avoid them but they breach twitter limits

[thomas]

Originally Posted by silk

Am I correct in thinking that a vanilla DOS disk has a table somewhere with which sectors are used

Yes.

and XCOPY amongst others overwrites unused sectors with their tag?

No.

When you do a low level format of a floppy disk (a.k.a. 'full format' or simply 'format'), the formatting program first formats *every* track, not only unused. During format it writes a certain pattern to each and every sector. XCopy might use the word XCopy like you discovered, the OS Format program uses 0x444f5300, 0x444f5301, 0x444f5302, 0x444f5303 and so on. So if you see DOS\0, DOS\1 and eventually DOT\0, DOT\1 and in later sectors maybe DQXM, DQXN, DQXO etc, it was done by the Format program. (I never looked and the *end* of a floppy disk too careful, so I don't know with which pattern it ends).

Only after the low-level format is done, the file system (usually OFS or FFS) initializes the disk (a.k.a. quick-format) and writes its root block and empty sector table (a.k.a. bitmap) to it. XCopy might shorten this process and write a pre-defined bitmap and root block to the disk. The OS format program truly asks the file system to initialize itself.

Should anyone care, the moiré patterns are annoying, I can render the images much larger to avoid them but they breach twitter limits

Actually they are too big already. You should upload them here as attachments and only put the automatically generated thumbnails into the post.

(Apologies again for the inlined images, I hadn't appreciated there was an alternative to the IMG tag, however I don't think it's worth attaching them and using up forum disk-space so I've replaced them with urls).

I had tried a few varieties of formatter but didn't find anything particularly interesting:
XCOPY 8 non-bootable This one shows a symmetrical (W)XCOPY pattern for part of the disk
DOpus full format (no interesting patterns)

I thought that DOpus used the standard DOS formatter but apparently not (I really should have spotted that).
WB3.0 Full Format (attached) This one, unsurprisingly, is a regular pattern on many disk renderings, thanks for the explanation (it ends 0x444F5BFF "DO[ÿ" depending upon your charset)

I'd be interesting in finding other formatters, the "GNU" one is intriguing and the one used in the RSI demo strikes me as pretty in hi-res - so if anyone can suggest formatting programs to try I'll give them a whirl

[StingRay]

Originally Posted by silk

I'd be interesting in finding other formatters, the "GNU" one is intriguing

If memory serves me right Tax (one of the GNU Design coders) created a tool especially to aid to with trackmo development but it was never spread to the public. It was most probaby used for Vox Pop too, hence the GNU markers on the sectors.

Anyway, there isn't anything really special about such ID's, many coders (myself included) used custom/self-made tools to create disks for trackmos and a lot of different ID's were used.

[Marcuz]

Fascinating images! Cool idea!

Originally Posted by StingRay

Anyway, there isn't anything really special about such ID's, many coders (myself included) used custom/self-made tools to create disks for trackmos and a lot of different ID's were used.

I agree, it's not that there's anything special about them beyond how they appear when rendered. I like that every now and then the twitter feed throws up something that looks surprisingly nice (to my eye at least), or a particular famous production appears.

Thanks for the tip, I rendered GNU Design's Skizzo Demo, large chunks of the disk are "Skiz" (the chunks of blue), although a partial-track of "DOS" makes an appearance at the end.

[Jope]

I was interested in this too when I was still actively doing my disk hasher project. Here's a few empty disks I formatted with various tools in order to be able to detect empty tracks in ADFs:

http://jope.fi/empty.zip

fmpty = ffs
impty = ffs int'l

Thanks Jope, I've rendered those locally and added Xcopy 8's bootable-dos format in as well for comparison. (I'll add a couple to the eligible set for the twitter feed)

Incidentally the images are predominantly red because obvious byte ranges are assigned a single colour (i.e. uppercase ascii = red, lowercase = blue) - the rest are from a high-contrast palette (generating a high-contrast palette for 255 values proved to be challenging, it generally resulted in a messy brown circle). http://tools.medialab.sciences-po.fr/iwanthue/index.php - this was fun to play with though