Friday, June 02, 2017

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.

Thursday, August 26, 2010

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.

Friday, April 16, 2010

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...

Saturday, April 03, 2010

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:

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:

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:

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:
and this one:

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

Saturday, March 20, 2010

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.

Saturday, February 06, 2010

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.

Thursday, August 14, 2008

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.

Monday, May 08, 2006

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.

Tuesday, February 07, 2006

The Joy of LaTeX

Ok, I'm a geek. Over the past 10 years or so, I've worked on a handful of math and engineering problems that I thought were interesting. Yes, most of them were "spare-time" activities, although a few were inspired by work stuff. I recently made a list of all of them, and I suddenly had the urge to publish them. Maybe some other people will find these things interesting as well.

At any rate, I wanted a way to publish them with all the math equations, as well as generate PDF's and HTML. I had heard about LaTeX for a long time, but now I had a fine excuse to give it a try.

I first tried the TeXLive distribution, but I never could get it to work on Windows. (Maybe this has been fixed since then) Then I tried MikTeX. It was a fairly straightforward installation. After working out a few examples, I was hooked. My first draft of a test article turned out pretty well:

I use pdflatex to generate pdfs and htlatex (part of tex4ht) to create html + pngs.

At any rate, it's nice to see that free software can be used to do professional typesetting. I'm planning to use this stuff to document my math problems, as well as some theory behind discrete sound filtering in MAME.

Tuesday, January 10, 2006

Actual MAME-related work!

For those who haven't heard, the speech chip used in Berzerk has been reverse-engineered by "Lord Nightmare"! This is something I've been waiting for for about 7-8 years! I'm sure that the emulation will end up in MAME and PinMAME sooner or later.

Because of this, I spent some time over Christmas looking at the analog filters on the Berzerk speech board. (These are applied to the sound after it comes out of the chip.) I finished the analysis, and it should be pretty straightforward to add them into MAME after the chip emulation is done.

For what it's worth, I've been trying out Maxima with wxMaxima to do the symbolic math for circuit analysis. I know, I could have used SPICE or something - but doing the math from scratch makes it easier to understand what is going on.

After I worked out about half of the math for these filters by hand, I ended up with about 6 pages of algebra. At this point, I figured I should use this as an excuse for learning Maxima. Sure enough, I found an error on page 5. Darned minus signs! :)

The second half of the analysis took about 5 minutes, since the code from the first half was already done, and I could re-use it!

For those who care - the filter is a third-order lowpass - a first order lowpass, followed by a second order with a resonant peak around 2400 Hz.

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 Starshi...