Hacking games to use ZXpand/Chroma/Other joystick

[sirmorris]

Sparked by a query about adding joystick support to a scramble game I thought I'd start this thread to work through this exercise in public. I think this will be a chatty thread, but I'll try and make sure that the steps emerging from the process are summarised so the information doesn't get lost.

To be clear - this is not my thread. It's a collaborative space which I will provide input to. I hope others will contribute what they find out and get stuck with.

OK, to start. Gather your tools.

1. An emulator with debugging support.
People have their own favourites, I am no different. I didn't make any value judgements in my choice of EightyOne - it just kind-of happened. You are free to choose your own according to merit.

2. A development environment.
I routinely use Linux and MacOS however these platforms are not best supported for casual development. Many tools exist only for Windows, so that's what we'll use here. Arguably the most complete tool available at the moment is ZX-IDE. We'll use that too. Get the latest release from the first post of the documentation thread here at SZXW.

3. A target game.
SCRAMBLE 81 is requested so we have a winner.

OK, tools gathered - on with the fun!

How should this end up? Well rather than pollute the zx gene pool with lots of hacks and hardware-specific versions of programs I prefer writing a loader/patcher which works with an unmodified P file. The loader does everything necessary to the original program in order to make it work with a stick. This sounds more work and in some ways it is, but the benefits are many. Not least of which is the ease with which changes to the patch code can be made. There are examples (with source) of how this is done in some other threads. Use the search bar.

I should get some paying work done now so I'm out of here and I'll leave it to you to get this party started

C

[sirmorris]

Nice game.

So without even looking at the code there are some big clues.

scrmbl81.png (2.76 KiB) Viewed 4137 times

Check out the keys. They are (nearly) all full keyboard matrix rows. I bet if you play it then any key in the row ASDFG will move the ship up, and any in [SHIFT]ZXCV will move it down. Left and right are both located in a single row so there's something ever-so slightly different going on there, but it's not going to be complicated.

My first worry is how 4 directions and 2 buttons will map to a physical single button stick. Perhaps fire forwards and drop bombs could be combined?

[ilyad731214]

I came to: poke 22079,0; Poke 22080,0 causes the ship to continually drop bombs, i can not find where is the reference to directions and shot.

[sirmorris]

How much Z80 do you know on this or any other system?

[ilyad731214]

Zx81 was my first computer in 1988 but i did not have access to the programs and i did not know anyone who would have the same computer. Then I quickly switched to the Spectrum. I never met the Z-80 assembler thoroughly. Sometimes I fumbled in the game code on the Spectrum. Sometimes I was able to find immortality, I also made quite a lot of tape games to work with Timex FDD 3000 disk drive, which was quite popular in Poland. I also wrote some simple demos, but they have not survived in the web. Now that I have grown up children, I go back to hobby years ago

[sirmorris]

Your poke finding techniques should be a good place to start. As would address 22411 ($578B) which is the entry point to the machine code from the BASIC loader.

It looks like a nicely structured program.

disass.png (5.5 KiB) Viewed 4084 times

I'm guessing that one of these calls would be for reading the keyboard, one for updating enemies, landscape etc. Game stuff, you know.

So breakpoints will be added at each of the entry addresses. I don't want to have to step through if I don't have to. I might check out the call that has the LD HL,.. first - because that looks suspiciously keyboardish to me.

bingo!

bingo.png (5.64 KiB) Viewed 4084 times

[sirmorris]

Looking at the keyboard code I see bits being tested and functions being called. Again, I'm lazy so I don't want to manually work out what each function does, so I'll breakpoint the targets of the calls and see which one gets hit when I press a particular key.

The code looks like it's doing something different after the first 2 bit tests. The first 2 call a function if a bit is clear - meaning a positive key press. We then jump around some code if i bit is NOT clear - my guess is that we skip further tests if no key is detected in one of BNM.[SPACE].

Put breakpoints at 53AB, 53C9, 53E5, 53FE

Run the game and start pressing keys.

up - we hit function at 53AB
down - 53c9
left - 53E5
right - 53FE

So far, so good. The code following the movement keys seems to be drawing the ship.

The next function call at 55DA reads the keyboard again. Odd. I don't know why they just didn't store the previous value <shrug>.

kb2.PNG (7.51 KiB) Viewed 4062 times

So something happens when bit 6 is pressed. BP at 55E1 will tell us what. The breakpoint is hit when I press J so that's forward fire. If no forward fire is detected the code skips to 5602. Break there. Hmm, no more key test by the look of it. Perhaps the next function at 563a - the next CALL in the 'main loop' - continues the pattern? Ha! Yup.

kb3.PNG (7.81 KiB) Viewed 4062 times

BP at 5641. Boom! Or rather, BOMB!

OK. That's all the controls mapped out.

[sirmorris]

Anyone else fancy joining in? Anyone? Bueller? Anyone?

[Andy Rea]

I'm following the thread, for future reference

Regards

[sirmorris]

Excellent. Right up your street Mr Rea!

So what I think should happen is that we replace the call to KEYBOARD with our own function which clears bits according to the detected joystick direction.

JS UP - will clear bit 1 of L
JS DOWN - clears bit 0 of L
JS LEFT - clears bit 7 of L and bit 4 of H
JS RIGHT - clears bit 7 of L and bit 3 of H
JS FIRE - clears bit 6 & 3 of L so we shoot both weapons at once

So how to make this happen? Change bytes at 536B, 563A and 55DA to call my own input routine.