Tempest Programming/Multigame

Just a little update on the Tempest Multigame/programming front.

The Tempest Multigame is now up and running 100% with a software menu
system. :-) I'm going to go out for another couple prototype boards
tomorrow to double-check the "production" layout, and then I'll order
production boards the week after that. Probably a 2-3 week lead for
those, a week for me to get the production run going, so about 4-5 weeks
 from now I should be shipping.

I'm going to do a $75 pre-order special for Vectorlist. After that
first batch the price will bump up to $99 for the duration. I'll post
details in a bit...

I'll try to get some pictures taken tonight. The installation is pretty
simple-- remove program EPROMs (if you want-- saves power), remove CPU,
remove graphics EPROMs. Plug CPU into Daughtercard and Daughtercard
into CPU socket on main board. Plug smaller daughtercard into graphics
EPROM socket. Solder one end of one wire to 6MHz test pin. Solder two
more wires to two pins on a 74LS139 on the main board. That's it. If
you want to be able to press P1 Start and P2 Start simultaneously to
call the menu there are three more wires to solder. (Or you can add a
"menu" button.)

Anyway, a couple tidbits for using MAME when writing software for old
AVG hardware (like Tempest):

1) MAME watchdog timing (in Tempest anyway) is worthless. Don't even
think it's accurate.

2) MAME doesn't understand bus contention between the Vector Generator
and the CPU. Be careful they don't
hit it at the same time or you die on real hardware.

3) MAME doesn't understand timing between color RAM and the Vector
Generator. This isn't fatal, but you can make effects that MAME can't
reproduce-- writing to color RAM while the VG is running. (I think
Vortex does this for the title screen that really freaks out MAME.)

4) MAME doesn't seem to understand timing of the VG being busy. At
least not how my code works (trigging VGGO from inside an ISR)-- I had
all sorts of weird timing problems on the real hardware until I added
explicit checks for the VG being busy.

5) MAME doesn't model the POKEY I/O interface right. MAME has the
input values always available on the POKEY I/O port, but a real POKEY
requires a write to the "POT GO" address to get the new values from the
input pins. (THAT took a while to figure out.)

That's about it for now...

-Clay
Received on Mon Apr 19 14:24:45 1999