| |
Saxxon
Account closed
Registered: Mar 2009
Posts: 12 |
Legend of Blacksilver [help needed]
Hey.
I've been working on a Legend of Blacksilver EasyFlash crack for some time now. I've hit a wall, however- while the game itself is cracked, bugfixed and trained.. it's missing docs, a disk saver, and a proper intro. I don't have the skills for any of these things.
I haven't found anyone to take the project over. So I present my development environment in hopes that someone will find interest in it and finish what I've started.
CC65 is the assembler for the loader/trainer, C64List was used to manipulate the game's BASIC code, and C# was used to create the cartridge building application that is used to compile the CRT file. All source and research documents are included, as well as the files directly extracted from the original media.
Running the "build.bat" file in the LoB folder will create an immediately playable CRT file in the same folder.
If you have any questions, you'll get a much faster answer at my e-mail: saxxonpike@gmail.com
This is released with only one restriction: if a modification is made and uploaded to CSDB, be sure to credit appropriately. Anything else you wish to do with any and all of the code is solely up to you.
The game is fully playable to the end and doesn't need any further bugfixes as I can tell. All that's missing are docs, disk saver and a good intro.
https://www.dropbox.com/s/72re3td77vihkam/LoB.zip |
|
| |
Rough
Account closed
Registered: Feb 2002
Posts: 1829 |
How come disk saving is missing? There's surely one in the original. |
| |
Fungus
Registered: Sep 2002
Posts: 686 |
This was a very complicated and time consuming crack to do. I for one, am pretty impressed with the work he has done on this. He understand the game code quite well and did a fantastic job all in all. He just lacks the drive coding skills a lot of us already have, and also the demo coding skills to create an intro. Typing up the docs is well within his skill set but I don't think he knows how to code a good docs display routine.
I am hoping someone with some skills can pick up his work an finish it, it certainly deserves it. A disk version too would be nice ;)
Rough: The original game uses the last version of Vorpal, not so easy to just use that code base, if that's even desirable. IMO it's not, and a standard kernal loader is what he wants. |
| |
Broti
Registered: Aug 2004
Posts: 15 |
I could supply the manual as txt |
| |
Rough
Account closed
Registered: Feb 2002
Posts: 1829 |
slapping all this stuff together plus an intro shouldn't be a big thing when Saxxon reveals the riddle behind the missing disk saver (now I hear people say "Don't babble, just do it!", I have no experience in easyflash programming at all thou)
@Broti: A scan of the original manual would be more appropriate. .txt files often miss passages of text (e.g. from the packaging) |
| |
Broti
Registered: Aug 2004
Posts: 15 |
Got a scan as pdf too ;) |
| |
Rough
Account closed
Registered: Feb 2002
Posts: 1829 |
Just found it too: http://ia601707.us.archive.org/26/items/Legend_of_Blacksilver_T.. |
| |
Broti
Registered: Aug 2004
Posts: 15 |
The same file as in my docs archive |
| |
Saxxon
Account closed
Registered: Mar 2009
Posts: 12 |
I'm glad to see there is some interest :)
There was some information missing from the Readme...
Cheats are done by injecting pre-calculated 40bit values to specific addresses in the BASIC variable space. Because the game itself relies on exact positioning of these variables already, this is something I could safely do.
Saving to disk is trivial- as far as I know, it just saves a 4kb snapshot of 9000-9FFF, which is where the BASIC variable space is located. The original saver sends a message to the disk drive to disable the special loader, uses a Basic command to save the file (it is a modified routine, but the end result is a simple memory write) then reenables the loader again.
I also export the block of memory, but to EF instead of disk.
When I save to EF, it starts at 07:0:1000 and works its way back in 4kb increments, using only the low bank. Because you can only wipe 64kb at a time, it will just write new saves at a lower offset. When 00:0:0000 is consumed, the 64kb block of low flash is wiped and it writes again to 07:0:1000. This is the reason why multiple saves are not allowed- the amount to wipe is too large for me to preserve any current saved games. The currently saved game is found by starting at 00:0:0000 and checking the byte there, doing so at 4kb increments. If a byte is found that is not $FF, it must be the saved game.
Getting 4kb of data from memory to a file on disk should really be trivial, and I'm willing to wager that I'm overthinking it..
I don't feel that I have adequate skill to create a front-end for a disk saver, nor enough familiarity with the Kernal anyway. I also don't even know where to start with a reader.
EDIT: I would also like to add, for anyone who might have interest in a disk version...
"LoB/original-media/extracted" is the folder which contains all the files in their decoded, unmodified form. I did two kinds of patches: BASIC patches and assembly patches. All the assembly patches I've done are contained in "LoB/docs/PATCHES.txt". Most of them are specific to the EasyFlash code. The BASIC patches are a lot more involved- you can see the updated code in each of the .lbl files in "LoB/build", and the original versions of these files in "LoB/original-media/sources".
A word of caution: the in-game saver BASIC code does something I don't fully understand but was required to make the game work. If you take a look at "223.lbl", "361.lbl", and "451.lbl", you'll notice that there's a little goto hack. This line also existed in the original code. Taken as BASIC code on its own, it's not supposed to do anything. This specific line number has to exist in both the saver stub *and* the main game code and I suspect it has something to do with what line of code the saver returns to when switching back (as they are separate BASIC programs). C64List kept wanting to optimize away these "unused" lines which broke everything.
The original saver also checks for a character's presence on the currently inserted disk. In the EF version, our character disk is *always* inserted, therefore this check and the "change disk + press a key" prompt are replaced with a simple sound effect in all 3 of the saver stubs.
Finally, the Vorpal format allowed for storage of more game data than you would ordinarily have using CBM format. The data on each disk side is greater than a disk's capacity, so compression will be required. The game data is very well pruned; I saw no unused data except one "blank" file (26). |
| |
the-joker
Registered: Oct 2013
Posts: 2 |
Quoting Saxxon
Running the "build.bat" file in the LoB folder will create an immediately playable CRT file in the same folder.
Hello Saxxon,
i can not build the CRT. Where can i find the C# program "CartridgeBuilder" ? |
| |
Saxxon
Account closed
Registered: Mar 2009
Posts: 12 |
Ah! I just realized I created the archive without including the tools. A bit embarassing..
Here's everything:
https://www.dropbox.com/s/cxlievmlkmbua0k/C64CART.7z |
... 6 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
