| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, Jun 28th, 2012 @ 05:32 ( . ) |
Hi.Just curious How long is the actual track 2 in question? due to the lack of sync, you get 8192 bytes when using nibtools, but I'd like to find out what the true size is. Cheers. |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Jun 28th, 2012 @ 08:31 ( . ) |
It will have an expected track size based on the density detected. /* To calculate the bytes per rotation: 4,000,000 * 60 b/minute = ------------------------------------------------ = x bytes/minute speed_zone_divisor * 8bits 4,000,000 is the base clock frequency divided by 4. 8 is the number of bits per byte. 60 gets us to a minute of data, which we can then divide by RPM to get our numbers. speed zone divisors are 13, 14, 15, 16 for densities 3, 2, 1, 0 respectively */ #define DENSITY3 2307692.308 // bytes per minute #define DENSITY2 2142857.143 #define DENSITY1 2000000.000 #define DENSITY0 1875000.000 Further divide this by the RPM (300) to get the number of bytes on a track that "should" be there. Now, if the disks were not written with a 1541, this will be inaccurate. It's already known that a trace duplicator will be a slightly different bitcell size that a 1541, but it's close. Also, we cannot always tell where a custom tracks starts and ends when written on a 1541, though. Well, at least I can't- maybe there are other methods to do so I haven't explored. |
 | Author: | Displacer (registered user: 14 posts ) |
|---|---|---|
| Date: | Thu, Jun 28th, 2012 @ 08:40 ( . ) |
The data is read in the protection routine from this track at density 1 (%01) Not sure if this is standard for track 2, don't have my books handy. |
| Author: | Displacer (registered user: 14 posts ) |
|---|---|---|
| Date: | Thu, Jun 28th, 2012 @ 11:16 ( . ) |
Another thing I noticed, and I'll have to confirm this, is the protection code is read in one sector at a time, it starts at T1 S7, but the odd thing is it appears to go up to T1 S23, that track should only go to S21. Is it even possible to jam 2 extra sectors onto that track? The sector loading code is in the file EA.prg and is not encrypted if you want to take a look |
 | Author: | LordCrass (guest: search) |
|---|---|---|
| Date: | Thu, Jun 28th, 2012 @ 15:48 ( . ) |
I disassembled and commented the entire pre-loader, protection check code (host & drive side), and in-game loader (host & drive side) for this a while back. I don't recall it using extra sectors, but I can check it later. |
| Author: | Displacer (registered user: 14 posts ) |
|---|---|---|
| Date: | Thu, Jun 28th, 2012 @ 16:05 ( . ) |
I verified that it at least tried to load up to sector 23. I don't know if it actually loaded data from extra sectors or if it just bypassed them when they weren't found. I put a break at the end of the sector load routine and the sector counter was at 23 |
| Author: | LordCrass (guest: search) |
|---|---|---|
| Date: | Thu, Jun 28th, 2012 @ 20:38 ( . ) |
It tries to load up to 23, but the drive starts throwing back "illegal track or sector" after sector 20, so the buffer contents that are read for each of those is a repeat of sector 20. You can't use the U1 drive command to read extra tracks or sectors. You'd need to use the job queue directly, or write a custom routine. |
| Author: | Displacer (registered user: 14 posts ) |
|---|---|---|
| Date: | Thu, Jun 28th, 2012 @ 21:49 ( . ) |
Yep. I tried loading the extra sectors from a drive monitor using job codes and there was nothing there, it just returned $02 back (header block not found) Wonder if it was a bug, or possibly leftover code from some other loader? Anyway thanks for verifying that, and the heads up about the U1 command, I didn't know it would return errors if you tried to go past standard tracks/sectors |
| Author: | Displacer (registered user: 14 posts ) |
|---|---|---|
| Date: | Sun, Jul 01st, 2012 @ 11:31 ( . ) |
Finally found the drive code and how it's loaded. After all the decryption of the main code, the drive code is there and in its decrypted state but you still can't see it. How it works is there are 2 blocks of $100 bytes that just look like random garbage. The code takes a byte from the first block, then it does some elaborate calculations on that byte involving all three registers, A, X, Y. When it's finished it comes up with an offset into the second block which is one byte of the drive code. It transmits that byte to the drive into the buffer at $300 and then starts again with the next byte. I think for completeness I may alter the drive code to read in track 2 in it's entirety into the extra drive ram I have to try and capture exactly whats there. I'll save that for another day though At any rate I think I now have the code and data for the protection in it's entirety and completely decrypted state, unless I run into any other little terrors like the drive code |
| Author: | Displacer (registered user: 14 posts ) |
|---|---|---|
| Date: | Sun, Jul 01st, 2012 @ 12:51 ( . ) |
OK, I think I captured the track, and it makes one thing I had assumed does not appear to be correct. I had thought the beginning of the string of bytes for protection started with 2 $D7 bytes. This doesn't seem to be the case. While it is looking for the $D7 bytes, there are actually 5 of them. After looking at the code it is not just looking for 2 of them, it's looping through the $D7 bytes until they end and then looking for the other bytes. I'm pretty sure this is the reference "header" it uses to signal that the actual protection bytes follow immediately after. |
 | Author: | Fungus (registered user: 20 posts ) |
|---|---|---|
| Date: | Sat, Aug 18th, 2012 @ 06:59 ( . ) |
Which game are you looking at? If it's pirate slayer/busters the tool I coded here can determine version and decrypt the main loader for you. [link] saves a lot of time. If it's not, I'd be a bit interested to look at it myself. |