Really strange. There is really no need for such on the C-64 - the analogueness of the SID combined with the noise wave is far too useful. Unless it is limited to a range for game-rule purposes?ZeroZero wrote:Ok, while searching for the monsters and items list this occured to likely be a lookup table for pseudo random number generation2600 - 2800 - No idea. Byte by byte identical in BT2.
BT 1 file list on CBM64
/Twoflower
Ok - i've got some very unexpected help on first and foremost the first disk, but also on BT2 which might just be the opening I needed.
- If anybody is interested, I now have the nibbled originals of all 3 variations of the Bard's Tale I original, with the copyprotection intact.
- It seems that my earlier statement was wrong. Bard's Tale 2 uses a normal track/sector chain - I believe I can retrieve the files unencoded if we can deduct the first track/sector of each file. All of these files might use different EOR-encoding though, so scouring through the memory for a table of these might be an idea. First file on city-disk the was definitly EOR'ed and unpacked.
- If anybody is interested, I now have the nibbled originals of all 3 variations of the Bard's Tale I original, with the copyprotection intact.
- It seems that my earlier statement was wrong. Bard's Tale 2 uses a normal track/sector chain - I believe I can retrieve the files unencoded if we can deduct the first track/sector of each file. All of these files might use different EOR-encoding though, so scouring through the memory for a table of these might be an idea. First file on city-disk the was definitly EOR'ed and unpacked.
/Twoflower
Thanks for the tip, but fixing the disk is no option. A lot of sectors with fake-pointers seems to have been entered to prevent such automation.
I have so far gone through the first 15 tracks of the disk and found 10 real files and the double amount of fragments / fake entries.
Oh yes - and the most intriguing question perhaps - how was it encoded?
Answer: Try EOR'ing every file with... EA.
I have so far gone through the first 15 tracks of the disk and found 10 real files and the double amount of fragments / fake entries.
Oh yes - and the most intriguing question perhaps - how was it encoded?
Answer: Try EOR'ing every file with... EA.
/Twoflower
Yes - the BTII disks proved to be less impenetratable than I thought. After ZeroZero wrote that the first diskside was somewhat accessable I decided to check the second one more closely. After getting some unexpected help concerning where to locate the first (main) file on the disk and got a tip that an uncompressed file likely are having long strings of zeroes in memory I had an entrypoint. So far i've been able to recover the city-graphics, 4-5 events and about as many graphic files - and i've still got 15 tracks, the dungeon disk and a lot of re-checking to do.Darendor wrote:What exactly are you two talking about? You're disassembling BTII disks? I feel lost.
The events look much the same as in BT1 and the routines they utilize are located at the same places ($0800+), although they are in some cases far more sophisticated - like f.ex the casino. If we start off with an easy one and learn the hard way by changing the main program references, these events might be incorporable with BT1. If there are different wall tilesets in the dungeons, these can be used more or less directly in BT1 and so on.
/Twoflower
Twoflower, we really could work far more effective if you were on messenger.
Finding the load address is a lot easier. Check where in e.g. X and Y a address is loaded, then check, if in the file you investigate at that (low) offset anywhere is a string e.g. If so, then yozu can esaily calc the load address.
I am a pro sw developer, I can make you a proggy that completely xor's a whole D64 image except track 18, or whatever you want, by any value, with or without bytes 0 and 1 (track chain). Then the auto imagecheck of C64Copy should work excellent. In fact the boot disk was fully accessible after just having treated it with that tool, rofl, and including deleting unused stuff and BAM correction (which is a harder validate).
I think I am able now to start to write an event editor for BT 1, of course not for every instruction yet, in particular the riddle with several words and the Mangar event contain large parts of non-automatic, but "hand-coded" stuff. An editor otoh should provide simple actions to make events and not require the game developer to learn 6502/6510 assembler.
Finding the load address is a lot easier. Check where in e.g. X and Y a address is loaded, then check, if in the file you investigate at that (low) offset anywhere is a string e.g. If so, then yozu can esaily calc the load address.
I am a pro sw developer, I can make you a proggy that completely xor's a whole D64 image except track 18, or whatever you want, by any value, with or without bytes 0 and 1 (track chain). Then the auto imagecheck of C64Copy should work excellent. In fact the boot disk was fully accessible after just having treated it with that tool, rofl, and including deleting unused stuff and BAM correction (which is a harder validate).
I think I am able now to start to write an event editor for BT 1, of course not for every instruction yet, in particular the riddle with several words and the Mangar event contain large parts of non-automatic, but "hand-coded" stuff. An editor otoh should provide simple actions to make events and not require the game developer to learn 6502/6510 assembler.
As for the char disk of BTII: there is code on track 18, I didn't check, if it is real code or fake. Knowing that, I put the directory link chain on sectors that were obviously unused (std 1541 empty formatting) to avoid destroying any data. Anyway after decoating all files the char disk didn't work anymore, maybe it does a chksum over a certain sector or so, maybe 18,0. However I could that way uncoat all files w/o losing data, just not use the disk anymore, lol. There seem to be 101 "good" files on the disk.
ZeroZero:
You convinced me.
I'll get an ICQ-account and Pidgin today.
According to my notes, there is stuff located at track 18 sector 12 - i'm not really sure what. The thing is that there are some tricks placing data at track 18 which enables you to load data into the drivemem just by loading the directory - this might be one of them.
You convinced me.
I'll get an ICQ-account and Pidgin today.According to my notes, there is stuff located at track 18 sector 12 - i'm not really sure what. The thing is that there are some tricks placing data at track 18 which enables you to load data into the drivemem just by loading the directory - this might be one of them.
/Twoflower
At this point retrieving and documenting the files feels more important than getting the disk to work with an uncracked/semicracked BTII engine and loader. Replacing the loader isn't trivial, but definitly doable at a later stage. Replacing the loader to use the standard-romloader might be an option to start with?ZeroZero wrote:As for the char disk of BTII: there is code on track 18, I didn't check, if it is real code or fake. Knowing that, I put the directory link chain on sectors that were obviously unused (std 1541 empty formatting) to avoid destroying any data. Anyway after decoating all files the char disk didn't work anymore, maybe it does a chksum over a certain sector or so, maybe 18,0. However I could that way uncoat all files w/o losing data, just not use the disk anymore, lol. There seem to be 101 "good" files on the disk.
/Twoflower
What kind of unexpected help did you get anyways?Twoflower wrote:Yes - the BTII disks proved to be less impenetratable than I thought. After ZeroZero wrote that the first diskside was somewhat accessable I decided to check the second one more closely. After getting some unexpected help concerning where to locate the first (main) file on the disk and got a tip that an uncompressed file likely are having long strings of zeroes in memory I had an entrypoint. So far i've been able to recover the city-graphics, 4-5 events and about as many graphic files - and i've still got 15 tracks, the dungeon disk and a lot of re-checking to do.Darendor wrote:What exactly are you two talking about? You're disassembling BTII disks? I feel lost.
The events look much the same as in BT1 and the routines they utilize are located at the same places ($0800+), although they are in some cases far more sophisticated - like f.ex the casino. If we start off with an easy one and learn the hard way by changing the main program references, these events might be incorporable with BT1. If there are different wall tilesets in the dungeons, these can be used more or less directly in BT1 and so on.
And I'd like to point out that the original idea was to make a BT editor work with the BTII engine since it's the more advanced of the two, as opposed to importing BTII into BTI.
I'll just go over there now.
There is no directory on the disk. There are no "original" filenames. Tool programs can try to detect sector chains and create files from the chain it finds. So there is no directory to show you. After decoating the files (yet) the disk is unusable afterwards. Files can probably be extracted onto an empty disk, however that disk won't work in any way. To use BTII as an engine we first have to remove and replace or to modify the loader. Since likely BTII holds the whole wilderness and the present city in memory (as well as present dungeon), neither of that parts could be enlarged, probably maybe reduced...
Oh, the unexpected help came from a very wellknown C-64 cracker with earlier experience of EA protections like Pirateslayer. After a quick look he found out that it was protected in exactly the same way as an earlier title he had been working on some time ago. Applying the same theories on BT I proved to be a success. The information I got is also applicable on BT II and could open up the possibilities to work with that engine. Right now we can't do that - because as ZeroZero stated - we can't access the uncloaked files from that engine at the moment. With some work we might achieve that.Darendor wrote:What kind of unexpected help did you get anyways?
And I'd like to point out that the original idea was to make a BT editor work with the BTII engine since it's the more advanced of the two, as opposed to importing BTII into BTI.
Anyone wanna show me what the directories of the BTII disks look like?
Note the following though - the BT I isn't that limited. With the graphics provided from BTII you can easily make a 30X30 wilderness in the city-format which links to a town of almost any size - 10X10 to 30X30. Tricking the engine to load another citymap should be doable. The only thing is that it have to be done within a 30X30 map and you need to restrict access to the rest of the map by walls and by disabling teleport and PHDO. The alternative is to edit the rest of the map as "Wilderness" and use special events to determine entry and exitpoints. But I agree that the BTII engine is better.
Will upload the 15-20 files i've extracted from the BTII citydisk with a short explanation, awaiting the disk with ZeroZero's 100+ files. .-)
/Twoflower