| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 01:25 ( . ) |
I've been curious about the 2nd level protection checks on early V-Max games like Defender of the Crown. This is the one that's triggered when you go raiding or jousting. The game loads data from track 11 which signals a load to the protection code on track 18. It then iterates over tracks 12-18 checking each for a number of things: 1. Finds the 10 byte sector 0 GCR header and checks the next four bytes after it. 2. Verifies that the header ends in GCR byte $AF before the next sync mark. 3. Verifies that the header length is 17 bytes (not including the $AF byte). 4. Verifies that the first data byte after the sync mark in the data block is GCR $55. This check fails for me in Vice even though the byte in the file is correct. Changing the last sync byte to a $55 so that there's 2 $55 bytes in a row causes it to pass though. Maybe a timing error? 5. This last one I'm not entirely sure about. It seems to count the bytes in the header block again, using a different method. It reads 8 header blocks, totals the byte reads, divides by 8, and stores it in a table. It repeats it again for the same track, does some math with it against the previous value, and stores it back in the table. You wind up with a table of 7 values (tracks 12-18). These values are then checked. Track 18's value must differ from all of the others, and some others must be the same, some different. On my copy in Vice, tracks 12-17 are all the same, and 18 is different. So this check fails. Maybe someone can look at this code and figure out what its purpose is? Is there supposed to be bad GCR in here that causes the drive to read back a different number of bytes each time? Maybe something emulators don't yet support? I've attached the commented disassembly since it doesn't seem to display properly in the forum. The section of interest for #5 is $0239-$024a (calls the check) and $076a-$07a9 (the check itself). I'm not well versed on 1541 internals, so I may have misinterpreted some of of the instructions, leading to my confusion. Also, in-memory patching of the $55 byte problem and the byte counter allows the protection to pass, but then it goes back to track 12, loads for a few seconds, then crashes. So the investigation isn't yet finished. |
Attachments: |
| 1299479100_dotc-vmax.txt |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 16:20 ( . ) |
Really nice sleuthing so far- hopefully the author will come back and answer you. :) |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 19:02 ( . ) |
it might die on emulators, but can the current nibtools remaster it properly? Thanks. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 16:26 ( . ) |
Since there are two tracks that read cycles of over 8k bytes, I am thinking there is either an odd GCR pattern here being interpreted as longer than they are (shifting "illegal" GCR) or else it really could be some data is written at a different speed (density) on these originals on those two tracks. This "two long track" protection shows up on several disks dating back to Star Rank Boxing and some of the Activision titles. Oddly, some work and some don't. See 'Howard the Duck' as it has these long tracks and still works (unless there is a logic time-bomb in the gameplay somewhere) |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 19:52 ( . ) |
Whoops, I botched the LDA $1c00/BPL analysis of the byte counting routine. It's not counting header bytes, it's counting sync at the start of each header (assuming there's no short sync marks in the middle of the data, which my dump lacks), starting with the 2nd header block. I still have to analyze the track skip routine, but other than that the only density change I see in the protection routine is at $025c, where it switches density to %10 before it reads track 18. I can't recall if this is standard density for V-Max on that track. Of course, this doesn't rule out the possibility that some of the data was written at a density that differs from the rest of the track, under the assumption that it's supposed to be read back incorrectly. I don't believe I can verify this without checking this on a real c64/1541 with original disk. Would counting the same sync marks multiple times on a real 1541 result in a different count? Just wondering why they read it twice? I'm guessing it might also be the reason they average the values from 8 sector headers; to compensate for drives that have inconsistent speeds. Also, why would mnib have an issue with reading the sync lengths incorrectly? Or is it an issue with the emulator not reading them right from the image? .8:076a 20 2C 07 JSR $072C ; Search for header block .8:076d 90 06 BCC $0775 ; branch if we found the requested header .8:076f A9 02 LDA #$02 .8:0771 A4 18 LDY $18 ; track number .8:0773 38 SEC .8:0774 60 RTS .8:0775 A0 00 LDY #$00 .8:0777 84 0E STY $0E ; variable. sync count total .8:0779 A9 20 LDA #$20 .8:077b 85 2D STA $2D ; variable. Max number of retries. .8:077d A2 00 LDX #$00 ; initialize sync count to 0 .8:077f 20 8B 02 JSR $028B ; Find next end-of-sync .8:0782 B0 EB BCS $076F ; Branch if not found in time .8:0784 AD 00 1C LDA $1C00 .8:0787 10 FB BPL $0784 ; branch if reading data byte (loop until sync found) .8:0789 AD 00 1C LDA $1C00 ; sync-count loop .8:078c 10 0A BPL $0798 ; branch out of loop if data byte. .8:078e E8 INX ; increase sync counter .8:078f D0 F8 BNE $0789 ; check again as long as we haven't read too many syncs .8:0791 C6 2D DEC $2D ; sync counter overflowed past $ff. Decrease $2d counter (starts at $20) .8:0793 D0 EA BNE $077F ; repeat until $2d is 0. .8:0795 38 SEC .8:0796 B0 D7 BCS $076F ; if we had to repeat the above section >$20 times, fail out. .8:0798 8A TXA ; transfer the sync count to acc .8:0799 18 CLC ; clear carry .8:079a 65 0E ADC $0E .8:079c 85 0E STA $0E ; keep a running byte count whenever theres <$ff syncs in a header .8:079e C8 INY .8:079f C0 08 CPY #$08 .8:07a1 D0 DA BNE $077D ; repeat to get 8 values .8:07a3 4A LSR A .8:07a4 4A LSR A .8:07a5 4A LSR A ; divide result by 8 to get average header sync length .8:07a6 A4 18 LDY $18 ; place track number back in Y .8:07a8 18 CLC .8:07a9 60 RTS |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 20:51 ( . ) |
Syncs are only "read" by counting cycles during the sync. The drive goes into "free fall" from the time the 10th bit occurs and the end of a sync mark. We aren't reading real $FF bytes during this time, just inserting them into the stream according to density and cycle counting. For that reason, we also run into motor speed, belt drive flutter, etc. That's probably why it measures it twice during protection check. So it is possible that the sync length is wrong, and very much probably is. Arnd Menge has tweaked this code to be much closer now- it did lose a bit here and there before. I will reread an original and see how different it is. Also, VICE is inaccurate in sync counting as well, so what works on a real drive may be off in emulation. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Tue, Mar 08th, 2011 @ 02:19 ( . ) |
I've looked at the code a bit more, fixed some misconceptions, and added some more of the code with comments. The drive head movement routine does indeed set the density for each track based on a simple 2 value lookup table. Density %10 for track 18, density %11 for all other tracks. There's also some weirdness at $03bd that might allude to what VMAXX posted earlier about the stepper motor wait time. Still can't get the game to load properly after fooling the checks though. It zips back to track 12 again and loads for a few seconds and crashes. Perhaps the sync values are sent back to the c64 and checked again. I haven't looked at the c64 side of the code at all yet. |
Attachments: |
| 1299568764_dotc-vmax.txt |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Mar 09th, 2011 @ 01:10 ( . ) |
A-HA! I finally figured it out. The protection code is loaded into the $700 buffer of the drive by the C64 and executed. This copies it to $200 buffer and runs from there. However, after the code executes and does it's 5 checks, it goes back to track 18 and the C64 uploads ANOTHER block of protection code to execute. This one is short, but nasty! It goes back to good old track 12 again, finds the sector 0 header, then skips to the sync mark of sector 1 header. It counts this sync length using the VIA timers in $1804/$1805 since the old BIT/BMI isn't accurate enough, then compares it to a predetermined value. It does this for the next 255 sync marks! Takes about 2-3 seconds to run on the track. The drive then gets one last small block of data into $700 from the c64, and it copies it to $120 and we're done. The game loads the raiding section starting at track 24. So in total all these extra-level protections probably add an extra 8-10 seconds to the load time. Crazy. The first round of protection checks can probably be passed if remastered correctly. I doubt the exact sync count can be. This is likely why it was always patched out. Vice would probably be able to emulate this if it were cycle exact (apparently 2.3 is, not sure if that also applies to the 1541 emu code as well). Lots of fun looking at this one! And I never even looked at the c64 side of the code yet... Attached is the updated disassembly with comments. The extra $700 sections are at the bottom. |
Attachments: |
| 1299651028_dotc-vmax.txt |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Mar 09th, 2011 @ 20:35 ( . ) |
Good news, Vice 2.3 fixes the bug in this protection where reading the $55 byte after the data block sync resulted in the byte after it being returned instead. It doesn't require the cycle-exact version either. I'll see if I can modify the sync lengths in the G64 to get the protection to pass. This might not be possible as the timing is very specific with maybe a +/- 2-bit margin for error. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Mar 09th, 2011 @ 22:08 ( . ) |
Naturally, the amount of sync I need to add amounts to 4 bits. Is there a way to add a nibble of sync to a G64 image? Would it require adding a $F0 to the end of the existing sync and then bit shifting the rest of the track back into those lower four bits? If so, is there a G64 editor out there to make this easier? My hex editor doesn't really do this properly. Is it possible to use speed zones in the G64 image to alter the read speed of the sync marks? I tried this, but either I edited the wrong bytes (modifying these files by hand is a real pain), or it just plain doesn't work. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Mar 10th, 2011 @ 08:20 ( . ) |
On 03/09/2011 @ 22:08, Lord Crass wrote :
Naturally, the amount of sync I need to add amounts to 4 bits. Is there a way to add a nibble of sync to a G64 image? Would it require adding a $F0 to the end of the existing sync and then bit shifting the rest of the track back into those lower four bits? If so, is there a G64 editor out there to make this easier? My hex editor doesn't really do this properly. : : Is it possible to use speed zones in the G64 image to alter the read speed of the sync marks? I tried this, but either I edited the wrong bytes (modifying these files by hand is a real pain), or it just plain doesn't work. : -- Just add it to the beginning - i.e. change the last byte before the sync to $5f or something (or change according to what is already there, this data is almost always expendable). I don't think any emulator knows about speed zones- they can't interpret the byte-aligned data given to them with a different density. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Mar 10th, 2011 @ 11:09 ( . ) |
Not in this case. On DotC, it checks that the last byte in the header gap before data block sync is $AF, the byte after the sync is $55, and it checks that the length of the header block is a non-standard 18 bytes. It verifies the length of every sync mark on the track as well. The data sync currently looks like this in the G64, but it's about 4 bits too long: AF FF FF FF FF 55 |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Mar 10th, 2011 @ 14:15 ( . ) |
Ah, nasty. Harald was very thorough. :) In that case, you would have to reframe the whole track. I don't have code to do that, although I have routines to shift all the data right or left a certain number of bits. The bigger issue here is that the data must be byte-aligned to store in G64 format. If we just shift 4 bits, then all the data is wrong after that. It won't work since it's not treated as a bit-stream by the emulator, but a byte-stream. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Mar 10th, 2011 @ 16:29 ( . ) |
Ah, too bad about the byte alignment requirement. This pretty much precludes any proper emulation of precise sync lengths. Other than this, is track-sync the only other limitation on G64 as far as unhandled protection schemes go? On a related note, Vice 2.3 now supports weak-bit emulation. I tested this with the Paperboy original image in GameBase64 and it works like a champ. |
 | Author: | SaxxonPike (registered user: 16 posts ) |
