'Vorpal (later) analysis'
Author:Lord Crass (guest: search)
Date: Sat, Apr 02nd, 2011 @ 01:53 ( . )

I partially disassembled the SuperCard v6 GCR copier (regular version, not SuperCard+) to see how it handles the non/CBM-auto gap format mode that you need for the newer Vorpal.

It does it exactly like it describes in the manual. It starts reading the track and tossing away bytes until it gets X number of bytes in a row (which you specify with the parameter "number of gap bytes"). Once this has been found, it skips any remaining consecutive bytes that match the gap byte and then starts reading GCR bytes into the 8k buffer until $2000 bytes have been read.

It then searches through the buffer for X number of repeating bytes (gap length), and marks a $01 after it. This is how it knows where to stop writing the track.

So, it's almost exactly the same as the Maverick Epyx copier with the following differences:

1. It doesn't go out of its way to avoid reading the entire actual track gap into the drive buffer for a Vorpal disk (which is typically 52 94 A repeating, or some bitshifted variant), which results in a longer track that requires the drive to be slowed down a bit more to remaster.

2. It copies the majority of the end-of-track byte pattern depending on what you chose for the "number of gap bytes" parameter, which means the Maverick copier would be able to copy this copy. When Maverick copies the disk, it chops off all but one byte of this pattern, which means it cannot detect the start-of-track if you copy the copy with the same custom copier, and will hang forever trying to read the track (although it should work with the generic ramboard copier due to difference #3).

3. It doesn't add the extra sync (FF FF 55) at the start of the track.

This copier also has a slight bug/anomaly that could come up if you were to copy a particular type of disc using this format mode. If the disc has two long byte patterns on it (say, d6 d6 d6 d6 d6... followed by 55 55 55 55..) then SuperCard would think the d6 pattern is the gap byte and start writing the track buffer at the $55 byte pattern. But then when it tried to detect track length in that buffer, it would read X number of bytes of the gap byte ($55) and mark the $01 right near the start of the track, leaving you with a botched copy. This happened to me in the emulator when copying a modified Maverick copy of the disc.

REPLY: [With No Quote] --- [With Quoted Text]


--- 0 Users Online --- 0 Recent Unique Posters

Q54=1660521083 - Threads: / 1660521083