| 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 |
3/19/2011 @ 21:33----SaxxonPike 3/25/2011 @ 23:27------Lord Crass --- 0 Users Online --- 0 Recent Unique Posters |