Fun with FPGAs - recreating the Atari TIA, Part 1

I have been playing with recreating the Atari TIA chip as used in the original 2600 in an FPGA.  I know this has been done a few times already, but I'm hoping to use this project as a warmup for bigger and better things. Furthermore, I'd like to be able to produce actual hardware replacements for the original chips.

For the TIA, there are original schematics available, as well as many notes and forum posts about all the details of its operation.  There are other FPGA cores as well.  You would think this kind of project is incredibly straightforward - just implement what's in the schematic using Verilog or VHDL, and everything will just work.  I'd like to explore two reasons why this is quite a bit harder than that.

1) Custom ICs back in the day were extremely limited.  Clock speeds were low.  The total number of transistors were extremely limited.  

For these reasons, and by today's standards, lots of "shortcuts" were taken.  Circuits would be clocked on rising and falling edges, to double the effective clock rate.  Elements would be chained together in complex ways, where one state transition would set off a cascade of downstream state changes, affected by propagation delays.  A single bit of state might be represented by a full D flip-flop, or in might be simply the output of one transistor which is "refreshed" with a new value on a regular basis.

Contrast this with modern FPGA design principles - namely "synchronous design".  Essentially, all state should be in the form of clocked flip flops, which are all clocked at the same time, and whose input states are a simple combination of the output states.  Since you can't really imitate the tricks used back in the day exactly, you generate logic circuits that do the same thing.  (The intermediate states should be the same as what you have in the original design.)  But, in order for clocking to be synchronous, sometimes you need to create additional signals that didn't exist in the original design.  For example - a clock pulse causes A, but under some additional circumstance A then causes B.  If the delay between A and B is not significant, surely you want A and B to happen at the same time in the new design. But, you probably need a new signal that tells you that A is going to happen _and_ it's the special circumstance, so that B can happen at the same time.

Since you can't count on delays in an FPGA, you end up reverse-engineering the behavior of the original design, and implementing the equivalent behavior, even if it's not exactly 1-to-1.

I don't do FPGA design much professionally. I'm not even exactly sure how much I can deviate from "good" FPGA design principles and get a reliable design. That's one thing I'd really like to learn from this experience.

2) Sometimes, maybe most of the time, there is analog on the original chip along with the digital.

For example, the paddle controllers on the 2600 use an analog discharge curve from 5V to set their timing.  A better example, Atari used an analog phase delay chain to generate the color palette.  These require new adaptations to work with a fully digital design.

On top of this, 5V logic is largely obsolete.  You need to examine how all the pins are being used in your system, and make sure there are compatible signals getting to/from your FPGA.

In the next blog post, I will discuss the first hurdle I faced. Setting up clocking so that I can generate all the signals needed by a fully digital version of the TIA.

Sega Space Tactics

Sega Space Tactics - One of those arcade games which most people have never heard of - but it brings back a feeling of nostalgia for me.

The day before the grand opening of my local Chuck E. Cheese's - sometime in the early 1980's - my brother and I got a chance to visit this new "pizza arcade" concept.  Arcade technicians were scurrying between shiny new cabinets, each with the coin door open, making sure they all worked fine for opening day.

The "Space Tactics" sit-down cabinet was big - the two of us could fit inside side by side.  It was sort of a "3D space invaders", with weird analog sounds, electro-mechanical controls, and a first-person space shooter perspective.  It was a remarkable day, but something about that particular immersive environment stuck with me, at least for a while.  It was like we were "flying our own starship," just for the day.  Eventually though, I forgot all about it.

The game didn't catch on.  Or maybe it was just too complicated, and prone to breakage.  In any case, as the 1980's went on it was fairly quickly replaced with newer, more conventional games.

Fast forward to the late 1990's. I am having a blast working as a new MAME developer, and looking through a list of unemulated titles.  In the days before "flyer archives"...something about the name "Space Tactics" jogs a memory.  I ask about it.  I'm told "It's electro-mechanical and very complicated - but the schematics are in the service manual posted here if you're really interested...".  I still can't remember the game, but I think "maybe if I start working on the emulation I will remember..."

It takes a special kind of masochist to emulate a beast like this one.  All the standard arcade hardware, plus worm gears, limit switches, encoder wheels.  I started writing code a little at a time...just the graphics...the text...the scrolling of the playfield...eventually adding the LED arrays as best I could remember - and a rudimentary score display.  I remember now!  I wish I could remember exactly how it looked, but at least the driver is playable now.

A trip to Cedar Point amusement park - sometime in near the turn of the century.  The have two actual Space Tactics games! One working, one not (probably for parts I think.)  I take a few pics, and wonder how much longer they will be there.

Space Tactics Gameplay