|---|---|---|
| Date: | Tue, Mar 08th, 2011 @ 18:37 ( . ) |
VICE is inaccurate in a strange way, some disks will only boot a fraction of the time they are run. However I've found that HOXS64 has no troubles loading these disks every time. I don't know which of these programs is truly more accurate. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Mar 08th, 2011 @ 18:51 ( . ) |
How does nibtools rev 493 deal with reading or remastering these tracks? can these tracks be remastered properly at all? Thanks. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Tue, Mar 29th, 2011 @ 23:55 ( . ) |
Checked out the secondary protection check on Bop'n Rumble (Mindscape V-Max version). Similar to the Defender of the Crown secondary check, but it's in a smaller package and loads differently. Instead of the code being uploaded to the $700 buffer from the C64, it's contained in a regular V-Max sector. Every V-Max sector is executed as code once loaded into drive memory. So, normally the sector starts with a short routine which begins with a JSR to send the data payload to the C64, then sets the pointers to the next track and sector in the file chain and continues along. When Bop'n Rumble loads track 8 sector 15 into drive memory at $200, it's the full protection check code there instead of a sector to send back to the computer. It searches for the sector 0 header, then verifies that the sector gap bytes match a certain signature leading into the sync mark. It then does the strict sync length check on 38 consecutive sync marks. This is where it fails on emulators due to the odd length it's expecting. When it fails, it corrupts the current track pointer so the drive thinks it's on track 12 instead of track 8. When the next track seek happens, it winds up on track 20 instead of 24, fails loading, and retries constantly. Commented protection code attached. Put a Vice monitor breakpoint on 8:$218 before loading the game if you want it to break at the protection routine and take a look. |
Attachments: |
| 1301456953_bopnrumble-vmax.txt |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, Mar 30th, 2011 @ 08:44 ( . ) |
Hi LordCrass, Have you ever looked at Star Rank Boxing? The original release is the very first V-MAX release and the image still doesn't work on emulators (or remastered). I can send it to you if you don't have an image. -Pete |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Mar 30th, 2011 @ 10:46 ( . ) |
No, I haven't. I only have an original of Star Rank Boxing II and haven't been able to find the first one. Is a good copy of it in the extras of GB64 v05? If so, I'll have access to it. If not, you can email me a copy. Also, do you have protection-intact G64s of Black Magic and Force Seven? I wanted to check out the DataSoft protection on those, but GB64's extras versions are d64. Likely Star Rank Boxing is another sync length check. That seems to be a popular one on the earlier titles. Damn effective too. I wonder why they dropped this trick. Maybe too many customers had drives running at different speeds which wouldn't pass the check? |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Mar 30th, 2011 @ 23:30 ( . ) |
Star Rank Boxing pulls all the same tricks that Defender of the Crown uses, although the code is arranged a little differently and it checks the tracks in the opposite direction (18 down to 12 instead of 12 up to 18) When looking through this, I realized that I made a mistake in analyzing the DotC protection routine that I thought was checking sync lengths on tracks 12-18 and then comparing to each other. It seems to be checking cycles spent between sync marks, but discarding the value and moving to the next sync if it rolls over $FF, which will happen in a data block. So the only place I see it pick up a valid value is when it's checking the time between sync marks in the header block. So unless there's some tiny sync embedded in the data block, this would have to be checking only the header lengths. I'm unsure as to why they would differ, considering each header length is checked to match a length of 17 bytes prior to this. Maybe the mastering is such so that the density is slightly altered for each header, thus affecting read time? This routine results in a $0B value for every track 12-18, and this is the protection check that ultimately fails. This game also does the strict sync check using the VIA timer for track 12. Oddly enough, this check passes in the emulator. Likely because it's not as strict as DotC. DotC allows for a range between $70-$90 for the result, and Star Rank Boxing allows for $60-$90. Other than those checks, it ensures that the header gap bytes match a specific pattern, and that the header gap ends in $AF before the sync. Plus it constantly checks that you haven't modified the drive kernel routines or the reset vector pointer. Attached is the mostly commented code. |
Attachments: |
| 1301542011_starrankboxing-vmax.txt |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Mar 31st, 2011 @ 01:04 ( . ) |
I accidentally analyzed the V-Max V1 version of this game, not the V0 version you were looking for. Attached is the basics of the code for the V0 version. Same old tricks. First block of protection code will check byte before data block sync, number of bytes in header, number of bytes in data block on all tracks from 17 down to 1. These checks pass fine. Another block of code is uploaded to the drive and it scans from track 1 up to track 19 reading the header lengths using that cycle counting method, then averaging 8 values for the track. It stores the 19 values in a table and the C64 retrieves them and does some comparisons on them. Failure locks up the computer. This is the check that fails. The C64 code can be fixed up to pass this check. Not sure how to fix the actual header lengths in the image though, or if it's even possible. |
Attachments: |
| 1301547864_starrankboxing-vmax0.txt |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Mar 31st, 2011 @ 01:31 ( . ) |
I was just thinking about the long tracks on some of the V-Max titles. It's not just that some tracks are long, some are short too. For example, here's the V-Max V1 version of Star Rank Boxing when converting from nib to G64: Writing G64 file... 1.0: (3:7796) [] (7796) (fill:$55) {badgcr:7} 2.0: (3:7798) [] (7798) (fill:$55) {badgcr:5} 3.0: (3:7798) [] (7798) (fill:$55) {badgcr:4} 4.0: (3:7797) [] (7797) (fill:$55) {badgcr:3} 5.0: (3:7794) [] (7794) (fill:$55) {badgcr:4} 6.0: (3:7799) [] (7799) (fill:$55) {badgcr:1} 7.0: (3:7797) [] (7797) (fill:$55) {badgcr:3} 8.0: (3:7799) [] (7799) (fill:$55) {badgcr:5} 9.0: (3:7801) [] (7801) (fill:$55) {badgcr:2} 10.0: (3:7798) [] (7798) (fill:$55) {badgcr:5} 11.0: (3:7802) [] (7802) (fill:$55) {badgcr:8} 12.0: (3:7798) [] (7798) (fill:$55) {badgcr:6} 13.0: (3:7803) [] (7803) (fill:$55) {badgcr:2} 14.0: (3:7582) [] (7582) (fill:$55) {badgcr:35} 15.0: (3:7582) [] (7582) (fill:$55) {badgcr:38} 16.0: (3:8024) [trunc:96 ] (7928) (fill:$55) {badgcr:228} 17.0: (3:8023) [trunc:95 ] (7928) (fill:$55) {badgcr:230} 18.0: (2:7147) [] (7147) (fill:$55) {badgcr:9} 19.0: (2:7147) [] (7147) (fill:$55) {badgcr:6} Notice that: 16/17 are the longest (and therefore the most dense?) tracks 12/13 are not as dense as 16/17, but are more dense than 14/15 18 is the least dense. This comes into play if you look at the code that checks the header length table. The values are compared in the same manner above, in pairs, with track 18 being completely different. Here's the V-Max V0 tracks from 1-20: Writing G64 file... 1.0: (3:7790) [] (7790) (fill:$55) {badgcr:0} 2.0: (3:7791) [] (7791) (fill:$55) {badgcr:0} 3.0: (3:7780) [] (7780) (fill:$55) {badgcr:0} 4.0: (3:7571) [] (7571) (fill:$55) {badgcr:0} 5.0: (3:7787) [] (7787) (fill:$55) {badgcr:0} 6.0: (3:7782) [] (7782) (fill:$55) {badgcr:0} 7.0: (3:8039) [trunc:111 ] (7928) (fill:$55) {badgcr:0} 8.0: (3:7788) [] (7788) (fill:$55) {badgcr:0} 9.0: (3:7782) [] (7782) (fill:$55) {badgcr:0} 10.0: (3:7789) [] (7789) (fill:$55) {badgcr:0} 11.0: (3:7571) [] (7571) (fill:$55) {badgcr:0} 12.0: (3:7782) [] (7782) (fill:$55) {badgcr:0} 13.0: (3:7790) [] (7790) (fill:$55) {badgcr:0} 14.0: (3:7788) [] (7788) (fill:$55) {badgcr:0} 15.0: (3:8023) [trunc:95 ] (7928) (fill:$55) {badgcr:0} 16.0: (3:7785) [] (7785) (fill:$55) {badgcr:0} 17.0: (3:7790) [] (7790) (fill:$55) {badgcr:0} 18.0: (2:6939) [] (6939) (fill:$55) {badgcr:0} 19.0: (2:6941) [] (6941) (fill:$55) {badgcr:0} 20.0: (2:6946) [] (6946) (fill:$55) {badgcr:0} Tracks 18/19 are the shortest, 4/11 being the second shortest, 7/15 the longest, everything else is in between 4/11 and 7/15. The C64 code that checks the header lengths compares these different length tracks against each other (track 19 against track 1, track 7 against track 4, 15 against 11, etc) A track with more data on it would therefore have the bits packed closer together and result in a shorter cycle count within the header, no? Unfortunately, impossible to verify with the current emulators. You'd have to upload a modified subset of v-max drive code that does this check and saves the values for you to read. Or on a real C64 with an original Star Rank Boxing and a monitor cart, you could set a breakpoint at $5f97 and check the values at $010B-$0119 to get them for that title only. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Mar 31st, 2011 @ 22:25 ( . ) |
Superstar Ice Hockey (Mindscape V-Max V1 version): Header & density check tracks 12-18 after title screen. Checks again when starting a game, then also checks sync length on track 12 (strict like DotC) Championship Baseball: Header & density check 18-12 after credits, VIA timer sync check ($60-$90) on track 12 (sync passes on emu). Exactly the same as Star Rank Boxing V-Max V1 version (Activision) Disk Busters V2.0: Not entirely sure why it crashes yet (might be a bad copy), but loader is V-Max, stored on track 1. Contains text at $35C: V-MAX! (TM) CBM LOADER.....COPYRIGHT 1985,1986 HARALD SEELEY.....ALL RIGHTS RESERVED |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Fri, Apr 01st, 2011 @ 00:32 ( . ) |
a lot of those v-max dumps are quite old. Has anyone tried redumping them with the current nibtools? if possible, could someone redump DOTC and superstar ice hockey to see what happens to these long tracks? Thanks. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Fri, Apr 01st, 2011 @ 12:01 ( . ) |
I think the dumps themselves are fine and redumping wouldn't yield any additional information. There's 2 problems here: 1. This protection simply won't work in current emulators because they don't have any concept of density and its effect on the time it takes a byte to be ready at $1C01 in the emulated 1541. Therefore this protection doesn't get the different timing values it's expecting. 2. Remastering this cannot be done in one pass when using a 1541. I did some rough calculations, and you *should* be able to reproduce this density change by altering the drive speed for each special track, then writing that track to disk. For example, with the Star Rank Boxing V-Max V1 example I gave a few posts up, the special tracks are 14/15, 16/17, and possibly 18. If we take 12/13 as "standard density at 300RPM", then we get tracks 14/15 being 2.8% less dense, and 16/17 being 2.9% more dense. Track 18 might be standard as well, you'd have to use nibtools to see what the track capacity is and see if matches. So if you write the whole disk at 300RPM, then rewrite tracks 14/15 at 308.4RPM, and 16/17 at 291.3RPM (Pete, are these speeds realistic for the 1541 or will you run into some limitation?), then you should probably be able to pass this protection check. The sync length check on track 12 might be a little trickier though. As long as the sync stored in your image is close enough, you might be able to sneak a successful check in by altering the drive speed that you write that track with a little faster or a little slower, but you'd need to know what timer value is coming back from the protection in order to know which way to adjust the speed. Also, if you adjust the speed of track 12 too much, you'd also need to adjust the writing speed of 13-17 accordingly as well. The protection doesn't check for an exact value when it counts the cycles when reading the header. It simply compares the values between the tracks to ensure that they differ in specific directions. So as long as you can get that criteria to match while still being able to get readable data from the disk, you'll pass the check. All in all though, it doesn't seem worth the effort involved. You're better off using something like KryoFlux to reliably write back a protection like this. |
 | Author: | Nate (guest: search) |
