Here's the README:
Code: Select all
Citadel BBC Reassembly v0.1, 8th October 2018 Original game by Michael Jakobsen Disassembly / reassembly by 'Diminished' --- INTRO This is a set of files -- including reverse-engineered source code -- that will enable you to build a Model B version of Citadel. YOU WILL NEED - BeebAsm (http://www.retrosoftware.co.uk/wiki/index.php?title=BeebAsm) FILES - 6502 source: - citadel.asm main source file; assembly directives are in here (D_*) - consts.asm most of the constants (C_*); chained by citadel.asm - vars.asm memory locations of variables and tables; chained by citadel.asm - shim.asm short move-down routine and final initialisation code; chained by citadel.asm - BASIC source: - loader.bas the BBC BASIC loader used to launch the game - Data: These are pure data files and no code resides in them, although certain parts of x740.bin encompass regions which are used by the game as variables. - x600-f.bin female player sprite data residing at &600 (320 bytes) - x600-m.bin male player sprite data residing at &600 (320 bytes) - x740.bin main data file; mostly room/tile data and room names, starting at &740 (7,616 bytes) - Others: - template.ssd a BBC disc image used by BeebAsm as a template; it contains a single file called JEZEBEL, which is just a Beeb-native copy of loader.bas - build.sh a bash script which may be used to build the game BUILDING IT Simply: beebasm -i citadel.asm -do jezebel.ssd -di template.ssd -v which will create a disc image called jezebel.ssd with everything you need to run your newly minted game. Put the image somewhere appropriate, and then CHAIN "JEZEBEL" to load the game. If you are building on a system with bash, you can use the provided build.sh to build the game. You may need to edit the file so the correct path to BeebAsm is specified. If you are looking for things to modify, consts.asm is definitely the place to begin, along with the directives (D_*) at the top of citadel.asm. BUGS - picking up the very first energy flask in the game emits the wrong sound effect OTHER ISSUES There are some problems with relocating pieces of code. In particular, if you are building a non-retail version (D_RETAIL = 0) with a keyboard control scheme (D_CONTROL_SCHEME < 4) it ought to be possible to reclaim the bytes before the keyboard map (T_KEYMAP) that are usually reserved for the absent and slightly larger joystick routine. However, reassembling all the code north of this point at a lower address causes serious player sprite corruption, and the reason is currently unknown. Note that this bug seems to persist even using an (emulated) CMOS 6502 which lacks the JSR page boundary bug, which I originally suspected to be the culprit. The D_NON_RETAIL_PADDING_BEFORE_KEYMAP flag exists for this reason and should be set to 1 for non-retail builds to ensure that the unused joystick routine bytes are reserved as in the retail versions. Disassembly / reassembly is a work in progress, so some variables and routines are still poorly labelled and understood, and mistakes are likely. There is currently no Master 128 support; you can only use this to build for the Model B. ABOUT THE LOADER I wanted the simplest possible loader setup, without the need for arcane assembly language initialisation routines and multi-stage relocations. So JEZEBEL (a.k.a. loader.bas) changes to MODE 2 straight away, and sets up nearly all of the OS and CRTC parameters needed by the game right there in BASIC. It then disables the cursor and performs a *OPT 1,0 to suppress any filing system messages, before quite happily loading 16K of 400IMG plus the small move-down/final initialisation shim into "live" video RAM. This simplifies everything greatly, but has the disadvantage that any filing system errors (particularly cassette filing system errors) will not be reported to the user. The only functions performed by SHIM, the tiny piece of 6502 initialisation code, are moving down the main code to &400, setting up the stack and enabling the OS vector that allows the game to react to vertical sync. The run-time patching performed by the game's retail loader for choosing the gender of the player sprite and the control method has also been simplified out of this implementation. Player sprite and control scheme selection are implemented here as traditional conditional assembly language directives (in consts.asm), so if you want to support all ten combinations (five control schemes and two genders) then you will need to assemble the game ten times.