Adventure was easy to double...since all of the display routines are right in the first 256 bytes of the program. So all that needed to be done was grab those routines and paste them into a new assembly...along with any GFX...and the Curr and Info tables pertaining to them. Then they can be completely removed from the main code...cutting it down in size to just over 2k The free area in the display bank is well over 2k.
At the top of each file, a bankswitch instruction is placed in to jump back and forth between the display and the main program.
Compiling the roms...
They must be done independantly...and the 4k binaries pasted together to create the 8k rom. What you'll need to do is compile the first part with the -s switch added (so Dasm will create an equate table for you that can be added to the second part). I dunno any other way of doing it, but it's not that much of a pain. Instructions...
dasm ad1.asm -f3 -seq.txt -o1
This command will compile the first half of the game. All of the addresses where each graphics object "lives" in the first bank will be put into a seperate text file called eq.txt, and the binary will simply be called "1"
Open that eq.txt file. You'll see all of the labels that were used in the first assembly (equates)...as well as every address where those labels compiled to. You'll need to copy every label/address identifying GFX tables, and paste that info to the top of the second assembly file. You'll see labels for ram locations ® and program lines as well...these do not need to be transferred. Just the GFX tags. Once pasted, insert an "= $" before each address, and then save it. Open the second assembly and look at the top for an example.
Now that the second assembly "knows" where everything is, you can just compile it to create the 2nd 4k binary...
dasm ad2.asm -f3 -o2
Now you have both 4k binaries...and you can join them together...
copy /b 1+2 adhack.bin
This copy command uses the binary mode to combine both files (1 and 2) into a new file (adhack.bin). Once combined, you can open and run it using any 2600 emulator
Things to be aware of...
Make sure that your screen GFX bitmaps do not cross page boundries if you add additional ones...or you'll end up with small pixel "skews" on some of them (because it will take 1 cycle longer for the kernal to access them). This problem had me stumped for awhile until I got wise
These days, I try to make sure that all data never crosses pages. When assembling, I just add ORG tags for each page and fill them up...working my way from $FF00 to lower addresses. When Dasm reports that I go over, I just remove the number of bytes that it says and put them higher up in the assembly file...and then try again. Fortunately, the map data lines do not matter if they cross a page (so you can have up to 64 screens in the original optimized code).
The assembly files below have a few ORG tags added to avoid page crossing. These can be removed as you fill in memory...but it's a good idea to keep the very last one (so that Dasm will warn you if you go over the 4k limit for that bank). All of the memory between ORG tags has not been exhausted completely.
Adding rooms to the program is a cinch...just copy/past an existing line in the room data matrix found near the end of the 2nd assembly, alter the variables, and voila...a new room has just been added! The current code allows for a maximum of 64 rooms, but the program can be altered slightly to allow for more than that. The new rooms will not be accessable until the room link data is altered to "point" to them. 5 additional rooms are added for an example (the "Custom" rooms).
Adding objects, castles, dragons, etc. is more complex. You'll need to reorganize the ram used by the existing objects to insert free ram to hold the values used by the added ones. All dragons and castle gates, for example, must be sequential ram locations in memory...and the last object must be the "null" sprite.
Added objects will require 3 bytes of ram each...the room number and X/Y locations. Added castle gates will require 1 byte of ram (to hold the state it's in)...and added dragons will require 5 bytes of ram (3 bytes like objects, plus variables to hold it's state and movement). The bat requires 7 bytes...the same as the above plus 1 byte to hold the object that the bat is carrying and 1 byte to indicate how long it's been holding it.
Of course, the routines will need to be altered to handle new gates, dragons, or bat. Other objects require very little changes (aside from any special coding to handle their functions).
Of course, any additional game sprites will need bitmap data added to the first assembly...and any changes to the first assembly must be followed by copying the equates to the second assembly.
Free ram: locations $E7 to $F7 are unused by the original game (17 bytes). These can be used immediately in any way that you want. An additional 2 bytes can be reclaimed by changing the routines that include the "Temp" location $D8 and the input counter $E6.