Atari 2600 FPGA update / Video Pinball flipper velocity

[ehenciak]

Hi all,

 

I've been working on porting the Atari 2600 to an FPGA. I am up and running on real hardware now and people at work are falling head over heels playing with the system (Pitfall's on right now) . I will have a webpage up very soon showing this thing off. School and work are pushing me pretty hard right now, but I've had it running (buggy) for a few weeks now and just recently got it 99% rock solid.

 

The current bug I've run into bothers me....it seems like Video Pinball's ball to flipper collision and resulting velocity is goofed up (direction seems fine). For example, when I hit the ball with a flipper, the ball tends to slow down somewhat instead of speed up! If the ball itself is too slow, when it hits the flipper, it almost comes to a stop then drains. It really doesn't look like a TIA issue...collision detection appears to be working just fine and every other object on the screen bats the ball around as it should. With the resulting direction working, something is telling me that it is related to the resulting velocity calculation!

 

I'm thinking this might be a software issue...now in the case of the FPGA, this would be a problem in the CPU core ! I guess my question is geared more towards those who developed emulators for the 2600 and may have run into a similar problem assuming they know the innards of Video Pinball...How does video pinball calculate the resulting vector for the ball (i.e. velocity and direction)? Do they use BCD arithmetic or binary math...signed or unsigned. I am going to dissect this myself eventually, but I want to find out if someone already did this before spending a few evenings tearing it apart.

 

Oh, and as usual, this design will be open sourced for everyone to look at and use (in non-commercial applications, but I am VERY VERY VERY flexible if you'd want to sell something based on this...$1 million dollars should be enough (just kidding) ).

 

For those interested, I plan on releasing the core in July once it's all debugged and working 100% with all bankswitching capabilities (and a few other goodies). Moreover, a "reconfigurable retroconsole in a cartridge" is in the works....I think you're going to like the looks of it ! I have samples of the case on the way!

 

Ed

[Bruce Tomlin]

I seem to recall reading that Video Pinball is one of the tougher emulation challenges. I don't know why, but I think it has to do with getting the collision registers right, possibly on a cycle-accurate basis.

[vdub_bobby]

I seem to recall reading that Video Pinball is one of the tougher emulation challenges.  I don't know why, but I think it has to do with getting the collision registers right, possibly on a cycle-accurate basis.

I seem to remember reading somewhere...on [stella] maybe...

 

Doesn't Video Pinball do some goofy stuff, like try to read from the write-only TIA registers? And then depend on the values it gets back?

[vdub_bobby]

In fact, a little digging showed my memory is somewhat accurate:

 

here are a couple of [stella] posts on the subject:

http://www.biglist.com/lists/stella/archiv...0/msg00204.html

http://www.biglist.com/lists/stella/archiv...7/msg00045.html

 

And a quote or two:

All the TIA graphics and sound registers are indeed write-only.  When you

read from anything in the TIA address space (which is $0 through $7F and

any mirrors thereof when lines A7 and A12 are low), you get its read-only

registers, which are the collision registers from $0 to $7, the four

paddle potentiometer inputs from $8 to $B, and the joystick buttons at $C

and $D.  Reading from $F is undefined as far as I know.

 

Your guess was correct, I believe.  With undefined situations like this in

the 2600, almost always the value read will be whatever value was on the

bus on the previous cycle.  I remember Video Pinball relies on that for

some operations involving collision detection, which was why that took so

long to emulate properly.  Looks like this may be a similar case.

 

>Does this happens too with read addresses like INPT4? If I do LDA INPT4,

>will

>accum bits 6 to 0 contain the last bus value?

 

Yes.  In fact, that is actually the detail that Video Pinball relies on

and needs in an emulator, which took everyone a good long while to figure

out.

From a post by Erik Mooney.

 

It seems like I found something a little more explanatory in the archives at some point, but I can't find it right now.

 

But there ya go; that oughtta get you going in the right direction.

[Eckhard Stolberg]

It's a problem with the data bus. All TIA read registers will only drive the two topmost bits. The six lower bits will be left floating. Therefore they will read whatever data was on the data bus last. Usually the TIA collision registers are read with zeropage addressing mode, so the last data on the bus usually is the low byte of the address of the TIA read registers.

 

Video Pinball relies on the state of the lower bits when it compares the collision values. That's why collision detection with the paddles will fail, if your hardware always sets these bits to zero. That indeed did take us some to time to figure out and emulate correctly in z26.

 

Accessing the secret kingdom in Mountain King also depends on the state of the lower bits in the collision registers. This game (accidently) interprets data from the TIA read registers as pointers for the level data. If the lower bits in the read registers are set to zero, the level data for the secret kingdom is created in such a way that there always will be some platforms in the way when you try to jump to the entry point of the secret kingdom. Therefore you won't be able to access it.

 

 

Ciao, Eckhard Stolberg

[ehenciak]

You all rule....thank you! You saved me a few hours of tearing through the game.

 

When I read TIA, I only drive the databus with what I thought were the only "necessary" bits. Everything else is forced to zero by default. Tonight that will be no longer.

 

I promise pictures and video are forthcomming....I was amazed at the response I got at work with this thing...in a lab right next door to my cube, we have all of this mega-fast networking equipment we design....however, everyone's huddled around my cube looking at a 30 year old game system ....one of them stated that it was the coolest thing he'd ever seen in an FPGA ... you gotta love Atari ! And I only had Pitfall, Frogger, and Video Pinball to show off (someone suggested to look for a problem with random numbers ).

 

Wait until you see how absolutely crystal-clear TIA video can be! I'm debating on adding a VGA connector to a small TIA replacement daughtercard I hope to make. It's part of my silly plan to make a "super TIA". It'd be fully backwards compatible with TIA, but I plan on adding a mode where TIA is effectively doubled (except for audio). TIA only requires roughly 700 Altera logic elements (I'll be moving to Xilinx shortly) and I know I can reduce that count by roughly 75 once I start "seriously" cleaning the design up. You could easily gang two TIAs together and only the priority encoding and collision detection change ! PAL support wil be fine since I can dump all the color encoding tables into embedded memory.

 

