Missile Command arcade -> A8

[Rybags]

I've spent a few days looking at the game program code (disassembly from IDA Pro) and MAME driver for this game. The MAME driver (C program) is useful in that it provides rough documentation for the hardware used within the machine.

 

The hope was to be able to take the arcade Rom, put a bit of an emulation wrapper around it and have it run on the computer - both on standard hardware and VBXE.

 

But... some problems. Looks like there's practically no way the game would work on a standard machine without extensive reworking, and it's likely the reworking would make it too slow anyway.

 

A few things about the arcade game:

- it uses 256x231 resolution. The horizontal res is somewhat incompatible with Antic modes, it's 4-colour for most of the screen, 8-colour for the bottom 32 pixels. The solution I had in mind was use Antic E with scrolling and pan the view when the cursor gets near the edges of the screen.

With VBXE it wouldn't be so much a problem, it can do 256 pixels in narrow mode although the aspect ratio of the game would be somewhat screwed up, it'd be near 1:1 where the arcade pixels are about 4:3.

 

- the video RAM uses a weird access/addressing scheme. At first glance it seems ridiculous but the way it works allows accessing pixels on byte boundaries rather than having to do shifts/masks etc. This allows the code to run faster when doing pixel access operations.

The system board uses 1-bit RAMs, so there is little/no wastage. The accesses are only redirected when a CPU instruction with lower 5 bits=00001 is active. Such instructions are the (ind,X) ones - this allows the system to use this addressing scheme for the video Ram with almost 60,000 unique addresses but still allow the system to have a "normal" type memory map where the normal RAM, 12K ROM and IO devices can reside and not resort to any bankswitching tricks.

 

- it uses a single Pokey at 1.25 MHz and 6502 at ~ 1 MHz. The lower Pokey speed would mean frequency translation or reworking parts of the code would be required (shouldn't be too much work). The lower 6502 speed means the computer has some nice spare cycles to do emulation layer stuff and hopefully still be able to maintain the same pace as the arcade.

 

- trackball. There are a couple of hardware registers that maintain 4-bit X/Y for the trackball, simulating this should be possible, this is where the extra spare cycles come in handy.

 

- Interrupts. The game appears to generate IRQs at VSync and periodically during the display (every 64th scanline) - I suspect the scanline IRQs are mainly for reading the trackball position.

 

I'm thinking this game could probably be made to run under VBXE without too much effort. There are about 30 (ind,X) graphics access instructions in the game although there might be normal access to the video RAM as well (quite possible things like the explosions are done by normal writes to the video RAM).

[Heaven/TQA]

so basicly even "simple" games use unique hardware setup? why did they not had internally a "Atari board"? or where do such "strange" designs come from? or are we used to this "computer layouts" since the 80s?

[Rybags]

I'm not sure the arcade version even uses a video chip as we know it, generation is probably all by discreet logic.

 

There was a move later by Atari, e.g. System 1, System 2 boards with integration and commonality.

 

For these earlier games, it did make some sense that the board only contains what the game needs. One example here seems to be the video memory - most of it dedicates 2 bits/pixel but the lower part of the screen has 3 bits/pixel probably for stuff like the cities and status displays.

 

It could be a challeging conversion - the graphics accesses that I did find could be replaced by blits easily enough but I suspect it might be the tip of the iceberg. Blits might help out in other areas, it's hard to say. It'd be an interesting project.

MAME only helps out so much - the debug features are more aimed at devloping cheats, not really so much for the deeper workings of the games.

[Rybags]

C code driver for MAME can be found here http://www.mamedev.org/source/src/mame/drivers/missile.c.html

 

Provides some useful information, much in the initial comments.

 

Dis1.txt

 

Here's the disassembly I generated. The game code is from $5000-$7FFF. System vectors for NMI/RESET/IRQ @ $7FFA. I left the Ram segment in there, it's somewhat big but provides reference of locations that are directly accessed.

[Wrathchild]

would be interesting to see if any of the code correlates with the actual version done on the A8

[kiwilove]

I don't know too much about coin-op history - except that I take it that arcade games were custom built for that particular game - that there was no standard until the JAMMA board came along? Which allowed coin-op businesses to swap pcb's to change games - instead of having to buy a completely new coin-op altogether.

 

I do question what you are trying to do - with the hardware being totally different. A better fit - use of the target hardware, is to use that hardware to it's advantage - and write games that use it's strengths. Let it do what it can do....

 

The question is always - can someone come up with ideas that haven't been used before in this (a new) combination? There are always ways to display graphics that appears "fresh" and different. Like how the Simpsons style was drawn in - the original drawings were rather crude and rough, but then they were tidied up a bit, to what it is today (or should I say for decades...).

Wire frame like graphics could be used again or other simple styled graphics that can run perfectly fine on this old A8 hardware.

 

Harvey