BT 1 file list on CBM64
Looks like some lookup table, maybe for calculations. Often used to get a value from a table rather than calculating it every time you need it. Was popular on slow computer systems e.g. for sinus/cosinus values and such.2600 - 2800 - No idea. Byte by byte identical in BT2.
Instead of calculating sinus for 30 degrees, get that value from table position 30. Calc once at program start, then use fast. Can have to do with bitmap packing or sound table.
According to Sailor, there are three different disk-releases of Bard's Tale. The first release (big box?) is probably protected by Kris Hatlelid's (smart canadian, author of much nice C64 stuff) first version of Pirateslayer. Then we had the second release (big folder) which used Pirateslayer V2, probably since the original version had a tendency to not work on newer drives like the 1541-II. The last release is the european PAL (small crystal case) version which seem to have been identical to the second american. To cut it short - this protection is generally concidered to be one of the worst and most tedious ones, even by experienced crackers. The versions we see floating around on the net are generally cracked - the copyprotection is no more, but they haven't rid the disks of the way it reads the data and how the data is structured. It still uses Kris Hatlelids loader, everything is still encoded - but now you can atleast copy the floppy. In the case of BT II, this means that you can play the game, but not extract any data. All information on the disks are EOR-encoded and there are no track/sectorlinks to follow to extract files.Darendor wrote:As you're apparently a member of Triad, could you tell me (us) about this Pirateslayer and how it's protecting the BTII game?
Here are some in depth facts about Pirateslayer.
/Twoflower
I found this page: http://www.atlantis-prophecy.org/recoll ... ticle&id=3Twoflower wrote:According to Sailor, there are three different disk-releases of Bard's Tale. The first release (big box?) is probably protected by Kris Hatlelid's (smart canadian, author of much nice C64 stuff) first version of Pirateslayer. Then we had the second release (big folder) which used Pirateslayer V2, probably since the original version had a tendency to not work on newer drives like the 1541-II. The last release is the european PAL (small crystal case) version which seem to have been identical to the second american. To cut it short - this protection is generally concidered to be one of the worst and most tedious ones, even by experienced crackers. The versions we see floating around on the net are generally cracked - the copyprotection is no more, but they haven't rid the disks of the way it reads the data and how the data is structured. It still uses Kris Hatlelids loader, everything is still encoded - but now you can atleast copy the floppy. In the case of BT II, this means that you can play the game, but not extract any data. All information on the disks are EOR-encoded and there are no track/sectorlinks to follow to extract files.Darendor wrote:As you're apparently a member of Triad, could you tell me (us) about this Pirateslayer and how it's protecting the BTII game?
Here are some in depth facts about Pirateslayer.
That explains it crashing when trying to freeze - it checks for a cartridge.Pirate Slayer and Prodos Games, one of the most difficult set of loaders due to their overloading of themselves several times and timer encryption, as well as cartridge checks for things like Action Replay (before they existed no less). Arctic Fox, Legacy Of The Ancients, Skate or Die, Ski or Die, The Bards Tale, etc.
So BTII was made copyable, but the copy protection still exists and prevents people from examining the files and stuff. But you were able to transload BTII images into the BTI engine, so how did that work?
Yep. It may crash because of two reasons - 1) cartridge check / a freeze screws up the zeropages or 2) because the loader freezes up or 3) both.Darendor wrote:That explains it crashing when trying to freeze - it checks for a cartridge.
So BTII was made copyable, but the copy protection still exists and prevents people from examining the files and stuff. But you were able to transload BTII images into the BTI engine, so how did that work?
I extracted the data by clearing the area I believe is the drivebuffer in the memory with VICE-mon. Once the new data I wanted was loaded, I resetted the program, and hunted down the plausible data in memory with the Action Replay monitor, saved out what I believed to be the full lenght of the file and attempted to force-load it into an event in BT I. It worked on my first attempt.
The bad thing about this is that f.ex the animations are rather picky. I've managed to screw up loads of animations by cutting them short.
/Twoflower
Alright, I am not sure I understood all that, but anyways....Twoflower wrote:Yep. It may crash because of two reasons - 1) cartridge check / a freeze screws up the zeropages or 2) because the loader freezes up or 3) both.Darendor wrote:That explains it crashing when trying to freeze - it checks for a cartridge.
So BTII was made copyable, but the copy protection still exists and prevents people from examining the files and stuff. But you were able to transload BTII images into the BTI engine, so how did that work?
I extracted the data by clearing the area I believe is the drivebuffer in the memory with VICE-mon. Once the new data I wanted was loaded, I resetted the program, and hunted down the plausible data in memory with the Action Replay monitor, saved out what I believed to be the full lenght of the file and attempted to force-load it into an event in BT I. It worked on my first attempt.
The bad thing about this is that f.ex the animations are rather picky. I've managed to screw up loads of animations by cutting them short.
...
So are the datafiles still called "NMxx" or whatever, or are they different?
That's the catch - there are no files. No visible ones, no interlinked ones on the disk - all thanks to Pirateslayer. I have been forced to save things out of the memory, coming to conclusions after f.ex comparing the contents of the C-64 RAM before and after an encounter.Darendor wrote:Alright, I am not sure I understood all that, but anyways....
...
So are the datafiles still called "NMxx" or whatever, or are they different?
/Twoflower
So, there are for sure no files on the disks at all. All the information is directly written to disk using block read/write routines.Twoflower wrote:That's the catch - there are no files. No visible ones, no interlinked ones on the disk - all thanks to Pirateslayer. I have been forced to save things out of the memory, coming to conclusions after f.ex comparing the contents of the C-64 RAM before and after an encounter.Darendor wrote:Alright, I am not sure I understood all that, but anyways....
...
So are the datafiles still called "NMxx" or whatever, or are they different?
I've noticed things like "LICK MY USER PORT!" and "OUT OF MY CODE HACKER!" while examining the disks using Disk Doctor.
Well-
... for BT II at least the boot disk is fully uncoatable and follows several file links. I used C64Copy with ALT-F3, "CheckImage". The Boot disk worked 100%, however maybe ON the boot disk might be a table for block linking on following disks, ignoring the links on the further disks, or, using the full 256 bytes of a sector and ignoring the link bytes at all. Using the emulators monitor should always enable you to make mem shots, no matter what C64-protection is set by any software. I will try later with CCS.
BT 1 engine has no wilderness, but it has a nice bigger city (30x30) and bigger dungeons (22 x 22) than BT II, else they needed yet another disk for BT II and got in trouble with main mem
Btw, Twoflower: where is the font? I think it must be gfx output rather than a font, since it is kinda antialiased and when it scrolls it is unsmooth (at least on a PAL system). Did you find that yet?
For the monsters and items I have no further idea than to track down a encounter event and try to find the tables, then search them in the files. I didn't see any structure in any file yet that immediately alerted me to be that data (unlike e.g. city maps or store).
... for BT II at least the boot disk is fully uncoatable and follows several file links. I used C64Copy with ALT-F3, "CheckImage". The Boot disk worked 100%, however maybe ON the boot disk might be a table for block linking on following disks, ignoring the links on the further disks, or, using the full 256 bytes of a sector and ignoring the link bytes at all. Using the emulators monitor should always enable you to make mem shots, no matter what C64-protection is set by any software. I will try later with CCS.
BT 1 engine has no wilderness, but it has a nice bigger city (30x30) and bigger dungeons (22 x 22) than BT II, else they needed yet another disk for BT II and got in trouble with main mem
Btw, Twoflower: where is the font? I think it must be gfx output rather than a font, since it is kinda antialiased and when it scrolls it is unsmooth (at least on a PAL system). Did you find that yet?
For the monsters and items I have no further idea than to track down a encounter event and try to find the tables, then search them in the files. I didn't see any structure in any file yet that immediately alerted me to be that data (unlike e.g. city maps or store).
It's font allright. It is located at $15D0 and onward in memory. I believe there is one normal and one inverted version in memory. I honestly don't think they have been visionary enough to visually invert the font by changing the colors. If you look at the structure of the data in memory by 15D0, just after the first files are loaded you can see a very typical "charstructure". I've got that set in my backbone since I ripped C-64 fonts in the early nineties.ZeroZero wrote:Btw, Twoflower: where is the font? I think it must be gfx output rather than a font, since it is kinda antialiased and when it scrolls it is unsmooth (at least on a PAL system). Did you find that yet?
I believe the font is plotted on a char- (or on sprites?! I would probably do that!) screen and that they actually transfer memory for 7 pixels, 1 pixel at the time, to make it look like scrolling. Glitches are probably caused by it beeing NTSC-code. The Bard's Tale logo is also in chars and is located at apx. $2000. I should really memorymap the game and the two modules. We allready got quite some directions on the routines and the tables.
/Twoflower