Atari Battlezone

[Rocketeer]

For the Acorn Electron/BBC B with 16k SWR, BBC B+/Master 128 and optional ARM7TDMI/Pi CoPro second processor.

The attached disk image will run on all the above machines but when running on the Electron it will benefit greatly from having some acceleration either emulated or actual hardware i.e. the Slogger Turbo Board.

Quick start - press "C"(oins) twice then "B"(attlezone) to play, "A","Z","K","M" to move, "Space" to fire and "F" to toggle second processor on/off.

On the disk image see files:-

readme - full instructions to get playing.
credits - various routines used for Atari Battlezone and where they came from.
notes - extra information and tidbits about Atari Battlezone.
version - version history.

These are attached to this post and are available within your machine by changing to MODE 0, CTRL-N to scroll lock and then *TYPE <filename>. Use the SHIFT key to page through the file.

[EDIT : The files have now been updated, principally a sound issue caused by a direct keyboard read conflict - most emulators were okay and rotational speed of the player's tank is double when opposite directional keys are pressed.]

[Ukwebb]

very nice job

[jms2]

Wow, that's an amazing piece of work, well done! I have only played it in BeebEm (with ARM7TDMI) so I imagine it's even better with the 1GHz ARM.

I do have a couple of questions about gameplay - I assume these apply just as much to the original as it seems so authentic, but I'm interested to know the answers anyway: if you drive the two tracks opposite to each other, it doesn't seem to rotate noticeably quicker. And also, sometimes when an enemy tank appears it starts rotating immediately, and has fewer degrees of rotation needed to face you than you need to rotate to face it, so you basically can't beat it. I guess this is all just part of the game?

[mike12f]

That is amazing. Hopefully it will end up on the https://www.bbcmicro.co.uk/ soon.

It looks arcade perfect. Has this been created from the original ROMs somehow?

What is the way to get the fastest frames per second on B-em or BeebJit? I tried B-em with a Tube ARM co-processor, but it didn't seem to run any faster than without the co-processor. I'm not sure if I did it correctly though.

[jms2]

My version of B-Em only has a Arm Evaluation system co-processor, The game can't use this, as it doesn't have the MUL instruction. So that could be your problem - you need either an ARM7TDMI or a Pi.

[Rocketeer]

Wow, that's an amazing piece of work, well done! I have only played it in BeebEm (with ARM7TDMI) so I imagine it's even better with the 1GHz ARM.

I do have a couple of questions about gameplay - I assume these apply just as much to the original as it seems so authentic, but I'm interested to know the answers anyway: if you drive the two tracks opposite to each other, it doesn't seem to rotate noticeably quicker. And also, sometimes when an enemy tank appears it starts rotating immediately, and has fewer degrees of rotation needed to face you than you need to rotate to face it, so you basically can't beat it. I guess this is all just part of the game?

Firstly the 1Ghz ARM won't give a big improvement in speed, all the functions the BBC tells the ARM to do then it can return the results without the BBC having to wait, all except one. The ARM will render a line, the BBC passes coordinates and it returns a sequence of screen addresses and pixels. For lines above about 128 pixels long the BBC reading data catches up with the ARM creating the data so for line drawing I institute a polling routine until the results are all ready. Since most lines are not longer than 128 pixels, unless objects are close up, then the ARM data will be ready the first time the BBC polls. Interestingly the Atari Mathbox takes a similar approach, for most functions it reads the results straight away, others it executes a CMP (zero page,X) instruction, delaying for 6 cycles, and the rest it loops polling a register that changes value when the result is available.

About the tracks. Rotating faster when they are pressed in opposite directions is how I initially implemented it but when Andy McFadden's disassembly became available I saw that this is not the case, it rotates at the same speed regardless. Your tank rotates according to a 9-bit angle, 512 degrees, the enemy tank rotates according to an 8-bit angle, 256 degrees, so straight away it has a turning advantage. It gets worse. For normal tanks then as your score climbs it becomes more aggressive by being able to rotate even faster in it's attempt to take a shot at you.

Thanks for the excellent questions, hope I've answered them for you.

[Rocketeer]

That is amazing. Hopefully it will end up on the https://www.bbcmicro.co.uk/ soon.

It looks arcade perfect. Has this been created from the original ROMs somehow?

What is the way to get the fastest frames per second on B-em or BeebJit? I tried B-em with a Tube ARM co-processor, but it didn't seem to run any faster than without the co-processor. I'm not sure if I did it correctly though.

Yes, certain code portions are from the Battlezone ROMS revision 2, but apart from the 6502 processor the arcade machine and BBC/ARM are radically different machines requiring different solutions.

Frame rate wise I wouldn't expect any difference between emulators because that's how they work. With the ARM enabled it can get up to about 10 frames a second which is close to the original's update rate of 16 frames a second.

[jms2]

It's great to hear about these details, especially as they come from the original roms. I'm looking forward to visiting those source websites you have cited.

About the tracks. Rotating faster when they are pressed in opposite directions is how I initially implemented it but when Andy McFadden's disassembly became available I saw that this is not the case, it rotates at the same speed regardless.

Interesting. Maybe Atari thought it made the game too easy if you could rotate faster.

Your tank rotates according to a 9-bit angle, 512 degrees, the enemy tank rotates according to an 8-bit angle, 256 degrees, so straight away it has a turning advantage.

Just to make sure I have understood correctly, do you mean that your tank rotates by steps of 360/512 degrees whereas the enemy rotates by steps of 360/256 degrees?

[strawberrytau]

Impressive!

Can I clarify which PiTubeDirect copro works with this? I’ve tried 15 (Arm) but it fails to boot with “This is not ARM code”.

What command do I use to put the Pi in the right mode?

[Rocketeer]

Interesting. Maybe Atari thought it made the game too easy if you could rotate faster.

I'm inclined to think that Atari chose whatever looked good on screen as the AI could then be easily tweaked to accommodate their choice.

Just to make sure I have understood correctly, do you mean that your tank rotates by steps of 360/512 degrees whereas the enemy rotates by steps of 360/256 degrees?

That is correct.

[Rocketeer]

Impressive!

Can I clarify which PiTubeDirect copro works with this? I’ve tried 15 (Arm) but it fails to boot with “This is not ARM code”.

What command do I use to put the Pi in the right mode?

I don't have a copro myself but I am informed that this should be an informational message only for the 1Ghz option. It should boot into the game where you can toggle the ARM on/off with the "F" key. However, yours doesn't seem to do that unless there are other ARM options from your documentation?

[strawberrytau]

I don't have a copro myself but I am informed that this should be an informational message only for the 1Ghz option. It should boot into the game where you can toggle the ARM on/off with the "F" key. However, yours doesn't seem to do that unless there are other ARM options from your documentation?

I’ve tried mode 15 and mode 12 on the PiTube (which I think are the only ARM options) and neither work, unfortunately. The game just fails to start. The machine pauses for a second after the *RUN command and then returns to the command line with a beep. Even *BASIC raises an error message during the !BOOT.

The game still runs pretty well without the copro though! Impressive work!

[strawberrytau]

Actually I wonder if there is something wrong with my PiTubeDirect setup as I think *BASIC should work.

Edit : No. It looks like this is expected behaviour.

viewtopic.php?p=376202#p376202

[fizgog]

Looking very impressive considering Atari having a math box in these games

I also like the little Atari logo animation

[tricky]

Great port.
I thought the same thing about rotating but then forgot to check MAME.
If you are running an emulator and want faster gameplay, you could just up the emulated speed 2-3 X was good for me although whichever emulator it was want very happy with the sound like this.

[Rocketeer]

Great port.
I thought the same thing about rotating but then forgot to check MAME.

Because of the same rotational speed it makes sense not to turn on the spot using two keys. Just use one key as that also moves you along in the direction of travel of the track so presenting a moving target to the enemy tank.

[Rocketeer]

Looking very impressive considering Atari having a math box in these games

I also like the little Atari logo animation

Thank you!

[DutchAcorn]

Impressive port Rocketeer! Playing Battlezone is one of my earliest arcade memories.

The game really benefits from a second processor as a math box, gameplay on real hardware is a bit too slow for my liking, esp. compared with the speed of the original arcade. So I've been playing on beebem with speed x2.

Regrettably I can't test with a pi ARM7 second proc (don't have one), it would be nice to have it working with the ARM1 second proc.

