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

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

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:

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?

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

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.

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.

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.

Subscribe to:
Posts (Atom)