Compose your message:
Email Address :
Password:
OR
Your Name :
REAL Email Address :
(PRIVATE)
Subject :
Please type in your message (no HTML codes) :
[quote]On 03/19/2011 @ 18:24, Lord Crass wrote : 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. -- [/quote]
File to attach:
(limit 250000 bytes)
SECURITY QUESTION
I had 10 oranges and then I located 9 more.
How many do I have now?
: