Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Commodore » Commodore Emulation » Test disks & programs for floppy drives
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Test disks & programs for floppy drives [message #389050] Wed, 04 December 2019 10:19 Go to next message
Anonymous
Karma:
Originally posted by: Vincent Pelletier

Hello,

I'm working on improving MiSTer FPGA's[1] C1541 implementation.
So far, I can get Jani's test cartridge tests to pass (300.0 rpms, fast
format works, drive functionality tests all pass).
Now that I'm accurate enough for well-behaved disk accesses, I'm
looking into being accurate-enough for copy protection checks to pass.

Do emulators have test suites, with disk images with malformed data
(mimicking copy protections) and some programs (CRT or PRG) to check how
such disks are read ?

[1]: https://github.com/MiSTer-devel/C64_MiSTer

Regards,
--
Vincent Pelletier
Re: Test disks & programs for floppy drives [message #389328 is a reply to message #389050] Mon, 16 December 2019 16:03 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Ez

https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/ drive/

Vincent Pelletier wrote:
>
> Do emulators have test suites, with disk images with malformed data
> (mimicking copy protections) and some programs (CRT or PRG) to check how
> such disks are read ?

https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/ drive/
Re: Test disks & programs for floppy drives [message #389343 is a reply to message #389328] Tue, 17 December 2019 20:01 Go to previous message
Anonymous
Karma:
Originally posted by: Vincent Pelletier

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
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: VICE X128 Windows symbolic keymap
Next Topic: LUnix on the Commodore 64
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Nov 21 08:17:40 EST 2024

Total time taken to generate the page: 0.08925 seconds