'Vorpal (later) analysis'
Author:SaxxonPike (registered user: 16 posts )
Date: Mon, Mar 07th, 2011 @ 19:21 ( . )

Btw, I'm curious what exactly you did to patch the Legend of Blacksilver disks to make them work in the emulators. Did you change the code? Or just the track data?


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

'Vorpal (later) analysis'
Author:Pete Rittwage (registered user: 558 posts )
Date: Mon, Mar 07th, 2011 @ 20:44 ( . )

Just the track data has been reframed. It's the same as what Maverick does to it...


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

'Vorpal (later) analysis'
Author:Lord Crass (guest: search)
Date: Sat, Mar 19th, 2011 @ 18:24 ( . )

I took a look at the Maverick Epyx Copier for California Games to see what it does. It looks for a repeating byte pattern of at least 10 identical bytes (any byte except $55 or $AA). Once that run of bytes is complete, it skips 3 GCR bytes and then reads another 10 bytes and checks for repeat patterns of these 10 bytes.

Once the repetitions are complete, it reads in 8k of track data with a different timing routing. This routine should handle "copying" of syncs since they pre-fill the track buffer with $FF bytes, and skip over buffer bytes if a byte-ready isn't received in a cycle-specific period of time. It uses self-modifying code to alter the timing sequences in this read loop depending on the track density.

Track density seems to be set according to regular Commodore DOS rules. It doesn't change density in the middle of a track or anything odd like that.

It finds the end of track cycle by looking for that same repeating byte pattern and marking a $00 after the first byte of it.

For writing, it erases the track with $55 bytes, writes two bytes ($FF $55), then just dumps the track data to disk with a BVC/STA/CLV loop, finishing when it reaches the $00 marker byte.

This $FF $55 might be the key to reframing the data. I took a fairly quick look at the Vorpal loader drive code from California Games, and it looks for a few different bit patterns on the disk, one of them being $FF (although it seems to expect the sync bit to be set in $1c00 if it sees this, so maybe I'm wrong here).

I've attached the commented disassembly from the Maverick copier and the main Vorpal drive loader loop. The Vorpal code is confusing and I see why people had trouble understanding it.

Attachments:
1300573258_cgames-vorpal.txt


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

'Vorpal (later) analysis'
Author:Pete Rittwage (registered user: 558 posts )
Date: Sat, Mar 19th, 2011 @ 18:33 ( . )

Thanks very much for detailing this. I knew it did something strange, but never had time to disassemble and see exactly what. :)


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

'Vorpal (later) analysis'
Author:SaxxonPike (registered user: 16 posts )
Date: Sat, Mar 19th, 2011 @ 21:33 ( . )

Aha, beat me to it :) I don't know a lot about how the 1541 works so spent lots of time researching. Your disassembly is most helpful, thank you! :) The loader in LoB is exactly the same, byte for byte. Seems it uses the clock bit on the serial bus as a data bit when transferring to the C64.


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

'Vorpal (later) analysis'
Author:Lord Crass (guest: search)
Date: Sun, Mar 20th, 2011 @ 01:41 ( . )

That's the "2-bit loader" that is used by nearly every fast loader around.

V-Max uses one too. It's not the fastest, but the v-max one is nice because it doesn't disable interrupts, so music can play while it's loading, screen doesn't blank, etc.

