| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sat, Oct 15th, 2011 @ 23:32 ( . ) |
Hi there. I am having trouble trying to get xemag protected disks up and running on a c128d with in built drive. I need some brave volunteer to help me conduct a little experiment. If you have a c128d, could you dig out your original xemaged disk (not a remaster) and try loading it up? If the game loads successfully, could you send me the disk via post so that I can test it out on my equipment? I promise I will return the disk to you intact. Thanks. |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Oct 16th, 2011 @ 12:57 ( . ) |
You will not be able to get copies of 'fat track' protected disks to work on a 1571 (or 128D with 1571 built-in). Originals will work fine. You can't properly write a fat track with any Commodore drive, as it is not able to write the 3 consecutive tracks perfectly-aligned. The middle track will always be erased. Oddly, some of these protections will pass on a 1541 with the motor slowed to 298 or below. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sun, Oct 16th, 2011 @ 20:24 ( . ) |
I've never needed to slow my 1541 down to 298rpm while loading up a remastered xemag disk. It's only on my 128d that I strike trouble. |
 | Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Mon, Oct 17th, 2011 @ 20:16 ( . ) |
The only xemag disk that I have is "Tass Times in Tonetown". I never had any problem running the original or my backup copy on my C126D. The fully runnable copy I use in emulators is just a 36 track D64 with the extra last track being all zeros. I don't think that it does any protection checks other than verifying that track 36 is formatted. I have attached a zip of the D64s for both sides. You could try to write it to a floppy and see if it works. |
Attachments: |
| 1318896995_Tass_Times.zip |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Oct 17th, 2011 @ 20:43 ( . ) |
Tass Times doesn't seem to do a very thorough check of the protection- in fact it always passes. I wonder if the time bomb is later in the game? |
 | Author: | Mayhem (guest: search) |
|---|---|---|
| Date: | Tue, Oct 18th, 2011 @ 14:05 ( . ) |
I think it is... I vaguely recall someone saying that the game screws you over at some point if it fails the copy protection checks in loading. Could be wrong, or misremembering... |
| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Tue, Oct 18th, 2011 @ 18:27 ( . ) |
Back in the day, I played Tass Times to completion on my C128D. I know that I used my backup copy. I aways put my originals away in a safe place as long as I was able to make a working backup. When I was scanning my collection, I compared the data between my original and backup and they matched. I don't know if my backup sucessfully reproduced the fat track. Once I had a clean image, I trashed the backups and only kept the originals. Pete, I sent you a full half track scan of the original. I suspect that it only did a minimal check of the protection. I will try to step through the 36 track D64 with a walkthrough to see if I can get to the end. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Oct 18th, 2011 @ 21:09 ( . ) |
which program did you use to make a backup? Thanks. |
| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Sat, Oct 22nd, 2011 @ 14:32 ( . ) |
I am not absolutely sure. My preferred backup program was Copy II 64/128 v4.0, but I also used Fast Hackem v4.1a. I also preferred to use two 1571s, the C128D internal and one external. When I get some time (it will be a while) I will try to copy it again on real hardware and see it I can get it to work. I started to step through Tass Times using a walkthrough, but the walkthrough was not perfect and I messed up along the way. Maybe later today I will get a chance to finish stepping through it starting from my last save. It takes a while even with a walkthrough. When it starts up, it does move the head to 35.5. WinVICE (x64sc v2.3) does not support half tracks so it is probably sending the program data from track 35. After starting up, the game floppy must be flipped to side two, which is not copy protected. To have a time bomb later in the game, it would have to require that it be flipped back to side one, possibly at the end game. I used the following WinVICE settings: True Drive Emulation enabled, required; 6567 (NTSC), optional—allows music to play at correct speed; 6526A (new), not sure, but many games don’t work with the 6526 (old) setting. The D64 image does not work in CCS64 v3.8. |
 | Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Oct 24th, 2011 @ 21:12 ( . ) |
I believe Vice does support half-tracks. FAT tracks do work from g64 files in Vice. The issue was always imaging them properly. You can simply use a parameter from Fast Hack'em or Maverick inside of vice to recreate the FAT track. Most of these do recreate the protection instead of cracking the check. When you run the parameter, just look at what track Vice seeks out to. If it's 35/35.5/36, then it's not a crack. The game wouldn't necessarily have to flip back to disk one for a timebomb. It could check the protection on side one at initial load and simply set a flag in memory somewhere. Later it just checks that flag and blows up if it doesn't find what it expects to. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Oct 25th, 2011 @ 06:09 ( . ) |
I tried using fat hack em's fat track creator on a real machine and the games with xemag protection don't pass the check. The EA loaders how ever -- do. |
| 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. |