Mid 200x.  "eBay - L@@k - Sega Space Tactics game for $50 - local pickup only - in upstate New York".  I decide to rent a truck and drive with a friend to pickup the game, driving from the midwest. (This deserves it's own blog entry)  The game is complete, except for a coinbox door and a reinforcing rod to add rigidity to the seating area.

Inside Sega Space Tactics

It is amazingly complicated on the inside.  Pixels were expensive in 1981, so making an immersive experience was tricky.  Sega's solution?  Mount the monitor on a rotatable chassis with a movable mirror.  The playfield appears to slide up-down-left-right as you move the flight yoke.  Against this moving background provide stationary 'beams' of fixed LED's in the foreground, which light up in sequences when you fire.  Finally, add some fluorescent graphics, a black-light bulb, LED score indicators and lighted buttons, analog sound, and you've got something!

Now the sad interlude...It's fun and works, but I never get it completely setup where my kids and I can play it.  It stays in my garage.

2010ish.  Against my better judgement, I decide to get rid of Space Tactics because it is taking up too much room!

And the happy ending...

Last week - 2017.  A local collector is selling a Space Tactics...more than $50, but not too high...just as I'm buying a new house with a walkout basement.  A quick trip, and I have a nicer one than I had before!  Still missing a coinbox door but otherwise complete.  I haven't powered it up yet but I will follow up this post with a video.

Epilogue:

Current MAME gameplay

2017 MAME status - still work to do! - Others have added nicer rendering of the score display. Sound emulation is not complete, because of the analog stuff.  (No reason why it can't be completed now, though.)  Also, notice the laser beam rendering is still "angled up" and pixellated - unlike the real thing.  This is still the best I could remember when I first wrote the driver, and I used the low-resolution playfield rendering (which forces the pixellation) to add it.  It should be updated to use the proper MAME rendering subsystem (would look great) and aligned like the real game to be roughly horizontal.

Atari Starship 1

After a "short break"...I'm working on MAME again. :) After all the excitement about the discovery of an Easter Egg in Starship 1 earlier this year, I decided to take a look at some of the shortcomings of this driver.

The first issue relates to the way the spaceships explode.  In MAME 0.185, the ships "get brighter" and then disappear in MAME, but in the original game they appear to flip around as well.  Strangely, the wrong sprite is sometimes used when the flipping occurs, so a hack was placed in the driver to stop the flipping.  I honestly don't remember who added the hack - it might have been me :)  (Back in the day there were no handy Youtube videos of the actual gameplay available - like this great one from Arcade Jason)  In any case I removed this hack for MAME 0.186.

In the Easter Egg article, they mention the "Fast/Slow" throttle controller.  It looks like the kind of controller which should toggle, but apparently it actually goes back to Slow if you let go of it.  This is a trivial fix, and I have it in my github already.  See the original controller on the right here:

The next issue relates to the speed of the emulation.  The schematics for Starship 1 are buggy, and the video timing really doesn't make sense.  I used a combination of reference videos and photos of the PCB to conclude that the video timing circuit is very much the same as Atari Destroyer, and Super Breakout.  The Horizontal Line rate (rate to draw one scanline) is 15750Hz and the Frame rate is 60.114Hz, when using a crystal of 12.096Mhz. This also makes the game timings correct. (the game runs for a "certain time" instead of a certain number of lives).  This is fixed in my github as well.

Now, there are two issues left that I know of.  The planets that get created always originate "centered on the screen", which seems to make the MAME version much harder than the actual - I need to look into this, but I think it relates to the calibration procedure of the original game, which was required at setup time and is described in the manual.  This needs more analysis.

And finally - the scaling of the spaceship sprites.  Atari used a patented circuit involving analog circuitry to scale these images.  The patented circuit actually creates sprites which are "directly proportional" to the size that the game requests.  In other words, there is a simple scale factor to sort out.  Unfortunately, it's tough to sort it out definitively, without access to the real hardware, or building up a circuit yourself.  To make matters slightly worse, the real circuit used in the game is slightly simpler, which means there is a more complex relation between what the game commands and the actual size of the sprite on the screen.  I will most likely need to build the circuit and measure it at some point.  For now, the approximation in the code seems to work pretty well.

I created the first driver for Starship 1 way back when, and Stefan Jokisch updated it and submitted to MAME back in the early 2000's.  I put in the one fix for MAME 0.186 and at least the next two fixes should make it for 0.187.  This should be enough to close out the corresponding bug report on mametesters.  Aside from Starship 1, and I have a few more ambitious emulation projects...but I'll save them for the next update.

And so it begins...

..the Great Garage Cleanout of 2010 that is.

Well, I have to make room, so the arcade games are starting to go.  Gremlin "Comotion" and Midway "Extra Bases" were parted out today.  The dead husks are sitting out at the curb as I type.  I kept the PCB's and took some last photos which I'll add a little later.

These were both used to develop the MAME drivers.  I created "blockade.c" based on Comotion and some schematics from Al Kossow.  The Midway "Extra Bases" cocktail contained a Black and White monitor, which was interesting because the game at that time was in color in MAME.  It turns out that the game had a dip switch, which could either drive a Black and White monitor directly with the Luminance output, or in another configuration, drive the color conversion board and play the game in color.  This was sort of "unknown" or at least not well known at the time in the MAME circles.

Ironically, as I pulled the monitor out of the "Extra Bases", I noticed it had some burn-in from "Blockade", which is basically the same hardware as "Comotion".  (Obviously not the original monitor)

These two games were bought from two different places, but being of similar vintage I guess I shouldn't be surprised.

Vintage Gaming Party @ Penguicon

I am planning to have a hotel room party at Penguicon this year, bringing my old game consoles out of storage.  (Actually two parties, one on Friday and one on Saturday, if all goes well.) 

I started by testing out a Coleco "Telstar" Pong and the Atari 2600 yesterday.  You can see my team of playtesters trying out some "big-screen" Pong action here:

Here is just a taste of the excitement in store... :)  Next I'll be pulling out the Intellivision, Vectrex, and whatever else I can dig up.  If anyone has some smallish TV's (preferable analog!) they want to loan for the weekend, I could probably use them.

Perhaps I'll throw in some Apple II games, or some other system emulators. Moria/Angband?  Text Adventures?  Trek?  Am I crazy enough to bring in a full-sized arcade game?  The possibilities are endless, but the hotel room is not, unfortunately.  If only I had a TARDIS...

The Mathematics of Calendar Reform

The Gregorian Calendar is inconsistent, and there is only so much we can do about it. The earth takes about 365.24 days to go around the sun. The number of days in the year are nicely controlled with leap years and leap seconds, to make this work out.

We have a tradition of the 7-day week. We have a tradition of months which are 28 or 30 or 31 days long. But worst of all, each year starts on a different day of the week, forcing us all to have new calendars each year.

So, can we do better? Sure we can. Let's look at the numbers:

First, every number can be expressed as a series of primes multiplied together, called a "prime factorization".

365 = 5*73

Yuck. Well, if we want 5 seasons of 73 days each, we are all set. I don't think so :)

364 = 2*2*7*13

This has potential. We could have 7 day weeks, 4 weeks in a month, and 13 months. Plus one day every year which is outside the "days of the week". A kind of yearly holiday for the 365th day. And on leap years, we need one more day like this. Then, every year would have the same pattern. Indeed, these kinds of 13-month systems have been proposed, and even used occasionally. The most recent version is probably this one:

http://en.wikipedia.org/wiki/International_Fixed_Calendar

I admit they are probably the most elegant, but I think the world will not readily switch to 13-month calendars.

So, we have two other choices. Give up months altogether, and go with 7*13 = 91 day quarters. This has also been proposed:

http://en.wikipedia.org/wiki/World_Season_Calendar

The other choice is to stick with three months in a quarter, with one month getting 31 days and the other 2 getting 30 days. I tend to think this is the most reasonable course of action. Here is a calendar system that works this way:

http://en.wikipedia.org/wiki/World_Calendar

Now, so others have proposed that, instead of having a day or two each year outside of the week, we should stick with 7-day weeks all year, but change the number of weeks per year to keep the calendar with the right "average days per year". These so-called "leap-week" calendars are interesting, but I think they would tend to drift a little too far from the astronomical events for my tastes. The first day of each season would drift around by a few days each year.

Anyways, for more info on this subject, look up "Calendar Reform"

Two good sources are wikipedia:
http://en.wikipedia.org/wiki/Calendar_reform
and this one:
http://personal.ecu.edu/mccartyr/calendar-reform.html

I'm in favor of The World Calendar, how about you?

Blockbuster 'n4 - by Elcon Industries

I'm going to be getting rid of some of my videogames. They take up too much space, and I'm never going to get around to repairing them all. This one is from a company called Elcon Industries, formerly of Royal Oak, MI. It is a discrete logic game (I assume), with 5 different games available. (The marquee actually says "Blockbuster +4", which makes more sense.)

I assume these are all variations on Pong/Breakout/etc. As you can see, it's not working properly, but it does run through the "attract mode" on power up.




I'm wondering if this is an original game, or a clone of an existing one?

You can see some graphics glitches, but it is kind of interesting. The Cosmic Attackers game I have from the same company had a Sega Space Attack PCB inside.

Here are some more stills:











You can see that it also has a few bulbs which light up some game description text, and there is also a single "seven-segment"-style display for good measure. I'm not sure what that is for.

I'd love to hear from you if you have any info on this game, or others like it, or info on Elcon Industries, or ideas on what to do next :)

I don't have the key to the back of the cab, and I haven't "broken into" the back to take a look at the circuit board yet. I think that might be the next step.

Math problem #1 - piecewise approximating functions

I'm the kind of person that can get very interested in things that others might not notice. For me, his seems to occur from time to time with math problems. I'll be thinking about an engineering problem, and I will get caught up with some mathematical aspect of it. Usually, it's some problem which is easy to state but not obvious to solve. (Then again, I'm not a mathematician)