The interesting catch on it is that it transfers the bits out-of-order to the c64 and you have to fix them up with the computer side code (or like in V-Max's case, the data is stored already rearranged on the disk and the xfer actually puts it back the correct way, saving precious clock cycles).

Here's a good article on how the 2-bit fast loader works:

[link]


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

'Vorpal (later) analysis'
Author:Lord Crass (guest: search)
Date: Fri, Mar 25th, 2011 @ 23:27 ( . )

I made a mistake in the commentary of that disassembly. In the Vorpal code, at $586-$58a, it reaches here if it read a $FF byte and branches if sync is NOT set. I originally had this the other way around (sync is set). This is due to the 1541 memory map I was using which has bit 7 of $1c00 listed as 0=data, 1=sync which is backwards. Perhaps the doc is referring to the voltage level on the actual pin instead of what the drive sees, since these are active-low.

Also, I originally wrote that the Maverick copier writes $FF $55 at the start of the track. It's actually $FF $FF $55. I missed the 2nd BVC which occurs at $099, which, absent another STA $1C01 will just write the previous byte again. So this does indeed write a 16 bit sync mark, which is how Maverick frames the track data properly. Note that the Vorpal loader doesn't look for this sync and will handle the data either way.


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

'Vorpal (later) analysis'
Author:Pete Rittwage (registered user: 558 posts )
Date: Sun, Mar 27th, 2011 @ 13:44 ( . )

Since a track cycle can not be easily found, I always figured that the framing must "float" on this track.

There must be some 3x0 bits on in different places to cause this?


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

'Vorpal (later) analysis'
Author:Lord Crass (guest: search)
Date: Sun, Mar 27th, 2011 @ 15:31 ( . )

The track gap area, perhaps? There's usually junk in the write splice that comes through as illegal GCR, and with no sync mark at the start of track the framing is likely to be off.

If you know the start of the track (after the repeating bytes in the write splice area) and the track length (up to the beginning of the repeating bytes again) and read in just this data, does it still wind up misframed at the end?


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

'Vorpal (later) analysis'
Author:Pete Rittwage (registered user: 558 posts )
Date: Sun, Mar 27th, 2011 @ 16:02 ( . )

Yes, about 1/4 of the data is good, then it gets OOF.


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

'Vorpal (later) analysis'
Author:Lord Crass (guest: search)
Date: Mon, Mar 28th, 2011 @ 00:01 ( . )

What process are you using to determine the start of the track and then load the track in?

I was looking at some original disks on a real 1541 through Maverick's track editor. Here's what I noticed:

1. The track lengths for all these no-sync tracks always seems to be the same ($1E28/$1E29).

2. If you read across the track gap, the data always shifts, but does so predictably.

3. Since there's no sync, there's no framing reference, so any track read can come back in 1 of 8 different ways. This is irrelevant to the loader and the Maverick copier. You could force it to come back with a specific pattern by using the header search feature, but that would occasionally hang for a very long time as not every pattern seemed to come up due to a timing issue. I had to lift the drive latch and drop it back down a few times before it would result in that particular arrangement and read the track.

4. The first byte after the end of track pattern (the repeating single byte) is maybe 40% of the time a bad GCR byte. This would indicate to me that this is the write splice and is the actual end of track. The repeating 20 bit pattern after this is inert gap bytes.

As long as you start reading after the gap and stop when reaching the repeating single-byte pattern, you should get a track that Vorpal can read. It will be framed in 1 of 8 ways, but it doesn't matter since the Vorpal loader will handle it. The sync mark that Maverick adds simply makes it easier to make another copy of in the future with a generic 8k nibbler or parallel copier. This mark isn't necessary for the copy to load properly, and I'm guessing the SuperCard nibbler does the same thing as Maverick, but doesn't add the bonus sync mark. Maybe I should disassemble that copier to verify.

If you blindly read in the whole track just once without waiting for the actual start of track, you'll wind up with the write splice somewhere in the middle and the track data on one side shifted one way, and the data on the other side shifted a different way. If you just try to paste this together, it's ruined.

It's interesting that there are sync marks on the odd numbered tracks at all, since analysis of the loader indicates they aren't necessary. The same load routine is used for every track, sync or not. Perhaps a technical requirement for the mastering process?

I didn't have time to try it, but you should be able to copy these syncless tracks with the Maverick track editor as well. Read in the track blind, scroll through the buffer to find the track start, then put the first 4 bytes or so in the search header and read the track in again. Scroll down to where the gap is, enter edit mode and put a $00 byte after the first byte of the repeating single-byte pattern to mark the end of track (Maverick will now show the length of the track). Ensure your drive is slowed down and write the track to your target disk. This should work as it's basically the same thing the custom copier does.


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

'Vorpal (later) analysis'
Author:hyper active (registered user: 296 posts )
Date: Mon, Mar 28th, 2011 @ 21:25 ( . )

If only there was a similar g64 editor for the pc, or a pc application that lets you do what maverick's disk editor does.


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

'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

Q226=1675908239 - Threads: / 1675908239