DVG Multigame

I've got a bug up my butt for wanting to do a hardware modification
project that involves video games with emulation assisting in the process.
Staring at my Asteroids machine (with an Asteroids Deluxe board
installed), I thought "Hey! How about Asteroids/Asteroids Deluxe/Lunar
Lander" in my Asteroids cabinet? After studying the schematics to
Asteroids, Asteroids Deluxe, and Lunar Lander, it looks like such a
project is possible!

I'm soliciting input from others as to my approach, so I'll just start
rambling. I'm no hardware expert, so if you see a flaw in my approach (or
a better way to do it), please let me know!

Start with an Asteroids Deluxe PCB. Using either of the other PCBs would
render AD to be mostly silent. The other sound effects that Lunar Lander
and Asteroids have that are generated with discrete circuitry can be
generated (at least closely approximated) by the Pokey.

The game ROM region is from 6000h-7fffh across all games (with the
exception of Asteroids being 6800h-7fffh). Both Asteroids Deluxe and Lunar
Lander use up the entire region which renders code modification or
bankswitching within that region to not be possible. Also, it has more RAM
than Lunar Lander does (1K as opposed to 512 bytes), and I don't wanna add
RAM chips. ;-)

I'm planning on mapping an EPROM from the 8000h-ffffh range. Atari was
gracious enough to provide us with a way to make the board decode all 64K
(it's a pad jumper on the baseboard for A15).

The next step will be to disassemble each of the games and get them to a
point where modification and reassembly will generate the same image.

Use a 27256 or something equivalent (32KBytes). Asteroids Delxue and Lunar
Lander both use 8K of ROM. Asteroids uses 6K. That's 22K, giving us an
additional 10K to put in a quick front end or perhaps even another game.
We will also need to put in some sort of NMI/INT "steerer" logic to make
sure the game code gets the INTs/NMIs.

In the process of relocation, we'd need to disassemble the game code and
make it reassemblable. We'll also have to go through each game and move
some memory locations around (and bits of code, too) for controllers,
sound effects, and LEDs. Anyone know of a *GOOD* 6502 cross assembler -
one that allows longer than 8 character label names and can assemble
fairly good sized files? I have a disassembler that will do depth
traversal and label assignments. I've already done this for Asteroids -
it's completely relocatable and modifiable now. Just need to do it for the
others, too. ;-)

The controllers are the same for Asteroids/Deluxe but for Lunar Lander
we'll have to do a pseudo DAC for the thrust handle - in software, of
course. The other provisio for Lunar Lander is we'll have to put in some
code to allow the user to select which mission they want to go on (for
those without the benefit of the marquee). Visual feedback instead of
blinking lights (which the Asteroids/Asteroids Deluxe cabinets lack).

And if someone is insane enough to want to make hardware to interface to a
real thrust controller, the code would be easily modifiable and moveable!

We'll also need an ability to bankswitch the vector ROM depending upon
what game is being played. The vector ROM is located from 4800-5fffh
across all games, which is effectively 4000h-5fffh (with the bottom 7ffh
bytes unused because it's vector RAM), or another 27256 with some swizzle
logic to keep the chip enable out of the 4000-47ffh range.

Hardware-wise, we need a PAL (or something equivalent) to do the
following:

* Invert A15 to the new EPROMs output enable
* Have any write to the 8000-ffff region go to an 8 bit latch. The bottom
  two bits to go the upper address lines on the vector EPROM (27256) to
  select which bank of 8K the vector generator should use.
* Exclusive OR the PROM/VRAM output select (one half of L2) on the vector
  generator, and have it drive !OE on the vector EPROM (27256).

I don't think there are any other things we need to modify on the board
itself. Did I miss anything? Obviously there are mappings of dip switches
and other inputs that are different from platform to platform, but we can
handle that in software.

The only thing I haven't figured out how to handle are the dip switches.
We've only got a few. Perhaps a SEEPROM or some other nonvolatile storage
device to store settings and render the dip switches themselves unused or
available for other purposes. Comments?

Some other random thoughts that we should think about:

* Elimination of all self-test code from the individual games. We write a
self-test procedure that's handled in the front end and eliminate the
rest. Saves code space.

* Should the front end cycle through the attract mode of all games?

* Should it allow the game to be played in an operating environment like
an arcade rather than just free play?

And yes, I intend on making the source code available to all who wish to
implement it. If I program up some PALs, I'll make the PAL info available
free as well.

Comments? Let the discussion begin!

-->Neil

-------------------------------------------------------------------------------
Neil Bradley Seti@Home Hall of Shame on a 80386DX16, Intel 80387
Synthcom Systems, Inc. 32MB RAM, Win 95 Status: 48.425% complete
ICQ # 29402898 CPU Time: 1721 Hours 14 minutes 53.4 sec

---------------------------------------------------------------------------
** To UNSUBSCRIBE from vectorlist, send a message with "UNSUBSCRIBE" in the
** message body to vectorlist-request@synthcom.com. Please direct other
** questions, comments, or problems to neil@synthcom.com.
Received on Thu Mar 9 22:27:59 2000