|---|---|---|
| Date: | Fri, Apr 01st, 2011 @ 17:08 ( . ) |
On 04/01/2011 @ 12:01, Lord Crass wrote :
I think the dumps themselves are fine and redumping wouldn't yield any additional information. : : There's 2 problems here: : : 1. This protection simply won't work in current emulators because they don't have any concept of density and its effect on the time it takes a byte to be ready at $1C01 in the emulated 1541. Therefore this protection doesn't get the different timing values it's expecting. Might be worth adding this + different track skew values to VICE. Right now, it aligns on sector 0, which works form some but not all schemes. : 2. Remastering this cannot be done in one pass when using a 1541. I did some rough calculations, and you *should* be able to reproduce this density change by altering the drive speed for each special track, then writing that track to disk. : : For example, with the Star Rank Boxing V-Max V1 example I gave a few posts up, the special tracks are 14/15, 16/17, and possibly 18. If we take 12/13 as "standard density at 300RPM", then we get tracks 14/15 being 2.8% less dense, and 16/17 being 2.9% more dense. Track 18 might be standard as well, you'd have to use nibtools to see what the track capacity is and see if matches. : : So if you write the whole disk at 300RPM, then rewrite tracks 14/15 at 308.4RPM, and 16/17 at 291.3RPM (Pete, are these speeds realistic for the 1541 or will you run into some limitation?), then you should probably be able to pass this protection check. The sync length check on track 12 might be a little trickier though. As long as the sync stored in your image is close enough, you might be able to sneak a successful check in by altering the drive speed that you write that track with a little faster or a little slower, but you'd need to know what timer value is coming back from the protection in order to know which way to adjust the speed. Also, if you adjust the speed of track 12 too much, you'd also need to adjust the writing speed of 13-17 accordingly as well. : : The protection doesn't check for an exact value when it counts the cycles when reading the header. It simply compares the values between the tracks to ensure that they differ in specific directions. So as long as you can get that criteria to match while still being able to get readable data from the disk, you'll pass the check. : : All in all though, it doesn't seem worth the effort involved. You're better off using something like KryoFlux to reliably write back a protection like this. -- First, my main hope is that people will patch up the .nib files (say by increasing sync length) to match as closely as possible what the code expects. This way they will work unchanged in emulators once better drive support is added. Also, it would be nice for nibwrite to work for as many schemes as possible, but that's secondary. Since you can only write a byte at a time, we can't do bit-timing. The only variables we have there are drive speed, density setting, and clock speed (2 Mhz for 1571). Perhaps nibwrite could be tweaked to be able to master patterns like you describe using some set of those parameters. But if not, let's focus on analyzing the schemes and patching up the .nib files and let other systems like Kryoflux do bit-accurate mastering. -Nate |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Fri, Apr 01st, 2011 @ 18:02 ( . ) |
sorry I should have made things a bit more clearer. My redump request wasn't meant to try and test if nibread could dump it better so that it would work on emulators, I just wanted to find out if it could be remastered with nibwrite with the right details so that it could be played on the real thing. Both Nibread and nibwrite have been optimized a bit since DOTC and the other v-max titles with the special tracks were dumped several years back. A good example of this is Sinbad and the throne of the falcon. Although there don't appear to be any special secondary checks in this game, previously the tracks were unable to be written back to the disk properly because they were sync-less. After a redump with a more recent version of nibread last year, I was able to successfully remaster the game and get it up and running. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 00:35 ( . ) |
It should be remasterable with the current nibtools, provided you adjust the speed of your drive properly for each of the checked tracks. No update to nibtools can improve this since the software cannot adjust the speed of the drive motor or the rate at which data is written (past the usual density setting). |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 01:55 ( . ) |
but in the old dumps the tracks are too long, just over 8k, and even if you do manage to slow your drive down to 290rpm, the track will still truncate. It will not let you write anything if it detects your drive is below 290rpm. That's why I thought the new nibread would do something different with the tracks so that they can be remastered at a slower speed without any truncation |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 02:40 ( . ) |
How much is truncated? It might be ok if it's just useless gap bytes being left out. You should be able to get all the actual sector data written on the track, since even a software nibbler with a standard 300RPM speed could do this. I don't think the protection is too picky either. It averages values all over the place, so I guess it's anticipating some differences. As long as there's a measurable difference from the other tracks... Only way to find out is to try it. I'm guessing you'll still get caught by the track 12 sync check though. Easiest way to tell on a real C64 is to listen to the drive and watch the screen when you choose the "go raiding" option (assuming this is Defender of the Crown). If you're failing the density check, you'll hear it clicking as it reads tracks 12-18 over and over again. When it fails track 12 sync check, it'll pause for about 2 seconds on one track, then reset the computer. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 05:42 ( . ) |
it's not DOTC, it's superstar ice hockey |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 07:06 ( . ) |
Tracks 16 and 17 are very long and impossible to remaster without some truncation, even at 290rpm. Tomorrow I'll test superstar ice hockey and remaster the long tracks at 290rpm and let you know if I get anywhere. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 12:06 ( . ) |
Superstar Ice Hockey has the same track layout as DotC (12/13 are normal, 14/15 are short, 16/17 are long, 18 is normal) 12.0: (3:7809) [] (7809) (fill:$55) {badgcr:5} 13.0: (3:7808) [] (7808) (fill:$55) {badgcr:4} 14.0: (3:7598) [] (7598) (fill:$55) {badgcr:4} 15.0: (3:7594) [] (7594) (fill:$55) {badgcr:4} 16.0: (3:8051) [rsync:99 trunc:24 ] (7928) (fill:$55) {badgcr:4} 17.0: (3:8052) [rsync:100 trunc:24 ] (7928) (fill:$55) {badgcr:4} 18.0: (2:7157) [] (7157) (fill:$55) {badgcr:4} I still have to look at these long tracks to see what "extra" data on them is making them so long. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Apr 03rd, 2011 @ 02:00 ( . ) |
I only had a bit of time with the C64 today, but I was able to try writing one of these long tracks with a 1541 (with Maverick's track editor though, not nibtools). My assumption about 308RPM/291RPM was based on a regular track being 7800 bytes. This is incorrect. At maximum density setting, the drive spec says it writes 307692 bits/sec. 307692 / 5 / 8 = 7692 ($1E0C) bytes per track This makes the problem even worse though. The Track Editor read in track 16 as being $1F76 bytes. I was able to adjust the drive speed to write a track this long, and it did write that track back, but when re-reading it with the track editor, it seemed to take longer to read the copy than the original. The resulting data looked correct, but perhaps this borders on unreliable depending on your diskette quality. So, $1F76 (8054) bytes on a track is an increase in capacity of 4.71% 300RPM * 0.953 = 286RPM for tracks 16/17 Tracks 12/13 are 7806 bytes in length. In fact, tracks 1-13 are typically written at the same density. To achieve this density on a copy: 7692 / 7806 * 300RPM = 295.6RPM Tracks 14/15 are 7598 bytes in length: 7692 / 7598 * 300RPM = 303.7RPM And track 18 is handled by V-Max as standard density for that speed zone (285714 bits/sec = 7143 bytes per track). V-Max is showing 7156 bytes on this track, which is close enough to standard, so this track is written at 300RPM) You can reduce syncs and track gap bytes for 16/17 as the protection doesn't check sync length on them. This should reduce the track to about 7908 bytes which could help you from overwriting the start of track. You still need to slow the drive down to about 286RPM though to get the proper density. If nibtools won't write to a drive that slow, perhaps you can modify the source to either adjust the limits, or remove them entirely. It's in the write.c file. The line is if( (motor_speed > 310) || (motor_speed < 290)) Or, if you don't have the dev tools to compile nibtools, but you're handy with a hex editor, you can try modifying the binary nibwrite.exe. Search for: 00 00 91 43 Replace with: 00 80 8E 43 This will change the lower RPM limit to 285, which should be sufficient. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sun, Apr 03rd, 2011 @ 03:05 ( . ) |
Yo! thanks for that! appreciated! |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Apr 03rd, 2011 @ 03:18 ( . ) |
I got the sync length to match properly for Bop'N Rumble in the G64 image, which now allows the game to run and pass all protection checks unaltered in Vice. Not sure if this will work remastered due to some timing/density differences. For track 8, all of the syncs need to be: AF FF FF FF FF FF The $AF byte should already be there, so just make sure there's 5 $FF bytes after that. The sync check is looking for a return value of $70-$90, and this sequence comes back right in the middle with $80. I believe this same pattern should work for all of the V-Max V1 and V2 titles that use this sync length check, although most of the others check it on track 12. The only differences I've seen in the check is how strict it is. Some allow a result of $60-$90, most are $70-$90. I tried this before and was unsuccessful. Not sure why it worked now. Perhaps I was accidentally modifying the wrong track before. Did I mention hex editing g64 and nib files is an error-prone pain? |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sun, Apr 03rd, 2011 @ 23:51 ( . ) |
Hello Your dump of superstar ice hockey is obviously different to mine. Here are the details of tracks 12 through 18 from the dump I have. 12.0: (3:7800) [] (7800) (fill:$55) {badgcr:1} 13.0: (3:7799) [] (7799) (fill:$55) {badgcr:0} 14.0: (3:7589) [] (7589) (fill:$55) {badgcr:0} 15.0: (3:7589) [] (7589) (fill:$55) {badgcr:0} 16.0: (3:8050) [rsync:102 trunc:20 ] (7928) (fill:$55) {badgcr:0} 17.0: (3:8050) [rsync:102 trunc:20 ] (7928) (fill:$55) {badgcr:0} 18.0: (2:7157) [] (7157) (fill:$55) {badgcr:0} Can I have yours? Maybe I'll have better luck with it. Thanks. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Mon, Apr 04th, 2011 @ 03:05 ( . ) |
Ah. this is more like it. someone sent me a better copy. The only problem I have with it occurs when I go to start a game. I think it's the track 12 checker that kicks in. At least it's a bit further than the part just after the title screen and song where I was previously getting stuck. I'll work on it later tonight. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Apr 04th, 2011 @ 04:33 ( . ) |
Yes, that would have to be track 12 sync check. The other protection would have gotten you right after the Mindscape credits screen. That's good news though! It means you beat the density protection check. I wasn't sure if that was going to work or not. Did you try changing all of the sync marks in track 12? In a typical dump, they're all uneven. In an emulator, the sequence "AF FF FF FF FF FF" passes successfully, although when I did some calculations on what the drive code does, I came up with a longer sync mark. Only way is to try it. You need ALL of the marks to be the same. If the above mark doesn't work, try inserting another FF byte or two at the end of it. The check routine is lenient to about +/- 5 bits of sync. It's a pain in the neck, I know. Wish there was a G64 editor that allowed you to do tasks like this easily. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Mon, Apr 04th, 2011 @ 05:54 ( . ) |
you could try using the maverick disk editor from within an emulator with better drive emulation, like Hoxs or ccs64. or you could do what I do and extract each individual track with the hidden raw-dump mode option. just create a folder named "raw" under your main nibtools folder and then type nibscan filename.nib or filename.nbz each track is extracted in to a file like this: tr1.0d3, tr2.0d3, tr3.0d2, tr4.0d1 etc. which brings me to my next question. When you say "all of the sync marks on track 12" are you talking about the first 4 or 5 af ff ff ff ff marks at the very start of the file? or are there more sync marks I need to fix up which are deeper in the file. Thanks. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Apr 04th, 2011 @ 06:22 ( . ) |
If I recall, that track should have 42 sync marks (21 sectors on the track, with a sync for each header and data block) and you need to change all of them for that track or the protection will fail when it hits one you haven't fixed up. Watch out for sync marks that wrap around the track end/start in the image. You'll see FF FF FF FF 52 54 at the start of the track, but make sure the last byte of the track isn't sync as well (or the AF byte. So if your track starts with the sync and without the leading AF byte, just insert it. These are pretty much standard DOS sectors, so it shouldn't be much of a problem like some discs where you have 100 sync bytes in a row. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Mon, Apr 04th, 2011 @ 07:16 ( . ) |
Is this the sort of thing you mean? If it's wrong, are you able to fix it for me? Thanks. |
Attachments: |
| 1301915807_tr12.rar |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Mon, Apr 04th, 2011 @ 19:11 ( . ) |
It works..... sort of. on my c128, the drive makes horrible click click bzip bzip bzip bzip noises after the title screen, but on my c64, the game loads, and after the main selection screen I am able to pass the sync check on track 12 and play the game. Lord crass, if you have a c128 or c128d, Are you able to test the game and see if it will load properly? Thanks. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Apr 04th, 2011 @ 19:41 ( . ) |
I do have a C128, might take a day or two before I can get to it to test it though since it's at my brother's place. My current drive that I use for nibtools (a 1571) is acting up. The last few disks I imaged came through with a slew of errors where there shouldn't have been any, so it's likely got a dirty head, or is out of alignment. In order to alter the drive speed, I'll have to hook up my 1541 anyways. I tried Bop'N Rumble on my 1541 Ultimate and it worked great (the game crashes if you have the REU turned on though), but trying to use Maverick to copy that G64 from the 1541U to a real 1541 didn't result in a working copy. Maybe be a density issue since 1541U uses Vice's drive emulation core. I also tried the new 2.0 firmware that allows you to write to G64 images. This failed miserably and I wound up with a G64 file that was only 264KB in size. Other people have reported bugginess with G64 write support as well. Too bad. Hopefully this gets fixed up at some point. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Apr 04th, 2011 @ 19:26 ( . ) |
You missed one sync mark. I fixed it up and also cleaned up the end-of-track a bit (removed the bad GCR and reduced the gap so that the original track length of 7809 bytes is retained). |
Attachments: |
| 1301959578_tr12.rar |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Wed, Apr 06th, 2011 @ 01:32 ( . ) |
Thanks mate. Even though I missed one sync mark and left the end of the track uncleaned, the game still works. Not bad for someone who can't see, eh? |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Wed, Apr 06th, 2011 @ 03:36 ( . ) |
Hmmmmm. Just tried rewriting track 16 and 17 again. I tried to load it up it on my c128. This time it passes the density and header check on track 12 and 18 after the title screen, it then attempts to load the Menu but after reading in the first 6 tracks, the drive motor kicks and thrashes and makes an awful racket. Think cyan loader but 10 times worse. After a while I had to cut the power for fear it would break the drive. No such trouble on the 1541 and c64 however. Here's hoping it's not a drive alignment issue. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Apr 06th, 2011 @ 14:09 ( . ) |
Are you using a different drive with your 128? Try hooking up the c64's 1541 to your 128 and see if there's a difference. V-Max has a checksum for every sector and if the checksum doesn't match, it will attempt to load the sector again and again (10 times I believe). This tends to produce horrible noises as the head tracks back and forth between track 18 and the track that has the requested sector. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Wed, Apr 06th, 2011 @ 17:46 ( . ) |
Um.. Can you tell me how I do this? When I plug the drive in and type load"*",9,1, it says device not present. When I use ,8,1 it says file not found, but both drives activate at once. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Apr 06th, 2011 @ 18:04 ( . ) |
Disconnect the 1571 or whatever other drive it is you have connected. Or do you have a C128D with the internal 1571? If it's internal and can't easily be switched off, you need to change the device numbers. You can do it through software: 1. Turn then 1541 off. 2. Run the following commands to set the internal drive to device #9 CLOSE 15: OPEN 15, 8, 15 PRINT #15, "M-W", CHR$(119) CHR$(0) CHR$(2) CHR$(9+32) CHR$(9+64) CLOSE 15 (note that the CHR$ entries are all part of that second line which starts with PRINT #15) 3. Try getting a directory from a disk using the new device number LOAD"$",9 4. Turn on the 1541. It should default to device #8 and there shouldn't be a conflict as the internal drive is now #9. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Wed, Apr 06th, 2011 @ 20:41 ( . ) |
got it! the program loads up without any problem, I can start the game, it passes all sync checks and header checks. Were you able to test out the original on your 128d with internal drive? Thanks. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Apr 06th, 2011 @ 21:12 ( . ) |
Not yet. I only have access to a regular C128 with external drives (1541, 1541-II, 1571), not a C128D. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Apr 17th, 2011 @ 11:55 ( . ) |
I've linked this thread into the V-MAX! protection description on the site. Lord Crass- if you ever want to compile your finding in article form, I'd be glad to augment/replace my original findings from 2005. You have gone deeper than I have into it, so you have better insight into the versioning. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Apr 17th, 2011 @ 21:42 ( . ) |
I still need to disassemble and comment the loaders for V-Max versions 2, 3, and 4. V2 looks similar to V1 except for the actual sector read routine, while 3 is quite different. Once this is done, I'll clean it all up and format it into something presentable. |
 | Author: | Fungus (registered user: 20 posts ) |
|---|---|---|
| Date: | Sun, Apr 24th, 2011 @ 07:54 ( . ) |
I have done the v-max 2.x load from three stooges, I would be glad to contribute it, it's very well commented. Aside from that, what do I need to patch in v-max 2 (earlier) to make it function in vice 2.3. Specifically Side Arms I am trying to get to work again. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Apr 24th, 2011 @ 23:40 ( . ) |
Sure, it'd be nice to see someone else's take on the code as I'm sure I've made some mistakes here and there (I used Sinbad as my base for V2). I still have to look at the C64 side of the code, although I'm pretty sure it's mostly the same as V1. I'm almost done with V3 and V4. Some heavy use/abuse of the stack in that one, but a very nice DOS it is. Simple, elegant, and flexible. Sidearms is checking the lengths of the sync marks on track 4 and again on track 6. The sync marks on those tracks need to be: Header block sync: 2B FF FF FF FF FF Data block sync: AF FF FF FF FF FF I've disassembled and commented those earlier secondary protections for all titles that had them. Attached is the one for Sidearms. Since this same sync check is used frequently, it's only lightly commented in this particular disassembly. I've documented it more thoroughly on the Defender of the Crown version. |
Attachments: |
| 1303702686_sidearms-vmax1.txt |
| Author: | Fungus (registered user: 20 posts ) |
|---|---|---|
| Date: | Wed, Apr 27th, 2011 @ 22:51 ( . ) |
Kewl thanks for that. Can you pass me your email? I'd rather not post some stuff in public. I don't know if there is any PM system here, I don't think there is... well anyways mine is fungusn0 at (no freaking spam from bots and trolls) gmail dot com. |
| Author: | Fungus (registered user: 20 posts ) |
|---|---|---|
| Date: | Thu, Apr 28th, 2011 @ 00:44 ( . ) |
Ok I tried to patch sidearms s1, and it passes the track 4 check, but still fails on track 6. Can you tell me what I did wrong or why it still fails? I triple checked that all syncs are the right size, and I also checked to make sure the gap bytes were correct which it checks. |
Attachments: |
| 1303965891_sidearms_s1[capcom_1987](vmax2)patched.zip |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Apr 28th, 2011 @ 02:41 ( . ) |
The 17th sync mark was one byte too long. However, something else happened because after I fixed that, the sector checksum kept failing and it would load the track over and over. This track has a different byte for the end of data block which also starts the next sync. It's a $7F. However, the protection passes if you use 7F FF FF FF FF as that header block sync mark and AF FF FF FF FF FF for the data block sync mark, so that's what I did since it meant changing fewer entries. I've attached a fixed up image. |
Attachments: |
| 1303972861_sidearms_s1[capcom_1987](vmax2)-working.zip |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Apr 28th, 2011 @ 03:03 ( . ) |
Eh, don't use that last one. It doesn't work reliably. It was working for 3 or 4 loads in Vice 2.3 but then it failed. 2.3 has some timing issues I've noticed. But in 2.2 it fails consistently. A 39-bit sync mark is too short for this protection. I've replaced all those $7F sync marks with the 2B FF FF FF FF FF version and it worked every time for me in Vice 2.2 and 2.3. |
Attachments: |
| 1303974172_sidearms_s1[capcom_1987](vmax2)-reliable.zip |
| Author: | Fungus (registered user: 20 posts ) |
|---|---|---|
| Date: | Thu, Apr 28th, 2011 @ 10:36 ( . ) |
Thanks much! will you shoot me an email so I can pass that disasm work on v-max v2 also? =] |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Apr 28th, 2011 @ 11:30 ( . ) |
I sent you an email the other day, but if you didn't get it, my address is lordcrass {at} hotmail dot com. |
| Author: | Fungus (registered user: 20 posts ) |
|---|---|---|
| Date: | Thu, May 12th, 2011 @ 23:46 ( . ) |
Can someone redump side 2 of this game? It has some errors. Unable to find some block headers on tracks 25 and 29, and maybe more. I can provide a tool to check if it works. |
| Author: | Fungus (registered user: 20 posts ) |
|---|---|---|
| Date: | Fri, May 13th, 2011 @ 16:22 ( . ) |
Never mind previous post, I just made an error in my tools, disk images are working fine. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, Jan 17th, 2013 @ 01:40 ( . ) |
Good Evening Today I finally got ice hockey up and running on my 128d with internal drive by converting the flux stream to g64 with dtc, then writing the long tracks from the g64. You'll need a maverick speed controller fitted to your drive or a way of slowing down the drive motor without too much jitter and flutter to remaster these big tracks, or else the tracks will become mangled. If this happens, you'll often get mixed results. My 1541 seems to be a bit more forgiving than my c128d when the game checks the tracks, on the latter machine, the head would thrash and shake like mad. |
 | Author: | Hyperactive (guest: search) |