[Rocketeer]

Regrettably I can't test with a pi ARM7 second proc (don't have one), it would be nice to have it working with the ARM1 second proc.

I did try initially to get it working on an ARM1, having a multiply routine to use to cover for the lack of MUL/MLA instructions, but try as I might I just couldn't get the code running on there to acknowledge to the BBC that it was present.

[mike12f]

It looks arcade perfect. Has this been created from the original ROMs somehow?

Yes, certain code portions are from the Battlezone ROMS revision 2, but apart from the 6502 processor the arcade machine and BBC/ARM are radically different machines requiring different solutions.

Could you tell us more about how much of it is coded from the Atari original ROMS and how much is bespoke creation? For example, there are "insert coins" instructions in the game, which is obviously a nod to the arcade machine. Is that something you've put in for authenticity of the look of the implementation, or is it because the code has been directly converted from the ROMs in the majority of places?

Anyway, it looks fantastic!

[Rocketeer]

It looks arcade perfect. Has this been created from the original ROMs somehow?

Yes, certain code portions are from the Battlezone ROMS revision 2, but apart from the 6502 processor the arcade machine and BBC/ARM are radically different machines requiring different solutions.

Could you tell us more about how much of it is coded from the Atari original ROMS and how much is bespoke creation? For example, there are "insert coins" instructions in the game, which is obviously a nod to the arcade machine. Is that something you've put in for authenticity of the look of the implementation, or is it because the code has been directly converted from the ROMs in the majority of places?

Anyway, it looks fantastic!

