Atari 7800 gets its first BBC Micro game

[GroovyBee]

I've adapted a game directly from the executable file that runs on the BBC Micro home computer (the Beeb to us Brits) to run from ROM on the Atari 7800. Its a bit buggy but its mostly there. See :-

http://www.atariage.com/forums/topic...-port-is-here/

Its a wire frame game so that's a big to all the nay-sayers that said the 7800 couldn't do that type of game .

There are no screen shots at the moment because the game does not run correctly in the ProSystem 1.3e emulator (I haven't tried MESS). You need to run it on a real PAL or NTSC system using a CC2.

[GroovyBee]

A teaser screenshot. I've updated the #1 post on the AA thread too.

[Greg2600]

Neat game. Works on MESS, but has no sound, and seems to go to game over quickly.

[slapdash]

Ha ha, that's neat. Are the BBC Micro and 7800 that similar architecturally?

[Steve W]

I thought the Beeb was based on a Z80 processor?

If you really want to impress people, port Elite to the 7800! Or Mercenary.

[GroovyBee]

Neat game. Works on MESS, but has no sound, and seems to go to game over quickly.

Do you see the baddies in MESS? You don't get them in ProSystem 1.3e for some reason.

[GroovyBee]

Ha ha, that's neat. Are the BBC Micro and 7800 that similar architecturally?

Not really. They are similar in that they both have a 6502 and that is about it really. The Beeb has 32K of RAM compared to the 4K of the stock 7800. The Beeb's 6502 is also clocked at 2MHz compared to the 1.79MHz of the 7800. The video modes are quite different too.

[GroovyBee]

I thought the Beeb was based on a Z80 processor?

Nope! Its a 6502 at 2MHz.

If you really want to impress people, port Elite to the 7800! Or Mercenary.

You mean adapting a game between systems that only share a common CPU isn't impressive enough?

[Steve W]

Nope! Its a 6502 at 2MHz.

Yeah, I had to look up the BBC computer in my Retro Gamer Hardware Guide to refresh myself on it's stats. For some reason, I was thinking of the Amstrad.

You mean adapting a game between systems that only share a common CPU isn't impressive enough?

How difficult is it to port over 6502 code? I know that back in ye olden times a few shameful companies took their Atari 2600 games and ported the code over to the Atari 400/800 computers with basically no change in graphics (Fantastic Voyage, I'm waggling my finger at you!). I'd think that it would be easier to port Atari 2600 code since there's very little other non-processor hardware for the software to interact with, whereas home computers are far more technically complicated. How much work was the source code to port?

[Greg2600]

Do you see the baddies in MESS? You don't get them in ProSystem 1.3e for some reason.

How would I know what they looked like?

[GroovyBee]

How would I know what they looked like?

Have you seen screenshots of the arcade game Tempest in action? If not, I've updated the original thread over at AA with some pictures taken from my TV. If there aren't things moving around the walls of the "tube" and getting bigger as they come towards you then there are no baddies and its the same as ProSystem 1.3e.

[GroovyBee]

How difficult is it to port over 6502 code? I know that back in ye olden times a few shameful companies took their Atari 2600 games and ported the code over to the Atari 400/800 computers with basically no change in graphics (Fantastic Voyage, I'm waggling my finger at you!). I'd think that it would be easier to port Atari 2600 code since there's very little other non-processor hardware for the software to interact with, whereas home computers are far more technically complicated. How much work was the source code to port?

The 2600 generates its games on a display line per line as they electron beam travels down the screen. Basically its "chasing the beam". This requires what is known as a display kernel. Basically its a cycle exact piece of code that writes to TIA (video chip) registers at specific times to get the desired effects. All the game logic and AI would take place in the VBLANK time (the time when no display is active). It also has 128 bytes of RAM and that includes the stack! To convert a game from the 2600 would require the display kernel to be rewritten.

There was no source code for the Tempest adaptation. The starting point was a binary that was loaded into a specific RAM address on the BBC Micro. The first task was to disassemble the code. Then look for things that won't work in a ROM image like self modifying code and copying code sections around (basically you are looking for writes to RAM that effect CPU execution sequences). The code was run on a Beeb emulator until it had performed its initialisation and started the main game loop. At that point the RAM dumped and another pass of reverse engineering. At that stage you are looking for variables that are written to, tables that are used, programmer tricks, self modifying code, OS calls etc. When you are happy that you've found all the tables you should be able to insert a simple instruction, rebuild for the BBC and the image should still run. If it doesn't keep going round this loop until it does.

At that point you are ready to adapt the game. The Beeb has 32K of RAM an OS and game's are loaded in from tape/disk. Whilst the 7800 has 4K of RAM, no OS and games execute from cartridge. You find workarounds for the self modifying code, hunt out all the variables that can reside in RAM and find out what the "magic writes" to the Beeb OS RAM locations are doing Then you have to replace OS calls with equivalent functionality as well as handle the different video display bitmap formats and how to turn keyboard input into suitable joystick movements for menu navigation and the like. When you've done all that the game is pretty much ready for testing on the console. Then you keep going around the adaptation loop until the game is running how it should be.

[Aswald]

I've adapted a game directly from the executable file that runs on the BBC Micro home computer (the Beeb to us Brits) to run from ROM on the Atari 7800. Its a bit buggy but its mostly there. See :-

http://www.atariage.com/forums/topic...-port-is-here/

Its a wire frame game so that's a big to all the nay-sayers that said the 7800 couldn't do that type of game .

There are no screen shots at the moment because the game does not run correctly in the ProSystem 1.3e emulator (I haven't tried MESS). You need to run it on a real PAL or NTSC system using a CC2.

Who thought the 7800 couldn't? Both the CV and 5200 could do respectable-looking games like that, so why not the 7800?

[GroovyBee]

Who thought the 7800 couldn't? Both the CV and 5200 could do respectable-looking games like that, so why not the 7800?

Unlike the other two machines the 7800 does not have full screen video RAM on the motherboard. It has two video line RAMs. One is displayed while the other is filled using DMA. It is best known for its ability to push sprites onto the screen e.g. Robotron 2084. To create arbitrary lines on a display you need RAM (or you need to make lots of compromises). With only 4K of RAM in total on the stock 7800 its not possible to have a video bitmap display without having some RAM on cart. Atari did not want RAM in carts back in the day due to the extra cost.

[GroovyBee]

A fix for the ProSystem emulator is explained in this post here. You'll also need v1.02 of the game to match the MD5 checksum given.

I've also tried the game in MESS but it plays too quickly.

[Aswald]

*****************
Unlike the other two machines the 7800 does not have full screen video RAM on the motherboard. It has two video line RAMs. One is displayed while the other is filled using DMA.
*****************


What does that mean? Keep in mind that my programming experience is with Commodore computers.

[slapdash]

He means that you can't define an entire screen of graphics and only move the sprites around that need to move; you have to redraw everything one line at a time. On the 2600 it was REALLY only one line at a time, but on the 7800 (I gather from his post), you could at least start filling the next line while the first line was being output, which would mean that timing isn't quite as critical, I would think.

[GroovyBee]

Lets say on the C64 you have a screen of 160 pixels wide by 200 pixels high. For each vertical line there is a section of RAM that contains the data for 160 pixels. If you know the based address of the RAM you can write data into it and the pixel colours will change. You can think of the C64 display as being like a bitmap in an art package. You can draw anywhere on the bitmap and the pixels stay like that until you change them.

On the stock 7800 its nothing like that. Everything is a sprite. Lets say you have a screen of 160x192 on the 7800. The 192 vertical pixels need to be divided into zones of between 1 and 16 pixels high. If we choose the zone height to be 16 pixels there will be 12 zones (the zone height is the height of the sprites). Each zone has a Display List (DL) associated with it. The DL tells MARIA (the 7800 video chip) how to construct the pixel data for the zone. Each DL entry contains a source data pointer (where the sprite data will come from), a length to copy, an X offset (to go on screen) and other control information. The DL is read from left to right which controls how sprites are overlaid on top of each other. For example the DL entries for background would be at the front of the list, enemies, player and bullets next and so on. While MARIA is reading data the 6502 is halted because it needs access to the RAM and ROM. MARIA fills its internal video line RAM based on the contents of the DLs it is supplied with. You give MARIA a pointer to a Display List List (DLL). The DLL has an entry for each zone. Each entry has a pointer to its DL and some control information. As MARIA works its way through the DLL and each DL in turn the display is created.

In the BBC Micro adaptation I did it needs a bitmap display like the C64. To achieve it some RAM on cartridge is required. The source data in each zone's DL entry points to the RAM. The game writes to the RAM and MARIA just "thinks" its a large sprite block.

[Aswald]

To completely fill a C-64 screen would take 8K. This was because you had 25(V)x40(H) character spaces; each had 8 lines (horizontal) of 8 pixels.

So, to fill a space took 8 numbers from 0-255. A Byte. Since there were 1000 such spaces, that would take 8000 Bytes. About 8K (I know a "K" was actually 1024 Bytes).


Of course, this assumes that you want to create a screen without repetition. Because of memory limitations, obviously many such screens were out of the question. This is why custom characters and repetition were common, or large blank areas. To get an Arkanoid background, I simply used 4 custom characters 1,2/3,4 to form a block; thus, only 32 numbers were needed. Even in BASIC, a change would be quick.

Naturally, none of this takes color codes into account. If you wanted to give each space its own, that was 1000 numbers, or 1K. So figure 9K/screen of RAM, unless you used a formula of some kind.

Multi-colored mode did not cut memory requirements in half, even if horizontal resolution was. This was because a single dot of color was actually 2 combined: 00, 01, 10, or 11. Background ("nuthin'"), 2 shared, and one independent/space.


What you are saying is that EVERYTHING with a 7800 is a sprite- there is no true background. Thus, what you are really doing is filling the screen with sprites, some of which are for background or playfield.

And you can't just leave anything alone if there's any action- it's almost as if, with a C-64, a weird malfunction keeps erasing everything so you have to keep redrawing it.

So in Xevious, Tower Toppler, and Ms. Pac-Man- anything with extensive background- is going to take a lot of effort on the part of the 7800 to maintain. This must have sapped a tremendous amount of power from the 7800 for any such game, meaning that its advantages over the CV and 5200 were not as great as was believed back in 1984.

In other words, for games like Asteroids, Space Duel- any game with simple or blank backgrounds with great amounts of on-screen motion- the 7800 was hard to beat, even by 16-Bit systems, but with games with any kind of background it lost much of its advantage.

[tom]

Shouldn't that be...way back the BBC got an Atari game, now it's given back to its rightful platform.