|---|---|---|
| Date: | Tue, Oct 22nd, 2013 @ 01:16 ( . ) |
That was a band aid solution to convert the tracks from KF to g64 then write back the long tracks with nibwrite, but it worked. Now I have a Kryoflux device, which does all the hard work for you. Oh well, it's been a fun protection to play with. You have to hand it to Harald though, he really was on top of his game with his anti-piracy system. We had to overcome not 1, not 2, not even 3, but 4 obstacles in order to copy the game The loader code on track 20, the check for extra drive ram, the short and long tracks, and the sync check on track 12. Of course, no game stayed uncrackable for long, but I'm guessing it kept the hackers and crackers busy for long enough for Cinemaware to rake in a decent amount of money. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, Dec 21st, 2017 @ 18:00 ( . ) |
On Infiltrator II mission 1, the following edits must be made to pass the sync length check track 21: Header block sync: 2B FF FF FF FF FF Data block sync: AF FF FF FF FF. track 13: Header block sync: 2B FF FF FF FF FF Data block sync: AF FF FF FF FF FF. (Same as superstar Ice Hockey). Curiously, nibtools v587 is the only version that is able to capture track 21 correctly, but none of the versions I have can successfully capture the right number of syncs for track 13. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Dec 26th, 2017 @ 00:32 ( . ) |
Whoops, sorry, MY MISTAKE, Both the header block and data block for track 13 should be AF FF FF FF FF |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, May 23rd, 2018 @ 13:45 ( . ) |
On 12/21/2017 @ 18:00, hyper active wrote :
On Infiltrator II mission 1, the following edits must be made to pass the sync length check : track 21: Header block sync: 2B FF FF FF FF FF : Data block sync: AF FF FF FF FF. : : track 13: Header block sync: 2B FF FF FF FF FF : Data block sync: AF FF FF FF FF FF. : (Same as superstar Ice Hockey). : Curiously, nibtools v587 is the only version that is able to capture track 21 correctly, but none of the versions I have can successfully capture the right number of syncs for track 13. -- Interesting, I will have to see why... |