Hacker News new | comments | show | ask | jobs | submit login
A Visual Defragmenter for the Commodore 64 (pagetable.com)
44 points by ingve 4 days ago | hide | past | web | favorite | 17 comments





The best part is how this will make your disc slower to use afterwards. The blocks are normally stored out of order, so that the time it takes to send the data to the computer is about the same as the time it takes for the next block to show up under the drive’s read head.

Ah the times when disc interleaving was something you could tune and see the difference in speed gain. Least early PC's that was a factor and https://en.wikipedia.org/wiki/SpinRite was born and loved by all back then.

Reading that Wikipedia article... I'm surprised SpinRite is still around.

It is my understanding that modern magnetic media really hides what's going on at the platter level. This is not like the old days with MFM or RLL hard drives (before IDE). It is my understanding the modern disk controllers maintain their own mappings, and can in fact remap bad sectors on their own. I didn't think any of this information was available at the operating system level to the extent that it can be usefully modified outside the drive's own logic.


Modern drives do a bit of remapping, but still keep a near 1:1 mapping of physical to logical sectors.

It surprises me, because the drive has much more knowledge of typical access patterns combined with the hardware characteristics, so could easily do things like store two copies of some data so that whichever is closest to the read head can be read. I guess manufacturers just aren't interested in speed optimizations anymore now that SSD's exist.



So if you can space out the data so that the blocks line up perfectly to the spin cycle ... would that help?

Yeah, that was a well-known technique at the time. 8-bit optimization was really something special. It’s crazy how much performance people got out of those tiny machines by figuring out all of these little tricks.


Love the idea, and that it fits in 49 lines of BASIC.

But isn’t this slowing things down by shoving all the data out toward track zero? I thought that for head movement efficiency and speed the ideal was to put everything as close to track 18 as possible.


What surprised me is that Commodore 64 had really "fragmentable" filesystem

> Every file is stored as a linked list. Every block holds the track/sector tuple of the next block in its first two bytes, followed by 254 data bytes.

On ZX Spectrum, TR-DOS, one of available disk OSes, didn't support file fragmentation at all: files occupied consecutive sectors, and new files could be written only to free space at the end of floppy. Once file is deleted, it continued to occupy space. Instead of defragmentation, there was "MOVE" command that packed files together by moving towards start of the disk to fill freed space.

https://www.worldofspectrum.org/pub/sinclair/hardware-info/B... (section 9.3)

(I don't know, however, how ZX Spectrum +3 filesystem works (another disk system for ZX Spectrum) (http://www.worldofspectrum.org/ZXSpectrum128+3Manual/)


It surprised me too, especially as it means you now have a rather inconvenient 254 data bytes per sector.

(The BBC Micro's ordinary disc filing system also stored contiguous files. I'd always assumed that this would be pretty standard for 8-bit systems... it simplifies reading and writing of files, and reduces the amount of metadata that needs storing.)


CP/M, without a doubt the most popular OS for Z80 based systems with disk drives, and the main inspiration for MS-DOS, was an exception:

"Files in CP/M can be thought of as a sequence of up to 65536 records of 128 bytes each, numbered from 0 through 65535, thus allowing a maximum of 8 megabytes per file. Note, however, that although the records may be considered logically contiguous, they may not be physically contiguous in the disk data area. Internally, all files are divided into 16K byte segments called logical extents, so that counters are easily maintained as 8-bit values. The division into extents is discussed in the paragraphs that follow: however, they are not particularly significant for the programmer, because each extent is automatically accessed in both sequential and random access modes".

(http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm)


Here are some other formats:

CP/M: extent map made up of directory entries. The file size is in units of sectors, but text files end with ^Z. Ctrl-M Ctrl-J is end of line.

TRSDOS (TRS-80), also used extents.

This whole extent concept came from DOS/360 from IBM mainframes.

Apple DOS: directory entry points to a linked-list of indirection sectors which hold pointers to the sectors that make up the file. The size of a file is in units of sectors, except that for text files, the end of the file is indicated with NUL. Ctrl-M is end of line.

Atari DOS: just like the C64- a linked list of sectors, but with 3 bytes of overhead per 128 byte sector (the extra byte contains the number of valid data bytes in the sector). The file size is in units of bytes due to this. End of line for text files is 0x9b. (ESC with 7th bit set).

MS-DOS: files are made of a linked-list of clusters, but the linked list for all the files are stored in one place- the FAT (nicely eliminating the need for a free-space bitmap). But if you overwrite the FAT, you lose everything!

Early version of UNIX (SCO Xenix) didn't use a bitmap for the free blocks, instead it kept them a linked list. This was a really bad idea, files instantly became fragmented.


The code is horrifying/georgeous/ingenious/insane https://www.pagetable.com/docs/defrag1541/defrag1541_source....

They are not using basic keyword abbreviations, so the code could be even worse than this listing.

This is actually better, coming 30-some years late. C64 == wine?

If I possibly can, I'm going to dust off ye olde 1541, plug it into the somewhat less dusty C64, boot it all, find a working "diskette" and see if I can't run this.

Why? For the sweet satisfaction.


This is really reminiscent of an old PC program called COMPRESS, which was a defragmenter and not a compression utility, despite the name. Neat stuff.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: