 | Author: | Lord Crass (guest: search) |
|---|
| Date: | Sat, Apr 30th, 2011 @ 22:50 ( . ) |
There's a few of the non-working images I've analyzed and here's what I've found:
Mainframe: Uses a disk routine that accepts user code (U# commands) to process lower-level disk commands such as sector reads/writes. Uses the drive's job queue to process most of these. It fails when it's told to retrieve track 36 sector 16 and encounters an error 23 (READ ERROR). It retries 4 times and gives up and resets the computer. This is very likely a bad copy or a bad dump.
Galaxian (V-Max V4): This one has a non-standard V-Max loader that doesn't force all file loads through the V-Max splash screen program. The code that loads track 20 is also different and it doesn't look for the standard signature on track 20 which marks the beginning of data. It simply looks for byte $37 and then starts reading. Since there are multiple $37 bytes on this track, this might be a track-sync type protection, but it seems to "mostly" work in this case. The loader comes into drive RAM and it all looks good up until it overloads over top of the loading routine, where the instruction pointer is supposed to land on a newly written RTS instruction. The RTS comes in 1 byte out of place, the stack pointer is wrong, and the whole works gets screwed up.
Felony! (Thunder Mountain V-Max V3): Same loader as Galaxian, but the track 20 loads in completely corrupted.
Can the originals be verified as working and redumped? |
|
 | Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sun, May 01st, 2011 @ 00:26 ( . ) |
Alien world by high tech expressions also works, well it works under vice at least, I haven't tested it out remastered to a real machine though.
Kangarudy will work if you replace track 36 with a copy from a rainbow arts protected game.
and Paradroid can be made to work on emulators by patching track 38 in the same way you do with express raider. |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sun, May 01st, 2011 @ 01:48 ( . ) |
Hmmmm. Alien world does not work remastered to a real machine, or on hoxs64 for that matter.
I wonder when this game was dumped? |
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Sun, May 01st, 2011 @ 12:09 ( . ) |
Alien World isn't a protection problem, it's a timing issue when reading from the serial port. In Vice go to the "C64 Model Settings" window, change the C64 model to PAL, and change the CIA 1 model to "6526A (new)". The game will load then.
Of course with a real machine, you're out of luck unless you have that version of the CIA chip. |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sun, May 01st, 2011 @ 14:45 ( . ) |
ouch! That must have earned high-tech expressions a lot of unhappy customers. |
|
 | Author: | J Achernar (registered user: 36 posts ) |
|---|
| Date: | Sun, May 01st, 2011 @ 16:50 ( . ) |
Actually, it is a bug in VICE 2.3. I have several titles that worked just fine on the real hardware and on VICE 2.2 that won't work on 2.3 unless the new CIA chip is selected. |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sun, May 01st, 2011 @ 18:35 ( . ) |
Well it appears I'm one of the unlucky ones my c64 hardware does not have one of these newer CIA chips installed, the game won't load. |
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Tue, May 03rd, 2011 @ 00:55 ( . ) |
Crossword Magic does a very strict sync length check using the VIA timer on track 18. The image doesn't have the right sync lengths, so it fails. Game works if this is passed.
Superstar Soccer doesn't work because it's trying over and over again to load a file that doesn't exist on the disk "0:SOCCER DATA". |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Tue, May 03rd, 2011 @ 02:35 ( . ) |
Have a look at bobsleigh. what a mess that one is. |
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Tue, May 03rd, 2011 @ 19:40 ( . ) |
It uses the drive's job queue to read track 1, sector 0. Unfortunately, like Mainframe, this returns a read error (error 20, "Header block not found" in this case), so it retries 5 times, but adjusts the disk ID registers to match the last read track/sector (which happens to be from track 18). When there's 2 tries left, it bumps the head and reads again. Eventually it runs out of retries and just continues on.
It then generates a short list of GCR bytes it needs to find after a sync mark, which is based on the track/sector that was requested to be read, as well as the disk ID and some other values. It never finds this series of bytes and searches forever.
I'm thinking that there was a problem imaging track 1 and the image is corrupt. Perhaps there is something intentionally wrong with this track, but it seems odd that a protection from 1989 would rely on bumping the head for a reason other than a actual error situation. Especially one that has it's own GCR reading routine.
Unless someone can verify that the original works fine in a real C64 on the drive its being imaged from, I'm going to assume it's a bad image or disk. |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Tue, May 03rd, 2011 @ 03:06 ( . ) |
Although it is not possible to successfully convert the original express raider nzb file to g64 without any alterations to track 38, It is actually possible to remaster the unpatched signature track 38 on paradroid and express raider, but it is extremely difficult, it needs to be done in 2 passes.
First You need to write out the entire disk at a speed of 299.0x rpm, then write tracks 37 and 38 at a speed of 299.3x rpm using the timed alignment switch "-t". and what's more, you may not always be successful, you just have to keep trying and trying and eventually you'll be able to create a track that will pass the protection check. From what I can gather, each game protected with Heyward's system uses the same signature pattern on t38, the way the early rainbow arts games use the same sync length check method on t36. |
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Tue, May 03rd, 2011 @ 20:45 ( . ) |
I'm guessing you're referring to the PAL version of Express Raider.
I took a quick look at it and it uses track 38 like V-Max uses track 20. Waits for sync, then starts decoding GCR bytes 2:1. The decoded data starts getting written to the drive memory at address $170, building more drive code. This code is then executed and looks for a $77 byte, which it never seems to find, so this is where it fails in the emulators.
If it were to find this byte and continue, it would move the head to track 39, set a timer, and start looking for a sync mark which it must find before the timer runs out. So this is also a track-sync protection. When the sync ends, it loads data into the $700 buffer using 2:1 GCR bytes like it did on track 38, then jumps to execute it when done. Since I forced the sync timer to never fail when testing this, I guess I got the wrong sync mark (there's a few on this track) and the drive got loaded with garbage, so I don't know what this code is supposed to do.
Normally when the sync timer runs out, it moves the head back to track 18 and ends.
There's illegal GCR all over the place on these tracks which could cause you problems. Also, the track sync is problematic for most drives.
The illegal GCR seems to arrange properly with the nibconv -bf option, as Pete mentions in the database entry. Track 39 would need to be rotated in the G64 image so that the head lands at the correct spot for this to work in emulators, and/or the $77 byte placed in a spot on track 38 that accomplishes the same task. This requires some testing to see which block of data it actually needs and then what happens after it gets it. |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sat, May 21st, 2011 @ 20:27 ( . ) |
Really? Of all of the drives I've tested the game out on, I don't think any of them have failed to load it up so far.
btw: just make sure you Keep all curious children away from the drive at least while tracks 38, 39 and 36 are being read because playing with the drive door during this part of the loading process will break the game. |
|
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Wed, May 04th, 2011 @ 21:57 ( . ) |
I never noticed the Crossword Magic issue since I've never tried it on VICE 2.3. It works in earlier versions just fine.
|
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Sat, May 28th, 2011 @ 14:04 ( . ) |
Crossword Magic is another VICE issue- it works on older versions. |
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Tue, May 03rd, 2011 @ 09:51 ( . ) |
I really appreciate you looking at all of these. I'll get the database updated in the coming days.
|
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Fri, May 20th, 2011 @ 21:07 ( . ) |
Frankie Crashed on Jupiter: Protection reads the track 1, sector 20 data block at a non-standard density (%00 instead of %11). The image was read in using the standard density, so the result is garbage. This track needs to be redumped at the lowest density and the sector 20 data block (head block is fine) pasted into the G64 image for it to work in emulation. As for remastering, unless I'm mistaken, mnib can't write multiple densities on a single track yet.
Vixen (PAL) [Martech]: This is Para-Protect V2. Seems to work just fine for me in both NTSC and PAL. |
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Sat, May 21st, 2011 @ 14:45 ( . ) |
Flak [Funsoft 1984]: This awful little protection writes to the disk. It writes to t/s 19/02 and that must succeed or it tries over and over. Then it tries writing to t/s 20/02. This must fail or it tries over and over again.
The protection seems to be based on physically damaged sectors that need to return errors when attempts are made to write to them. I tried erasing the sector header for 20/02 to see if it would fool the protection, but it doesn't work. The protection checks that some of the sector was written (first 6 bytes at the minimum must match).
Unless someone can think of a way to damage the sector in an image to the extent that a U2 write command will only partially work, this won't function in an emulator.
And unless you can physically damage a real disk at the right spot, this won't work remastered either.
On the other hand, it's an easy crack to remove the protection check entirely. There's only one little method used to hide it (check $179F in the main program for the self-modifying code that hides the protection check at $17A2). |
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Sat, May 21st, 2011 @ 15:06 ( . ) |
Wow, possible laser hole protection? I know it was used on the PC, but this is the first find for the 64. |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sat, May 21st, 2011 @ 20:03 ( . ) |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Sat, May 21st, 2011 @ 20:08 ( . ) |
But the first check is for that. It must succeed the first time- |
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Sat, May 21st, 2011 @ 20:25 ( . ) |
And after it writes to track 20, it reads it back to verify it. The data it writes is a pseudo-random byte taken from the timer, so it's different each time you load the game.
When it reads it back, at least 6 bytes must match what it thinks it wrote, but the whole sector cannot match. If it does: protection failed.
Anyone here have access to the original disk and can take a look to see what kind of damage exists? |
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Sat, May 28th, 2011 @ 13:47 ( . ) |
This image came from "HOK". I will ask them.
|
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sun, May 29th, 2011 @ 04:54 ( . ) |
The only way to find out if the disk is really damaged is to first make a nb2 read of it, then format the disk and check to see if the t20s02 is still damaged.
|
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Sun, May 29th, 2011 @ 10:26 ( . ) |
I think the damage will be visible on the actual disk. No need to erase the original. |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Mon, May 30th, 2011 @ 16:50 ( . ) |
I wonder why syncr0l0k wasn't used on other titles. Perhaps some drives couldn't handle it. |
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Mon, May 30th, 2011 @ 19:39 ( . ) |
Expensive, I imagine. And since it's just a one-time check which isn't really integrated into the loader, it's fairly easy to crack. Even in the PC scene, this type of protection was quite rare and you usually only saw it on business apps. |
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Sat, May 21st, 2011 @ 20:19 ( . ) |
Kwik-Write! [Datamost]: Track 15 is non-standard. Only the last sector has a sector header and any data in the data block. This data block is divided into 3 shorter sections by sync marks:
The first section has $45 bytes of data and is written at a non-standard density (%10 instead of %11).
The second section is written at density %01 and $7D bytes are read in.
The third section is written at density %00 and $82 more bytes are read in. The GCR data is then decoded using standard ROM GCR decoding routines.
This track needs to be redumped three more times, at density levels 0, 1, and 2. The data could then be merged into the image for a working G64.
In short, there's all 4 density levels present on this one track (the sector header is written at standard density %11) |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sun, May 22nd, 2011 @ 18:52 ( . ) |
nibread -S15 -E15 filename.nb2 |
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Sat, May 28th, 2011 @ 13:51 ( . ) |
I've got an NB2 spin of this disk - sent it your way. |
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Sat, May 28th, 2011 @ 13:42 ( . ) |
I've requested a redump of Frankie Crashed on Jupiter to NB2 format so we can get it all. The original contributer is still in contact with me from time to time.
|
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Sun, Aug 19th, 2012 @ 17:10 ( . ) |
I have a dump of Frankie at all density levels - I'll send it your way.
|
|
| Author: | Lord Crass (guest: search) |
|---|
| Date: | Wed, Jun 08th, 2011 @ 23:16 ( . ) |
Datel Toolkit IV: Reads in sectors at nonstandard density (%00 when normal is %11) on track 5. Needs redump in NB2 format.
Raid Over Moscow: Appears to be a bad copy. Auto-booter loads track 18 sector 12 into $C000 then jumps to it. Problem is, that sector is empty. |
|
 | Author: | Displacer (registered user: 14 posts ) |
|---|
| Date: | Thu, Jul 05th, 2012 @ 12:31 ( . ) |
I'm currently working on Datel Toolkit IV. It has more protection than reading in sectors on Track 5 with a nonstandard density. It is also counting sync marks.
Code is pretty convoluted with several direct kernal calls on the computer side and direct DOS calls on the drive side so I don't know how or when it crashes if it fails the protection. It's also looking for specific errors (I think) on Track 5. Again using direct DOS calls, which to further muck things up, the calls are usually to the middle of a known routine, not the start of it.
As an interesting side note, after all the protection checking is done, all it does is point to a T/S location that is a normal file chain of blocks for a compiled (with Blitz!) basic program. It's very simple to defeat, just change to pointers on the only file in the directory to point to that file. It loads and runs just fine |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Fri, Jul 06th, 2012 @ 03:48 ( . ) |
| Author: | Displacer (registered user: 14 posts ) |
|---|
| Date: | Fri, Jul 06th, 2012 @ 13:42 ( . ) |
Yea one call it uses is to $F642. This is at the end of the kernel SAVE routine. It uses the very end of this routine instead of the kernel UNLSN. This of course is at the end of the SAVE routine, which just happens to include a call to UNLSN ;) |
|