| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Fri, Nov 18th, 2011 @ 22:15 ( . ) |
I have finally had a chance to step through Tass Times to completion to see if it does any additional copy protection checks after startup, and can verify that it does not. With my 36 track D64 image, I made it to the end of the game without any problems. Side 1 of the original floppy included an XEMAG fat track. Side 2 was not copy protected. To run the program in VICE, true drive emulation must be enabled. Also NTSC mode should be selected. It will work in PAL, but the title tune will play too slowly (HVSC file is NTSC). Either setting for the CIA chips, old or new, works. When my 36 track D64 image of side 1 is run under VICE (x64sc v2.3), the drive slews to track 35, then to 35.5 and back to 35 before continuing to load the program and showing the title screen. After a bit, it requests insertion of side 2 and then starts the game. Side 2 is then used for the entire game. When I try to run it as a 35 track D64, the drive slews to track 35, then to 35.5 and then to 36 and hangs. I have not been able to get the D64 image to start on either CCS64 v3.8 or HOSX64 v1.0.7.2 (after padding to 40 tracks). They hang just after start up (at track 35 for CCS64) and never reach the title screen. I have also made two G64 images, one with only full tracks, and one with all half tracks. Both G64s work identically in VICE. With these, the drive slews to track 35, then to 35.5 and then to 36 and then continues to successfully load the program. CCS64 only works with the half track image. HOSX64 does not work with the full track image and does not support the half track image. I have looked at the D64 image of my backup floppy and verified that it matches the original. I never made a NIB of the backup. I have not tried to get under the hood and don’t know why a 36 track D64 satisfies the copy protection check under VICE, but not under the other emulators. For EA’s Music Construction Set with a fat track, a G64 image is required to run it under VICE and even then it takes two full loading passes to satisfy the check. Hyper active, making another floppy backup of the original is still on my to-do list. I will post the results when I finish it. Lord Crass, I don’t believe VICE actually does read half tracks correctly. It does work with fat tracks (at least sort of), but I believe that is just sends the data from the nearest full track. It works the same with fat tracks whether or not the half tracks are included in the G64 image. I have made them both ways. For a little more on this, see my comment in the thread “Fat tracks in emulationâ€. |
 | Author: | Nate (guest: search) |
|---|---|---|
| Date: | Sat, Nov 19th, 2011 @ 22:55 ( . ) |
I thought it's quite clear why this works in VICE: the track is ordinary DOS format, written across both tracks 35 and 36. VICE automatically aligns tracks to sector 0 (if they are regular DOS) and so the protection sees what it wants when it bumps heads between tracks. If this was the EA protection or Rapidlok, the track 36 data would not be valid DOS sectors (just plain GCR) and the value would not be correct in a D64 image. |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Wed, Nov 07th, 2012 @ 20:06 ( . ) |
Hello there. I was lucky enough to get my hands on a xemag game from Microprose, Decision in the Desert. The fat tracks do read properly on a 128d machine, however, if I make a copy with nib tools and load the game, it dies on my 128d machine but still works on my c64. I tried an experiment, I measured the size of tracks 35 and 36 from the original, and then measured the size of the backup copy written out by nib tools. Running NibRead on the master tracks 35 and 36 of the original was 6233 bytes and running NibRead on the copy was 6260 bytes. The drive motor on My 1541 seems to be permanently stuck on 299.60 rpm and won't go any faster until the drive has been switched on for a while. The slower the drive motor runs, the larger the tracks will get when you write them out. Using Fast Hackem, I ran their fat track writer on my c128d with built in 1571 drive. The drive seems to run slightly over 300rpm. It took 3 or 4 tries at it but in the end, the protection was able to pass when I loaded the game on both machines. I ran nibread on the backup copy again and this time each track was 6543 bytes long. Only 11 bytes difference, but still enough to pass on both machines. Moral of the story, If you want to write back a xemag game to play on real hardware, make sure your drive runs at just over 300rpm, then use fast hackem's fat track writer. You may have to repeat this procedure several times and then load your game to see if the protection passes. I tested my copy on 2 xemag games, ocean ranger and decision in the Desert, and it took several goes on my c64 with 1541 to get the fat track check to work. It doesn't pass every time, but it will if you keep trying, as I said earlier, it might take 2 or 3 attempts. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Wed, Nov 07th, 2012 @ 22:35 ( . ) |
just a short addendum, make sure you make use of the IHS or the timed alignment switch when using nib tools to write out t35 and t36 or else fast hackem's fat track formatter will ruine both tracks. btw: If I try fast hack em's fat track maker on my c64 with 1541, the second track gets formatted (zeroed out), you may get different results. I had better luck when I used my 128d to do it. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Nov 13th, 2012 @ 23:13 ( . ) |
Hmmmmm. This copy of f15 strike eagle uses fat tracks on t6-t7. Unable to get it to pass on my 128d, it has some stuff on it which is overwritten by fast hack'em's fat track formatter, I'll need an original to play with, giving up for now. |