On Tue, 17 Dec 2019 08:03:29 +1100, Ez <
Ez@example.net> wrote:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/drive/
Great, thanks !
Also, I made some more progress in my understanding of the drive
electronics, and I would like to post here conclusions that I do not
find mentioned anywhere.
Warning: I do not have a real drive at hand to check my assumptions
with. I only have the schematics I found online (zimmers.net, ...).
One thing which took me a long time to figure out is how a track can
contain more data than its bit clock allows.
The bit clock being: 16MHz / 300rpm / (16 - speed zone) / 4 .
For simplicity, let's define 16MHz / 5 = 3.2MHz as the flux clock
(5 being 300 rpm converted in Hz, minus the unit).
And the answer came to me once I realised that the drive never reads a
"0". It emits a zero when it times out waiting for a "1". So while
shifting a "0" takes (16 - speed zone) * 4 flux clock cycles, shifting a
"1" can happen as often as every (16 - speed zone) * 2 flux clock
cycles.
So, ignoring the analog part of the circuit, an all-sync-mark speed
0 track can contain 3.2M / 16 / 2 = 100 000 bits, while an all-zero
speed 0 track has only 3.2M / 16 / 4 = 50 000 bits.
I calculated that the first monostable pulse length is about 45 clock
cycles +/-20%, so the actual maximum number of "1" bits a typical drive
should be able to read is closer to 3.2M / 45, or around 71111 bits,
or 8888 bytes. On a drive on the slower end of tolerances it can get as
low as 7404 bytes (which would fail reading speed 3 tracks), and on a
drive on the faster end of tolerances it could reach 11111 bytes. This
is of course the un-formatted capacity.
As the monostable pulse lasts longer than slowest speed zone's half bit
clock, this is speed-zone-independent. The real-world limiting factor
besides component tolerances should be track material maximum flux
resolution.
Extrapolating to disk image format, I believe a clock-perfect disk
image would have 3 200 000 "slots" per track.
A slot can be more than 1 bit to express weak-bit information.
Constructing such image would require sampling the output of the second monostable, adding 1 to current cell on a rising edge and advancing to
the next cell at a 3.2MHz rate, reading the track 2 ** n times to
collect weak bit statistics ("n" being the number of bits per cell).
Such image would be quite large (11MB for 84 tracks at 2 bits per slot)
but compress extremely well: often <200kB gzipped, sometimes twice that.
This is of course overkill, as it allows expressing disk images the
electronics could not read (like, "1" bits closer than 32 bit clock
periods apart).
--
Vincent Pelletier
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)