| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 12:17 ( . ) |
I have submitted a scan of Software Toolworks’ “Beyond the Black Hole†to the project made with version 4.93 of Nibtools. The copy protection for this one is a bit interesting. The database mentions that the program will not run in an emulator and will not remaster. Back in the day, this was one that I was never able to make a working backup with a nibbler. The disk looks normal with no bad sectors or tracks and no extended tracks. I scanned in side one with half tracks, but from watching it try to run and from the results of the scan, I don’t think that it uses half tracks at all. It may be using something like sync timing. Side two, which contains the program levels, is not copy protected. It actually does run in CCS64 (but not VICE 2.3), but only when started using Load and Run or drag and drop. Also CCS64 must be in PAL mode. It does not work if it is started using the C64 LOAD command. The PAL limitation is interesting, because the program is an NTSC version. When started normally, the Software Toolworks and Black Hole splash screens are corrupted in PAL, but are ok in NTSC prior to the program crashing due to the copy protection. This is as far as I plan to take this. I have attached a copy of a NIB file for side 1. If any of the experts in this group would like to take a look at it, see how it works, see if it can be remastered or see if there is any way to make it more emulator friendly, I would be interested in seeing your feedback. |
Attachments: |
| 1300637821_black_hole.zip |
 | Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 14:26 ( . ) |
