Raspberry PI Arcade Project

Seeing as there's a lot of techies on this site, I thought some of you might have gone out and bought yourself a raspberry PI.

Edited by RaveN - 04 May 2013 at 1:26am

Sounds like a great idea, my pi is sat on the shelf at the mo.

OK, I was keeping quiet on this until such time as I've completed more than one processor and added more support in the software, then I was going to release it, probably under some form of open source but I've done similar with an entirely off the shelf Arduino.

I'd better throw my hat in the ring too then!

I've made a similar device using a dsPIC33 demo board that I had laying around, and using just a couple of '573 latches managed to interface it to a 6502 socket on a bootleg Asteroids board. There's an RS232 serial port to connect to a PC running Hyperterminal, so I can send commands to the dsPIC. I can read/write data to addresses, and have part of a RAM test written up to now.

I'd already done a 6502/POKEY and a 6809/POKEY emulator on this same dsPIC33 http://www.youtube.com/watch?v=GIcezrwN6RE so for me the next step was to try to plug it into some real hardware and see if I could read and write data. This Asteroids Frankenstein brain is the result. I'd like to get it running Asteroids using 6502 emulation, but it doesn't work properly yet. Though connecting it to a known faulty Asteroids PCB is probably a bad idea...

The aim was going to be a 6809 interface running 6809 emulation, plus some maths hardware emulation that the dsPIC is quite good at. No prizes for working out what game that would be with a 6809 and math hardware! But I got this Asteroids PCB so that got connected up first.

I did think of using an RPi myself for this, like RaveN has done, but I had the dsPIC board and running some 6502 emulation already, so for me it was easier to do it this way. The RPi will be a lot easier to expand on that's for sure! I like the idea of a logic probe fault finder though, great idea. I'll be following any progress with interest. Keep up the good work!

I've done a bit more work on my "test brain" board and it's actually proved it's worth and found a fault today, showing that this sort of thing CAN be useful.

I thought I'd share what I've done with you guys here, as it's likely you'll be thinking about the same sort of thing. I'll be talking specifically about Asteroids hardware tests here, so apologies if this loses anyone technically, but the same principles will surely apply to other games.

So my board can read and write anywhere in the address space, driven by a crude and simple command line from the PC terminal. After getting it working plugged into the Asteroids, I could read things like the DIP switch, button inputs, write to sound registers, etc. as I'm sure you've been doing too with your testers projects. Next I wanted to run some simple code in a loop so that it would keep the Asteroids watchdog happy, and read and update all switch inputs and show on the PC terminal screen.

But with an Asteroids board, reading and writing RAM, button inputs, writing to sounds, etc is only about a third of the game hardware. The DVG vector generator has the rest of the chips, so how could this be tested from the dsPIC board? What I've done is made the dsPIC code read the DIP switch and use that value to select from a list of specific DVG tests. First test simply inserts a vector HALT instruction to 0x4000 (vector RAM, DVG address 0x0000) , then start the DVG running. It then checks to see if the DVG has halted, and repeats.

Second test inserts a JMPL 0x0001 instruction at DVG 0x0000, then a HALT at DVG 0x0001, and runs that in the same way. So that will test a little bit more of the DVG circuit by exercising the JMPL state.

I've then made a JSRL test to test the DVG stack to one level, which it passed OK an my board.

After that I wrote another 3 test functions to do 2, 3 and 4 JRSL subroutine levels. On my board these all failed, only the single level JSRL would work, the deeper calls never halted the DVG.

I assumed (wrongly!) that one of the three 74LS170 file registers that make up the DVG stack was faulty. Desoldering and changing them didn't help though. Next I looked at the '191 counter at K5 and could see by selecting my test functions that although it was getting a clock in, the outputs were not changing. Replacing the '191 now allows all 4 depths of JSRL instructions to pass the test. So it is useful!

Of course I could have found this fault in other ways... like , er... well anyone suggest how I'd have found this without the test code? With just a 6502 and the Asteroids ROMs, I doubt you'd be able to narrow it down to that? I only have a logic probe and a 'scope, so not sure how I'd find that fault with just those.

I've made test routines to do a simple draw vector for vertical, horizontal, short vertical, short horizontal and  absolute position.

Now I'm doing more devious vector tests, like:

0x0000 JMPL 0x0001
0x0001 JMPL 0x0002
0x0002 JMPL 0x0003
... etc

Then HALT as the last instruction in vector RAM. This would exercise the '191 counters at board locations F5, H5 and J5.

With some careful thought and good knowledge of the game hardware, a suite of test routines could be built up to aid troubleshooting.

Of course these tests are all specific to Asteroids, but should easily translate to other Atari vector games. I'm sure other games could also have test routines built up for them too.

I guess you could do all this with a Fluke, but having never seen or used one I don't know how simple that would be? I think the idea of a test box based on FPGA, R-Pi, or whatever, would be to have such test functions built in, so even someone with less technical knowledge could manage to plug in the CPU socket, run the tests and see where a failure occured.

RaveN: My scope is a GDS-2104 with 4 channel, it was bought for developing a 3 phase AC rectifier, based on a dsPIC33 controller for my day job, so I needed at least 3 channels. So you can see why I'm familiar with the dsPIC33 and why I've used it for this "test brain". Simply familiarity with the code and tools. The scope isn't really all mine, it's also my business partners too, but one of them would not know how to switch it on... so it seems a much better idea to leave it in my little workshop where it can be used for other  things.

Sadly, I'm also afflicted with the same problems as Guddler and RaveN. Working stuff out is fun until you've done it. Then finishing it off to be useful to someone else is not so much fun and it gets forgotten about. So don't expect some magic arcade test box to come out of all this discussion! 

Some excellent projects there guys - I can't wait for further updates. I figured I'd throw my hat in too .

I had an idea ages ago for a hardware cheat engine: something that ideally would attach to a CPU/RAM bus via a test clip and allow you to reproduce some of the MAME cheat functionality. The basic idea is to snoop the bus and look for reads or writes to magic locations such as #lives, energy level etc and then grab the bus and either stuff RAM with a fixed value or return the modified value to the CPU. My perfect end result would require no hardware modification to work; obviously that brings a host of challenges and I'm not sure it would ever be possible at least with my level of knowledge if electronics.

It's Arduino based because my Verilog is so rough that I'd be undertaking two major challenges simultaneously, plus I had a ton of trouble finding a source for the SCA style connectors I'd need to get a chunk of IO to my Spartan dev board :( I still intend to turn this into an FPGA-based learning project once I've got the underlying hardware designed and proven.

The current project state is much closer to a bunch of random source files and a breadboard feeding into a logic analyser than anything resembling the goal above, but it's good fun and sufficiently interesting that I keep coming back to it as time permits. And then shooting off at tangents like designing a library for it :)