|
Post by gmoon on Feb 10, 2007 11:32:37 GMT -5
Sheeez. Don't we miss those days of copy-protected disks?
|
|
|
Post by tlr on Feb 10, 2007 13:33:07 GMT -5
Sheeez. Don't we miss those days of copy-protected disks? There's nothing like a good puzzle...
|
|
|
Post by gmoon on Feb 10, 2007 15:06:34 GMT -5
There's nothing like a good puzzle... The real reason why DRM is a doomed strategy....
|
|
|
Post by Ian Colquhoun on Feb 11, 2007 0:11:43 GMT -5
tlr: Wow! What can I say? I can't imagine how long all this would have taken me. Looking through it quickly I think I only understand maybe 25-50% of it so far. Lots to study! This looks to be far more extensive than I thought it was. Anyway - you had a question about the border flashing - I'm not even sure whether it matters now that you've had a look. But anyway - I'm not sure how many times it flashes, but it changes about once every second or two. It seems to coincide with clicks from the disk drive which I assume is the head moving. The activity light on the drive never stays on during the load, it comes on briefly, goes out, the drive clicks, and it comes on again. The activity light is roughly in sync with the border flashes. I'll post images of Disk 2 and the Files Disk in a few minutes - just have to make sure they're in decent condition. Have you gotten far enough to have any ideas about how to get this backed up and preserved properly?
|
|
|
Post by Ian Colquhoun on Feb 11, 2007 0:40:19 GMT -5
www-acad.sheridanc.on.ca/~ian/c64/ds31disk2.d64www-acad.sheridanc.on.ca/~ian/c64/ds31files.d64Here are the other 2 disks required to get a BBS up and running. On Disk 2 there are a bunch of Basic programs called CREATE.* that are used to create your config files. EX. CREATE.CNF creates the CONFIGURATION file. To configure your BBS you actually edit the Basic source and run the program to generate the files. Other files on Disk 2 that may not be obvious: MODEM.NEW 1670 is the modem driver - which I'll also have to change because it currently won't work with my TCPSer setup. WONDER SET is a character set you can load when you boot the bbs. 930427.TXT is the prompt file from my BBS which it appears that I created on April 27, 1993. There is a prompt file editor used to edit this file but I'll have to go digging for that. I have it - somewhere! I hope these help. Thanks again.
|
|
|
Post by tlr on Feb 11, 2007 4:56:04 GMT -5
tlr: Wow! What can I say? I can't imagine how long all this would have taken me. Looking through it quickly I think I only understand maybe 25-50% of it so far. Lots to study! This looks to be far more extensive than I thought it was. It's fairly straight forward, but very tedious. You'll need moderate knowledge of drive coding to follow it. I'll be happy to explain any part of the code you wonder about. Have you gotten far enough to have any ideas about how to get this backed up and preserved properly? Yes, but it's probably a lot more work. I found the reason you can't copy it btw. It is hinted in the name "STAGGER TRAX" found in the code. On track 32 there is 16 sectors with encrypted code, BUT every odd sector number is located one half track up at track 32.5. I haven't looked at the .g64 format in detail yet, but I'm not sure it can represent this configuration. Also writing a copy of this to a disk provides a challenge. The quick crack is to replace track 32+32.5 with a regular track 32 containing the same data. When run in an emulator as a .d64, the emulator does not care if the track is 32 or 32.5. It returns the same so it should run. For the real thing, all instances of the half track movement needs to be removed. This is in principle simple, but there are many encrypted instances of this check. I assume I will find more protection in the "stagger track" itself. Now, this stagger track data is not in the images you posted because it cannot be read normally. I will make you a small utility to read the stagger track off the original disk and save it to a different disk and you can post it here. This is what the scan of your .g64 looks like in VICE: 1 2 3 12345678901234567890123456789012345678 +--------------------------------------+ |................................07.111| |................................00.111| |................................00.111| |................................00.111| |...............................207.111| |...............................200.111| |...............................207.111| |...............................300.111| |................................07.111| |................................00.111| |................................07.111| |................................00.111| |...............................207.111| |...............................200.111| |...............................207.111| |...............................200.111| |................................07.111| |..............................+-------+ |........................+-----+ |.................+------+ |.................| PRESS F1 TO EXIT +-----------------+ PRESS P TO PRINT Could you run this scan on the original disk? Use "E" on SUPERKIT9 from this disk: superkit [csdb]. I feel like the errors show up on the wrong track in the .g64. Be sure to put a write protect tab on your orignal, just in case! BTW: Have seen this: C*Base 3.3? I hope it's not the same program.
|
|
|
Post by tlr on Feb 11, 2007 7:12:39 GMT -5
Oki... run this: stagger_reader.prgIt will read the track from the original disk, and then prompt for a target disk where it will save the file "STAGGER TRACK" (17 blocks). I need that file to proceed. Again please write protect the disk if it isn't already. Should be no problems, but you never know with drive code. EDIT: If you could run mnib with the half track option (I think it is -h) you might be able to produce a .g64 that works in an emulator. If you do please post it.
|
|
|
Post by Ian Colquhoun on Feb 11, 2007 17:17:06 GMT -5
It's fairly straight forward, but very tedious. You'll need moderate knowledge of drive coding to follow it. I'll be happy to explain any part of the code you wonder about. Excellent. I'll try to sit down and have a look over it when I can. I understand ML, but not fluently like I do Basic, C or Perl. I found the reason you can't copy it btw. It is hinted in the name "STAGGER TRAX" found in the code. On track 32 there is 16 sectors with encrypted code, BUT every odd sector number is located one half track up at track 32.5. I haven't looked at the .g64 format in detail yet, but I'm not sure it can represent this configuration. Also writing a copy of this to a disk provides a challenge. Ya. That is ugly. So physically on the disk the odd sectors are at 32.5? I wonder how that was written to the disk in sync since 1541's don't have any way to sync track to track do they? BTW: Have seen this: C*Base 3.3? I hope it's not the same program. Good eye! Yes, I have seen the announcement for C*Base 3.3. I'm currently running C*Base 3.2, but it is no relation to Darkstar which of course is what I originally ran the Realms of Mystery on. Don't worry Mate, I would have stopped you a long time ago if this was just an exercise! Ok... Here is what Super Scan gave me on the original: 1 2 3 12345678901234567890123456789012345678 +--------------------------------------+ |................................77.111| |...............................277.111| |................................77.111| |...............................277.111| |................................77.111| |...............................277.111| |................................77.111| |...............................277.111| |................................77.111| |...............................277.111| |................................77.111| |...............................277.111| |................................77.111| |...............................277.111| |................................77.111| |...............................377.111| |................................77.111| |..............................+-------+ |........................+-----+ |.................+------+ |.................| PRESS F1 TO EXIT +-----------------+ PRESS P TO PRINT It looks like the stagger reader worked well too. Here is the track: www-acad.sheridanc.on.ca/~ian/c64/stagger%20track.prgDo you know whether this stagger trax is a known copy protection scheme, not the method itself, but this particular implementation? I've never seen any mention of it before.
|
|
|
Post by Ian Colquhoun on Feb 11, 2007 17:28:05 GMT -5
EDIT: If you could run mnib with the half track option (I think it is -h) you might be able to produce a .g64 that works in an emulator. If you do please post it. I had already made an mnib file with the halftracks enabled, and I just tried creating a g64 from it and running it in Vice. It looked like it might work - the black/red border flash was happening but just as I thought it was going to show the ASCII/Color menu, it hung - black screen, black border with light blue text and the track monitor showing Track 14.0. No good.
|
|
|
Post by tlr on Feb 11, 2007 17:36:02 GMT -5
EDIT: If you could run mnib with the half track option (I think it is -h) you might be able to produce a .g64 that works in an emulator. If you do please post it. I had already made an mnib file with the halftracks enabled, and I just tried creating a g64 from it and running it in Vice. It looked like it might work - the black/red border flash was happening but just as I thought it was going to show the ASCII/Color menu, it hung - black screen, black border with light blue text and the track monitor showing Track 14.0. No good. Ah, but that is a different problem. It scans for repeating memory patterns. The real c64 has irregularities in the memory after a reset. Vice does not. If you post the image I can try it. You can try too, but it's a bit tricky. - Load it until the border starts flashing, then do Alt-M for the monitor.
- In the monitor do:
a 0951<cr> jmp 0951<cr> <cr> x<cr>
- let it run until the border stops flashing
- Alt-M for the monitor.
- Do:
a 1819<cr> bit 18f3<cr> <cr> a 0951<cr> jmp 1300<cr> <cr> x<cr>
et voila...
|
|
|
Post by tlr on Feb 11, 2007 17:41:56 GMT -5
Ya. That is ugly. So physically on the disk the odd sectors are at 32.5? I wonder how that was written to the disk in sync since 1541's don't have any way to sync track to track do they? They probably used a drive with an added index hole detector. You could probably do this with the VIA timers on a stock drive. The stagger track seems to be just 16 sectors long (instead of 17) which leaves the possibility for extra gap between the sectors. Ok... Here is what Super Scan gave me on the original: Ok, this confirms the stagger layout. Do you know whether this stagger trax is a known copy protection scheme, not the method itself, but this particular implementation? I've never seen any mention of it before. It says "** STAGGER TRAX **** (C) 1987 D.S.S. ***" in the loader, so I guess it is custom for Darkstar Systems Software.
|
|
|
Post by tlr on Feb 11, 2007 18:20:25 GMT -5
Partial success! I got it running up to the configuration + re-asking for the master disk using the dumped stagger track. Q: What shall I type during the configuration to get past it as quick as possible? I did some trial an error to get past it, but I can remember what I did. EDIT: Only works with "Color" though. "Ascii" won't accept the second disk. Am I missing something here? To make this a clean crack I need to strip down all the original disks down to what was originally on them...
|
|
|
Post by Ian Colquhoun on Feb 11, 2007 20:35:47 GMT -5
They probably used a drive with an added index hole detector. You could probably do this with the VIA timers on a stock drive. The stagger track seems to be just 16 sectors long (instead of 17) which leaves the possibility for extra gap between the sectors. I've heard of index hole sensors for 1541's but I'd always wondered what the heck you'd use them for. I guess this type of thing is it! Ok, this confirms the stagger layout. Good. It says "** STAGGER TRAX **** (C) 1987 D.S.S. ***" in the loader, so I guess it is custom for Darkstar Systems Software. As far as I know D.S.S. was just 1 or 2 guys. They wrote quite a bit of software for the size of them... Along with the various versions of Darkstar BBS and Darkterm, they also did Zipcode and Zipcode II.
|
|
|
Post by Ian Colquhoun on Feb 11, 2007 20:42:43 GMT -5
Ah, but that is a different problem. It scans for repeating memory patterns. The real c64 has irregularities in the memory after a reset. Vice does not. If you post the image I can try it. I'll have a go tomorrow. In the mean time - here is the half track g64: www-acad.sheridanc.on.ca/~ian/c64/ds31ht.g64EDIT: Okay... so my son actually went to bed early tonight! I tried the above image in Vice with your tricks and it does get as far as the track 32/32.5 check and then just sits forever going back and forth between 32 and 32.5. I guess this g64 isn't quite right.
|
|
|
Post by Ian Colquhoun on Feb 11, 2007 20:59:12 GMT -5
Partial success! I got it running up to the configuration + re-asking for the master disk using the dumped stagger track. Q: What shall I type during the configuration to get past it as quick as possible? I did some trial an error to get past it, but I can remember what I did. EDIT: Only works with "Color" though. "Ascii" won't accept the second disk. Am I missing something here? To make this a clean crack I need to strip down all the original disks down to what was originally on them... Awesome! For the questions going from memory: System Drive: <return> Overlinks: <return> Link Drive: <return> Text File: 930427.txt Modem File: modem.new 1670 Sysop pass: whatever you want System pass: <return> Date and time: should be self explanatory I think that's all it asks. The reason the ASCII one wouldn't load is probably because one of the config files is specific to which option you pick. The file c.commands defines commands for the colour board and the ascii side expects a.commands. www-acad.sheridanc.on.ca/~ian/c64/ds31support.d64This image is the closest thing I have to what was originally shipped as Disk2 but I notice is actually labeled Side 2. The file 910805 is another one of my prompt files. I don't know what the file spectra is - it might be another prompt file someone sent me. The +he.* and +sy.* files might be mine, but they might be defaults too. I can't remember and I haven't looked recently. Anyway, it's a pretty close approximation of what originally came on that disk. I do have one other disk with some Overlinks on it - an extended File area and a Blackjack game I think. I don't have an image of it yet but will post it when I do. One problem is though that my memory has completely failed me as to how these work so they'll require some playing!
|
|