..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 burnin 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.
Thursday, August 26, 2010
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 "bigscreen" 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 fullsized arcade game? The possibilities are endless, but the hotel room is not, unfortunately. If only I had a TARDIS...
I started by testing out a Coleco "Telstar" Pong and the Atari 2600 yesterday. You can see my team of playtesters trying out some "bigscreen" 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 fullsized 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 7day 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 13month 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 13month 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 7day weeks all year, but change the number of weeks per year to keep the calendar with the right "average days per year". These socalled "leapweek" 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/calendarreform.html
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 "sevensegment"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 "piecewiselinear" 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 leastsquares 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 nonlinear 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.
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 "piecewiselinear" 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 leastsquares 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 nonlinear 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.
Subscribe to:
Posts (Atom)
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 alrea...

For those who haven't heard, the speech chip used in Berzerk has been reverseengineered by "Lord Nightmare"! This is somethi...

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