Here's what it does: After the title screen, it reads track 16 sector 20 (which seems to be mostly empty), after the read the drive head is at the tail gap (normally $55 bytes). It reads until it gets a $6A byte, puts it in the $309 location in drive memory. Then it reads the next 4 bytes and puts them reversed at $305-$308. Standard GCR decode follows and data is sent to the C64. The C64 loads the data into $CB00, then EORs the 4 bytes it loaded together. Result must be $79 or reset occurs. Force the value for a crack (I didn't check for checksums or anything like that) and the program continues and asks you to insert side 2, which I don't have. Or fix the GCR bytes in the image so they EOR (after GCR decode) to $79, which shouldn't be too hard. BTW, the non-working bytes in the NIB dump you have are at offset $3DE97 and are: 6A 3D 5C D1 9F |
| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 16:44 ( . ) |
Thanks for the very quick feedback. As a quick test, I changed the byte sequence in the G64 to 6A 65 AB 94 52, and the program boots and runs in VICE. So this is some type of bad GCR scheme? I went back and tried some of the switches in nibconv, but they don't make any difference. I wonder how it manages to work in CCS64? |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 17:28 ( . ) |
Yes the D1 is bad GCR. This will get read differently each time. |
| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 17:52 ( . ) |
After looking at it again, I decided to go with 6a bd 5e d3 9c as my best guess for what the program is really expecting since this only flips five bits. |
| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 18:26 ( . ) |
One last note, in three different scans of the original, all had the same bad GCR sequence 6A 3D 5C D1 9F. The original does boot on my C128D. So is this a nibbler or am emulation issue? I would be interested to learn if the nib I posted will remaster. I have never had any success remastering with my drive. If someone wants to try this, I can post side 2 so that a complete test can be done. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 18:37 ( . ) |
A little of both. The bad GCR is framed in such a way that causes a reading glitch if you aren't using the original loader. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 18:41 ( . ) |
To be more exact- the two sets of 3x00 bits in a row causes the framing to be lost and the bytes to be scrambled when read. as recorded on disk: 6A 3D 5C D1 9F = 110101000111101010111001101000110011111 the bytes it wants (technically this may not be what it wants, this is what you put in to make checksum match - it's probably more derivative of the original pattern in reality, as 94 52 is still an illegal GCR sequence): 6A 65 AB 94 52 = 110101001100101101010111001010001010010 You can see we slip away on the first bad sequence and it is scrambled from there. |
| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 22:23 ( . ) |
Interesting, thanks, so it sounds like the only way to reproduce this protection exactly would be to disassemble the original loader and use it to code a special purpose nibbler. Beyond my skill level and spare time available. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 23:16 ( . ) |
This string of bytes appears to be written at a different density level, that's why it's coming in incorrectly. Here's the drive code that switches density and reads them: .8:0493 LDA $1C00 .8:0496 PHA ; Push original $1C00 values (density specifically) to stack .8:0497 AND #$9F .8:0499 STA $1C00 ; switch to density %00, lowest density (same as track 31-35) .8:049c LDY #$19 ; read up to $20 gap bytes before giving up .8:049e BVC $049E ; wait for byte ready .8:04a0 CLV .8:04a1 LDA $1C01 ; read GCR byte .8:04a4 CMP #$6A .8:04a6 BEQ $04AB ; branch if found a $6A byte .8:04a8 DEY .8:04a9 BNE $049E ; loop until we find $6A or exceed number of tries .8:04ab STA $0309 ; Store the byte in the $300 buffer .8:04ae LDY #$03 ; Read 4 more bytes .8:04b0 BVC $04B0 ; wait for byte .8:04b2 CLV .8:04b3 LDA $1C01 ; read GCR byte .8:04b6 STA $0305,Y ; store at $308 down to $305 .8:04b9 DEY .8:04ba BPL $04B0 .8:04bc PLA ; Pull original density level .8:04bd STA $1C00 ; Set it |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Mar 21st, 2011 @ 08:23 ( . ) |
The first solid proof of a protection doing that! :) |
| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Mon, Mar 21st, 2011 @ 20:24 ( . ) |
Very cool! Pete, is there an option to force nibread to read at a specific density other than the default? If not, when I get some time, I'll try to compile a specific version that just reads at density 0. The next step would be to scan in just track 16 at density 0, then extract the original gap data. An exact G64 could then be manually reconstructed. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Mar 21st, 2011 @ 21:26 ( . ) |
Sort of. You could do an NB2 of that track which will give you 3 copies at each density. |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Wed, Mar 23rd, 2011 @ 04:45 ( . ) |
Peter, could you enable future versions of nibtools to extract the raw data in all 3 densities from .nb2 files? IE, you do a nibscan filename.nb2, and you get something like tr1.0d0, tr1.0d1, tr1.0d2 etc? Thanks. |
| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Sat, Mar 26th, 2011 @ 22:55 ( . ) |
I think that I have finally reproduced the exact original protection for Beyond the Black Hole from 1989. While there is a cracked copy available on GB64, I think that this one is worth preserving in its original form. This game is one of the first, stereoscopic 3-D (Pulfrich effect) games produced for home computers. It is possibly the only one released for the C64. At least, I am not aware of any others. To see the 3-D effect, take an old pair of sunglasses and pop the lens out of the left side to give one dark lens on the right. When I emailed Pete this one for inclusion in the database, I had already scanned in side 1 as an NB2 figuring that might be more useful since the copy protection had not been figured out yet. I took that and extracted the track 16 speed 0 tail gap data. I am not 100% sure I did this correctly. I am not very experienced with raw GCR unlike some of you who can read it like it was poetry. It turns out that the magic bytes are 6A 7A B9 A6 7D. I pasted the extracted data on top of the existing tail gap data in the G64 and adjusted the track size bytes at the beginning of the track to account for the tail gap being one byte shorter. This is sufficient for it to work in both CCS64 and VICE. It doesn’t make any difference for the emulators, but to fully reproduce how the original worked, I manually created a speed data table for track 16 with the tail gap bytes set to speed 0 and the rest of the bytes set to speed 3. I pasted this to the end of the g64 and set the speed zone offset for track 16 to point at this table. I have attached the edited G64 file and an NB2 I scanned in containing just track 16. If you take a look at this and see anything that I did wrong or could suggest any improvements, please let me know. |
Attachments: |
| 1301194320_Black_Hole_g64.zip |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Mar 27th, 2011 @ 13:45 ( . ) |
Thanks very much. That makes for a good emu patch. Unfortunately, nibwrite doesn't support speed zones- quite a rewrite would be needed for that. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Fri, Jan 18th, 2013 @ 18:13 ( . ) |
I have a copy of black hole NTSC wich I dumped using nibtools rev 560 (both sides) that won't run on the regular version of vice, but it does work on the sps release. Unfortunately I can't test if it can be remastered and run successfully on real hardware since the only 2 machines I have are pal. J Achernar's original unpatched copy will break and reset on both vice versions but mine will run on sps. Strange. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Mar 27th, 2011 @ 13:56 ( . ) |
Oddly, the image I have does work. It could be that I stumbled upon an original that has a different protection or had it removed, but that would be odd. Only the one sector in question differs. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Mar 27th, 2011 @ 13:57 ( . ) |
Attached is my original disk image. |
Attachments: |
| 1301248657_beyond_the_black_hole_s1[software_toolworks_1989].zip |
| Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Mon, Mar 28th, 2011 @ 21:58 ( . ) |
Very curious. Comparing the two images, they are identical except for two differences. Your copy does not have any signiture bytes at all it the tail gap of sector 16. Also, in track 19, sector 2, byte 60, an A0 has been replaced with a 60, i.e. an LDY #$21 has been replaced with an RTS. This happens to be the first sector of "BH2" which has a load address of 1406. Your copy runs in VICE as a D64 file. It looks like the copy protection has been completely disabled. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Tue, Mar 29th, 2011 @ 08:19 ( . ) |
Interesting. I'll need to check my original again- It's possible that someone ran a parameter on it sometime in the past, or else they had a mastering run without the protection. The latter is doubtful, so I'll correct the database. |
 | Author: | bluebirdpod (registered user: 28 posts ) |
|---|---|---|
| Date: | Tue, Mar 29th, 2011 @ 09:15 ( . ) |
I think Dark Castle is the same way, as it has weak bit protection signature checks, and I think GB05 has DCastle as .D64's which must have had a parameter run on both sides, I will confirm this, I have several Originals of Dark Castle. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, Apr 27th, 2011 @ 21:41 ( . ) |
This is likely the same mystery protection as on Chessmaster 2100. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Apr 30th, 2011 @ 10:47 ( . ) |
Yes, it is. In fact, it's exactly the same. The only difference the is memory location of the protection check on the C64 side of things. Looks for 4 GCR bytes written at non-standard density in tail gap of track 16 sector 20. EOR'd together must = $79. So you could even copy the same signature from Beyond the Black Hole for it to work. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sat, Apr 30th, 2011 @ 21:25 ( . ) |
the same goes for the George Heyward protection used on some copies of express raider and Paradroid. All I had to do was make sure tracks 37 and 38 were aligned properly and then copy the contents of paradroid's tracks 1 through 36, the signature patern works on both games. |