Lou's Pseudo 3d Page

Chase HQ was a great game on the ZX Spectrum. I got an original 48k release copy when it came out so that I could crack the loader for school and drop pokes in. After seeing your comment I thought I'd have a look in an emulator and see how long it'd take me to walk through the loader with modern tools.

The original release uses Paul Owen's protection system, which is really just a headerless loader and some playing around with system variables. If you want a bit of lunchtime fun, go and get an emulator with a debugger, get the original from WoS[1] and switch off all the tape loader acceleration. Type LOAD "" (Usually J, alt-p, alt-p on a modern keyboard) and press return, then make sure you're playing the tape.

If you load it you'll get an initial basic loader, then a screeching red and black striped loader which sets up the initial load.

The loader uses the IX and DE registers to specify where to load the next block of data and how much data to load respectively. The initial bit of data loads in at 0x8200 and is 0x0200 long.

If you break in your debugger after that initial high pitched red and black bit you should be able to see that the IX register will point to 0x4000 and DE will point to 0x1800, 0x4000 is the start of screen memory, which is 6144 bytes (or 0x1800) long.

After the screen loads you'll see the next block (at 0x5B00, 0x4A80 long) - this overwrites the system variables and lower parts of memory. As this is in contended memory it runs more slowly than the rest, this should be used to store the main system code that makes sure everything's ticking along with some of the code to handle bits between the levels and the text used in the game. It's been nearly 25 years since I've hacked ZX spectrum games on a regular basis so I could be wrong.

The following block loads into 0xC000 (IX) and is 0x3F00 (DE) bytes long, which if memory serves is the main in-game code and some game assets but again it's been a long time and I might be wrong. I'd expect music to be up here too and any time sensitive code such as the code handling the countdown timer for the game.

After this a small two byte header is loaded into 0x5BD5 which is used to load a small header. Another block overwrites system variables again at 0x5C00 and some of the earlier loaded game material then jumps to the main game code where it loops around FEFE jumping to the music player and keypress check starting at EF19.

If once you're in the game you want to have a fiddle, go to the redefine keys option and redefine the keys to be "SHOCKED" then press enter for the last key to enter test mode for the game. The 48k version is a multiload game which means each level is loaded from tape. I think the 128k version is similar but with music, but I never looked at the 128k version.

I would've been able to do a bit more with something like ZX32 (which is what I used to fiddle with) but I'm on a Mac and half the fuse debugging stuff doesn't work. Still, it's amazing what you can do with emulators these days compared to my multiface one. I would've killed for tools like this!

Wow man, you remember how to do all that. That stuff bring back so many fun memories.

I was younger at the time (13-14) but I got to play with assembly. Remember typing up my own assembly interpreter for fun.

You obviously got into it a lot deeper. I wonder how many kids turned to liking computers because of ZX Spectrum philosophy of dropping the user straight into a programming shell. Other game consoles drop you in some kind of greeting loader screen, so you never see a programming prompt.

I recapture some of the thrill of working closer to hardware, I got a Beaglebone Black. But could never quite get excited about it. I find it more interesting now to learn a new programming language or build a small game or hack on an open source project.

> I would've killed for tools like this!

Exactly. I remember doing POKEs and messing the game up then having to load everything again. Having an emulator and debugger would have been a lot more fun.

The actual answer to your question is that the Atari 2600's fundamental limitation is sprites per scanline, not per screen. It can draw lots of objects by reusing sprites across many scanlines, but can't draw many objects that need to move independently in vertical space.

So you can draw the "3D" racetracks by reusing two sprites all the way down the screen for the road boundaries, but you can't draw three Pac-man ghosts on the same scanline so you have to flicker between them on alternate frames.

That's the hard part(for me, and you apparently). That's why I think it's a good thing to have people with different personalities in a project. Some like to start and organize things, some like to finish things.