
A Visual Defragmenter for the Commodore 64 - ingve
https://www.pagetable.com/?p=978
======
egypturnash
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.

~~~
Zenst
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](https://en.wikipedia.org/wiki/SpinRite)
was born and loved by all back then.

~~~
ansible
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.

~~~
londons_explore
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.

------
reaperducer
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.

------
ungzd
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...](https://www.worldofspectrum.org/pub/sinclair/hardware-
info/Beta128DiskInterface_Manual.txt) (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/](http://www.worldofspectrum.org/ZXSpectrum128+3Manual/))

~~~
tom_
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.)

~~~
nineteen999
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](http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm))

------
andrewstuart
The code is horrifying/georgeous/ingenious/insane
[https://www.pagetable.com/docs/defrag1541/defrag1541_source....](https://www.pagetable.com/docs/defrag1541/defrag1541_source.png)

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

------
jmull
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.

------
bitwize
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.