Over the years, I've gathered up a list of these problems. And now, I'd like to share some of them on this blog. I hope some of you, at least, will find them as interesting as I do.

---

Today's problem is fairly simple to state - and I thought about it for the first time many years ago. Suppose I have a continuous function y=f(x), defined on an interval from x0 to xn. I know _everything_ there is to know about the function. Now, for some reason, I need to approximate the function using a "piecewise-linear" function. This is just a set of straight lines connected together at "break" points. (You can also think of this as an approximation based on splines.)

For say, a fixed number of break points, what is the "best" way to approximate the function? (BTW - this is something that is practically done all the time, in embedded computer programs, using "table lookups" to approximate functions)

Some clues:

For a given set of breakpoints located at each x_i, you can start by picking the breakpoints at (x_i, f(x_i)). In other words, points on the curve f(x), and connecting the points with straight lines. However, you will quickly notice that the approximation is biased, based on the concavity of the curve.

A better way for a given set of points at x_i, is to solve the linear least-squares problem to find the optimal y values, which minimize the error between the approximate curve and the actual one.

But the key question seems to be - how do I locate my points in x? I see no easy way to do this, without non-linear iteration. It seems strange that it is trivial to locate the points in Y given X values, but hard to locate the X values. I can imagine some heuristic rules like "I should use more breakpoints where the function is 'curvier'". But it's not at all clear what this means :) Maybe I need to think about the meaning of "best" a bit more.