The paragraph below details what came from the Atari ROMS, I'd already written a great deal before they became available for study. For instance the service mode and coins etc had already been written so there was no need to lift code for these (indeed the Atari code interfaces with the Pokey chip so it would have made sense to re-write this anyway once it was understood what it was doing). I did strive to give as authentic a feel as possible by including such things as coins.

Enemy AI, your tank movement, 3D meshes and drawing commands (it draws the object line segments in the same order), landscape line segments, collision detection. I would estimate about 15% of the codebase came directly from there (but it did need quite a bit of re-work to fit in with the data structure I'd already decided on), the rest had to written for the BBC as they really are two different machines. For instance the combat messages at top left are sprites, it's just not fast enough to "draw" these on.

When this version proves to be stable I shall be releasing the source code on GitHub.

[Ramtop]

Oh, this is excellent! Battlezone was the first video game I ever played, having it on the Elk is wonderful.

I spent a little time performance testing on a stock Master and an Electron with a 4.6MHz 65C02 accelerator installed, the Elk is faster but not by as much as I expected.

And I noticed that the game won't boot on my Electron with an ElkSD64 attached. Rocketeer, does your code check if the first sideways ram bank it finds is already in use? if it doesn't I suspect that may be the issue as it'll be overwriting the MMFS file system.

[marcusjambler]

Brilliant... I spent hours on this game... Thanks for porting it

[Rocketeer]

I spent a little time performance testing on a stock Master and an Electron with a 4.6MHz 65C02 accelerator installed, the Elk is faster but not by as much as I expected.

And I noticed that the game won't boot on my Electron with an ElkSD64 attached. Rocketeer, does your code check if the first sideways ram bank it finds is already in use? if it doesn't I suspect that may be the issue as it'll be overwriting the MMFS file system.

I had no idea such an accelerator existed for the Electron, thanks for the feedback on this.

You're probably right about the MMFS being over written, it does a simple test on the first address &8000 to see if writable, counting down from slot 13 (the first two are always occupied). Looks like I'll have to be more intelligent and maybe check for the presence of a copyright string even if it is RAM.

[Ramtop]

The accelerator is just a prototype, there are only two in existence at the moment. Currently sideways ram is still accessed at 2MHz, which I suspect is responsible for the less than expected performance increase.

From what you say, MMFS getting overwritten is definitely the problem. The ElkSD64 uses the 'Z' version of MMFS, which is stored in ROM and then copies itself into the first available sideways RAM slot on cold boot. The quick fix is to count from bank 0 upwards when checking for swram.

[Rocketeer]

The accelerator is just a prototype, there are only two in existence at the moment. Currently sideways ram is still accessed at 2MHz, which I suspect is responsible for the less than expected performance increase.

From what you say, MMFS getting overwritten is definitely the problem. The ElkSD64 uses the 'Z' version of MMFS, which is stored in ROM and then copies itself into the first available sideways RAM slot on cold boot. The quick fix is to count from bank 0 upwards when checking for swram.

I tried to put as much time-critical code into sideways RAM to get the speed boost for that very reason which explains your less than expected performance.

I've coded a check for the copyright string to avoid over writing swr being used the way you said and I'll release it in a few weeks - just need to see if any other bugs appear before then.

[JohnH]

FYI Having checked the MAME version I can confirm that left forward and right reverse together does rotate you faster than either on its own. A good strategy if a tank is going to get you in its sights before you can turn towards it, is to drive forwards and slightly to the left/right of the enemy and just go a little bit beyond it. Aim to pass it fairly close by. Your speed when close up is faster than it can turn. Then reverse in a J (or reverse J) direction passed the front of the tank and then quickly turn left/right and you should get it in your sights before it can turn and get you lined up for a blasting. Works on normal tanks, can't recall what you do with supertanks, probably the same only with more skill, lol. The missiles are best dealt with in reverse to give the effect of slowing them down and then fire at the last instant as they turn and come at you head on (from memory at least anyway).

I loved Battlezone and all the other vector arcade games better than the scrollers etc. and that's where the majority of my pocket money went.

[Rocketeer]

FYI Having checked the MAME version I can confirm that left forward and right reverse together does rotate you faster than either on its own.

You're absolutely right, I must be getting old as I checked the revision 2 code last night and it does exactly as you say - there are two rotations applied when opposite tracks are used. Have no idea why I persisted with there was only one rotation. Thanks for your post on this - the next release will have this and a few other bug fixes in.

[tricky]

Where not consider slots 14 and 15 for swram?
What are you going to do when all swram has C in it?
How are you checking for swram and which add-ons do you support?

[Rocketeer]

Where not consider slots 14 and 15 for swram?
What are you going to do when all swram has C in it?
How are you checking for swram and which add-ons do you support?

15 is Basic & 14 usually contains DNFS/DFS. At the moment the first bank of ram it finds it uses, but I've changed that now to check the ram for "(C)" to see if it holds a ROM image and move to the next if it does. If all are occupied it will give an error saying no SWR available on this machine.

Which add-ons you have in mind?