For the final TIA replacement, I'll be moving to an Actel or Atmel device due to cost, the nice instant-on feature, and 5V tolerance w/o the need for external components.

 

Ed

[Eckhard Stolberg]

When I read TIA, I only drive the databus with what I thought were the only "necessary" bits.  Everything else is forced to zero by default.  Tonight that will be no longer.

That's good. But please note that all TIA read registers always drive the two topmost bits, even if only one of them has a meaning. So for the TIA part of the controller inputs (INPT0 - INPT5) for example only bit 7 is used, and bit 6 will always be pulled to zero.

 

 

Ciao, Eckhard Stolberg

[ehenciak]

 

That's good. But please note that all TIA read registers always drive the two topmost bits, even if only one of them has a meaning. So for the TIA part of the controller inputs (INPT0 - INPT5) for example only bit 7 is used, and bit 6 will always be pulled to zero.  

 

 

I see this on the schematics....I should have been a little more clear.

 

Ed

[ehenciak]

This solved the problem for Video Pinball!!!! Thanks!!! Now to clean up Cosmic Ark...it's definately playable as is, but I want it perfect !

 

I'll also have to give Bruce's Red Box / Blue Box a whirl.

 

GI Joe looks great....this is all a dream come true !

 

Also, wait until you see the cases I found for "Retrovision 1" ! It looks like I'll be able to make a good looking, quality FPGA development system for no more than $100USD...and I'm still fighting to lower the price ... stay tuned !

 

Ed

[+batari]

Sorry if this is a little off topic, or if it's been answered before...but does your FPGA handle illegal 6502 opcodes? Many, if not most modern homebrews rely on these. For example, in my latest game I found practical uses for DCP, LAX, ISB, ARR, SBX, and SAX.

[ehenciak]

Right now, it does not support illegal opcodes....however, I want to get the Opencores 6502 100% perfect . I just want to get TIA perfect at first so that it makes debugging the 6502 much, much, much easier (1 unknown vs. two).

 

Moreover, even if there is an obscure problem, upgrades will be a snap since it's an FPGA ! However, I'd expect more bugs with the GUI I am making at first ! My software skills are pretty rusty !

 

Ed