Atari Battlezone

[tricky]

I support all that I know of in my games.
I usually put 32k ram in slot 15 with the second half in slot 11 in my show machines.
The early Solidisk are the biggest pain as checking for them will cause the usual mmc devices to fail their next request.
My beeb from 82 has a solidisk expansion, otherwise I might not have bothered with it.
I assume that you only put read only code and data into swram.
The Watford 12 rom ram board is a bit of a pain too as you can only write to the ram from a ROM on the board, which does usually include basic and/or a DFS.

[Ramtop]

I managed to squeeze the logic for a single bank of sideways ram into my accelerator. This is what performance looks like now:

https://www.youtube.com/watch?v=WMlwXBx7l3A

I lost a fair bit of time today playing the game, it's still as much fun as ever. Everything is running at 4MHz, except screen writes. The CPU unfortunately isn't stable at 4.6MHz with the Plus1 fitted and I needed to use that to make sure the fast sideways bank appeared higher than the slow ones.

[Rocketeer]

I managed to squeeze the logic for a single bank of sideways ram into my accelerator. This is what performance looks like now:

https://www.youtube.com/watch?v=WMlwXBx7l3A

I lost a fair bit of time today playing the game, it's still as much fun as ever. Everything is running at 4MHz, except screen writes. The CPU unfortunately isn't stable at 4.6MHz with the Plus1 fitted and I needed to use that to make sure the fast sideways bank appeared higher than the slow ones.

The performance looks excellent on the video, looks faster than a BBC. Well done!

[Rocketeer]

I support all that I know of in my games.
I usually put 32k ram in slot 15 with the second half in slot 11 in my show machines.
The early Solidisk are the biggest pain as checking for them will cause the usual mmc devices to fail their next request.
My beeb from 82 has a solidisk expansion, otherwise I might not have bothered with it.
I assume that you only put read only code and data into swram.
The Watford 12 rom ram board is a bit of a pain too as you can only write to the ram from a ROM on the board, which does usually include basic and/or a DFS.

I'm just using emulators at the moment although I do have an Electron/BBC/Master but they need setting up correctly and thats going to happen on Sunday when my friend Mark West is coming round to do so.

[hoglet]

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.

I just tried this, and got somewhat further, and was even able to play a game.

This was on a Master with a recent version of MMFS 1.52, using Co Pro 15.

Dave

[OneSwitch]

Superb. As a long time BattleZone fan, there's definitely a problem with rotating on the spot in game-play. Turning should be faster when pushing up one-side and back the opposite side at the same time, than just pushing up or down on one side only.

And keys wise don't feel logical to me. I'd go for typists resting position for the middle fingers....

E = LEFT-TRACK FORWARD I = RIGHT-TRACK FORWARD
D = LEFT-TRACK BACKWARD K = RIGHT-TRACK BACK
SPACE = FIRE

Maybe that doesn't feel right on a real machine though.

And for everyone used to MAME, 5 (or 3) for insert coins, and 1 (for player 1 button) to start.

Love all the extra bits allowing you to play with the game assets. Much like I,Robot's Doodle City in some ways.

Cracking job anyway.

[Sazhen86]

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.

It seems to work OK with the port of the ARM7TDMI code from BeebEm that is in the development version of b-em on GitHub. I guess it relies on the ARM co-pro being fast enough to keep the TUBE FIFO full rather than checking the data ready bit as it requires the tube speed to be set to 800% to work correctly.

[strawberrytau]

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.

I just tried this, and got somewhat further, and was even able to play a game.

This was on a Master with a recent version of MMFS 1.52, using Co Pro 15.

Dave

Great! It must be some other incompatibility in my system. I’ve got quite a few ROMs and VideoNULA on my Model B so it is probably one of those. Strangely it works fine for me when the copro is switched off. Can you think of any incompatibility that turning on the copro could trigger?

[hoglet]

It must be some other incompatibility in my system. I’ve got quite a few ROMs and VideoNULA on my Model B so it is probably one of those. Strangely it works fine for me when the copro is switched off. Can you think of any incompatibility that turning on the copro could trigger?

It's kind of hard to answer this without seeing a list of everything thats on your system.

I tested on a Master, I'll try a Model B later.

What version of PiTubeDirect and MMFS are you using?

Dave

[Sazhen86]

Another couple of data points.

I tried it on a Master with co-pro 15 and it worked fine. I also tried it with an ARM 7 TDMI co-processor on the Master and it failed. I suspect that the co-pro isn't fast enough to keep up. It does work in BeebEm and b-em with an emulated ARM7 TDMI providing it's set to run fast enough. Or it could use an instruction that's emulated but not present in the real CPU.

I tried it on a model B where it works with no co-pro, although I had to edit bzone0 to start looking for sideways RAM in slot 14 which is where mine is located.

I then tried it with both a Pi co-pro 15 and the ARM7 TDMI on the model B and it failed to start in both cases. It didn't get as far as showing the Atari logo and not much disk access was done. I suspect it had got to the part where it loads the ARM code into the co-pro and jumps to &406 to execute the code on the ARM. I haven't looked much further than that though.

[KenLowe]

Might be worth having a look at this code for detecting different types of free SWR banks:

http://wouter.bbcmicro.net/bbc/software-whs.html

This is what SteveF uses with Ozmoo:

viewtopic.php?p=311893#p311893

[tricky]

And mine viewtopic.php?p=386979#p386979 (was also posted to the LadyBug thread).

PS I think mine tests the most types and is the smallest code, but I could be wrong!

[Sazhen86]

Another couple of data points.

I tried it on a Master with co-pro 15 and it worked fine. I also tried it with an ARM 7 TDMI co-processor on the Master and it failed. I suspect that the co-pro isn't fast enough to keep up. It does work in BeebEm and b-em with an emulated ARM7 TDMI providing it's set to run fast enough. Or it could use an instruction that's emulated but not present in the real CPU.

I tried it on a model B where it works with no co-pro, although I had to edit bzone0 to start looking for sideways RAM in slot 14 which is where mine is located.

I then tried it with both a Pi co-pro 15 and the ARM7 TDMI on the model B and it failed to start in both cases. It didn't get as far as showing the Atari logo and not much disk access was done. I suspect it had got to the part where it loads the ARM code into the co-pro and jumps to &406 to execute the code on the ARM. I haven't looked much further than that though.

Well, that'll teach me for doing things too late at night. I bozo'd the load address for bzone0 when I changed the SWRAM check and missed off the host processor address prefix. Having fixed that, I can say that it load and runs OK on my model B with Pi co-pro 15.

[mike12f]

I've downloaded the latest version and the sound is working much better now on beebjit.

[Rocketeer]

I've downloaded the latest version and the sound is working much better now on beebjit.

Thanks for the feedback, much appreciated.