So, to summarize, we have a situation where we have a function which we know everything about, and a simple space of approximating functions, but we seem unable to match the two together, without resorting to nonlinear iteration.

If this one is too easy for you, feel free to handle extensions to this problem with higher order piecewise splines, and/or multidimensional functions. :) I can imagine practical applications for a good algorithm in this area.

Yikes - more than 2 years without blogging!

Not the kind of anniversary I wanted to celebrate. Anyways, I'm in the middle of a move to a new house, and work is heating up. So, hopefully around October, things will settle down...and I will try to post something more regularly.

The Road to Reality

I have been interesting in Physics as a hobby for a very long time. Back in the mid-90's, I was reading about Quantum Mechanics and Relativity on a fairly regular basis. I had to really dig to find books that were deeper than a purely "popular" treatment, but not so deep that an engineer could actually make sense of them. Some math, not all math.

Having been trained as an engineer is "almost enough" to handle "some" of the math, but I ended up with an awfully long road ahead. I eventually got a bit discouraged, but never quite gave up. (Emulation came along and I got a bit distracted for a number of years.)

In 2004 Roger Penrose wrote a giant book on Math and Physics, call "The Road to Reality: A Complete Guide to the Universe". It is a highly mathematical, modern treatment, but it builds on itself such that, theoretically, someone with some math background can actually understand it all. (At least, they'll be able to self-direct to other resources as needed.) There are 16 chapters of Math (the first 1/3 or so), followed by as many on Physics. For comparison, my formal math training ended at chapter 7. I now find myself in chapter 15, nearly finished with the math section. It is definitely not for everyone, but it's exactly what I needed.

Finally, I have found that discussing the details of the book can help a lot with the understanding. I recently created a Yahoo Group called RTRFANS, for just this purpose. With this book, and with internet resources that weren't available in the mid-90's, I've now got a shot at understanding truly modern physics.

Some porting work

I really need to post more often!

For a while now, I've been wanting to experiment with new methods of high-speed circuit simulation. The idea would be to prototype some discrete-audio stuff, possibly for MAME, using something like Python.

After looking into the requirements, I realized that I needed to handle polynomials with a single variable, and ratios of these polynomials. Also, I needed to be able to handle real or complex variables. I looked around on the web, and I found that SciPy is finally coming along nicely on Windows. However, I wasn't entirely happy with the root finder they use.

Along the way, I also found the ratfun package, which looked perfect, but was unsupported on Windows. I dug in and in a couple weekends, got it building under Windows. I think I'll be using it for the experiments, whenever I get back to it.