BombJack up and running

I thought I would try porting an existing game implementation to my own board. I found this guy who made an implementation of BombJack, one of my favorite games. It was made using VHDL for a Xilinx FPGA. I don’t know VHDL, never used Xilinx and it was also made to use an external SRAM to “emulate” a lot of the EPROMs in the game, since the FPGA he used did not have enough built-in RAM. Also he added a converter to use a VGA screen, while I want to use an original 15kHz arcade monitor.

Fortunately, VHDL was not that hard to grasp, and the many comments and good coding style in the implementation certainly helped. Also, he had left implementations for all EPROMS for use in internal RAM, only commented out.

I removed all code for emulating EPROMS from SRAM, the SRAM code itself with bootsrapping and stuff. I also removed the VGA converter. I had to change all EPROMS to use the Altera internal RAMs instead.

One big problem was he used a processor core programmed specifically for Xilinx. Luckily I found an Altera port of the exact same processor, and could just swap it.

After some quirks and bug finding it sprung to life!

2016-03-19 00.25.11

At this point it seems to be working flawlessly.

2016-03-19 00.16.23

A big thanks to Alex! Without his implementation and hard work this could never have been made in such short time.

JAMMA board up and running

All tests are ALMOST ok! The only problems found are the P2_RIGHT problem and one of the pins of the big I/O connector don’t have contact with the FPGA pin. Bad solder joints under the FPGA. Not strange in any way. 🙂

So, if everything is ok we should take it for a test drive, right?

I have already cloned Sprint 2 to a modified version of my previous PCB, so I made a copy of that project and in the new one I changed the FPGA type and re-assigned all I/O’s. I also made this connector for the steering wheel giving the optos 3.3V, 0V and gets the pulses pack. Very professional work with the connector there… *cough*

2016-03-12 23.17.37The black connector in the middle with the gray wires. Yes, the one with the perfect solder joints.

And… It works flawlessly! 😀

2016-03-12 23.17.00

Haven’t connected the dip switches in the Sprint project, though… I should do that.

A new JAMMA PCB is born…

After my Pi arcade graphics board I thought I would take it a step further. It would be nice with a JAMMA board with a big FPGA, opto-isolated JAMMA inputs and a lot of I/O to add more functions and devices if needed.

So, I went ahead and designed one. It has the same audio amp as the Pi arcade board, it has 2×8 dip switches, all inputs from the JAMMA is opto isolated and it has one 40-pin and two 16-pin I/O ports. I also added the RAM from the Pi arcade board (512k x 8, 10ns). And the FPGA is a 55k one. Should be enough for many old games and also for many new projects with an added processor (it will probably be 100% compatible with the old Pi arcade board).

It took a few weeks to cad it (on my spare time), there are at least 150 pins for the power supply only… The FPGA has a total of 484 pins.

2016-03-06 21.37.30FPGA mounted together with the other surface mounted components.

2016-03-05 15.55.17…and the back side.

Mounting the FPGA was not easy, and the first attempt failed. However, after re-balling the FPGA with my soldering iron (i didn’t even think that was possible) I got a response on the JTAG chain!

I implemented a character generator in Verilog and started writing tests to read the JAMMA signals. By some reason 2P Right fails, everything else worked. Also the DIPs worked fine.

Yesterday I added a walking-one test for the RAM, and it seems the RAM is working fine as well.

2016-03-10 19.57.47The position of the printouts are messed up, but I think you get the idea. 😉

Today I implemented a sound test but I didn’t test it yet. For now it should output a 1kHz sine wave. I will make it output frequencies from 20Hz up to 20kHz when I get the base going.

Sprint 2 FPGA project

So, I decided it might be fun to squeeze an old video game into an FPGA. I do have my arcade adapter board which has an FPGA plus the needed video DAC and sound amp.

I thought I would try with Sprint 2 as it is a game I saw when I was young (too young to play) but always thought looked cool. Another plus was the small ROM space needed as my arcade board only has a 6k gate FPGA (using about 80% in total for the game).

After a calendar month of work I have learned a lot more about FPGA’s and Verilog, although there is plenty more to learn.

A very nice guy (Cimex on www.arkadtorget.se) supplied me with an actual steering wheel of the game and after making an opto board for it it works like a charm. Still missing a shift stick, but I added shift up and down inputs to the hardware instead, and that is working good for now.

Demo (in Swedish, sorry):

More demo videos

There are some more videos, I might as well put them here as well.

Shadow testing. This worked well….as long as the shadow didn’t move. When I think of it, this idea might not be fully tested, maybe there is one test left… 😉

 

Actual shmup demo. Animated enemies, animated ship, shooting enemies. Background stolen from another game. 🙂

 

This is the actual newer-looking shmup we are working on. Zoomed in, that’s why the ship seems a bit big. 😉

 

Very early video of NASG (Not Another Space Game) video intro.

Monitor interface finished

I don’t think I will be adding more functions to the graphics board. It can do what is needed (as far as I know now) so I think I will call it finished. 🙂 At least version 1.0. Maybe, in a few years or so, when better FPGAs are more affordable, I will do a juiced up compatible version. 🙂

A spec on the board can be found here.

Here is a version of the API, which is evolving all the time.

 

Game programming

The internet is wonderful.

Suddenly they are all around me. They are good at graphics, music, planning, brainstorming… And, just as suddenly, I find myself being a game programmer. 🙂 I will give you a peek preview of the background of the first level. Tim has made a wonderful job!

New arcade PCB

Many good things have happened. 🙂

First the new PCB arrived.

2015-04-20 18.09.30
The JAMMA connector was perfect, the new footprints I made was ok… I soldered the components and gave it a go. Worked fine! I had to modify the sound filter somewhat and I think I’ll do a re-design here, but it worked fine after adding a resistor.

So, sound amp is working, all inputs from joysticks and buttons are working, JAMMA connector is ok, Pi connector is ok, FPGA module works… I got rid of the last known problem in the FPGA and added a few new features. Now, for each bitmap, you can decide on what part of the screen it is visible. And I added the same thing for each sprite. I can now set a window for each sprite in which it is visible. Great for games with more than one area on the screen at once. 🙂

2015-04-21 23.14.02
This is how it looks with all components mounted, except for the 3.5mm audio connector which has not yet arrived.

FPGA audio!

I started yesterday evening to make a…sound board, sort of. A simple sound data buffer in the FPGA (two sprites were lost in action…) and being able to write to the buffer using the SPI interface. Then, if there are any data in the buffer, the FPGA reads the data and outputs it using 8-bit PWM on the very last free pin. I didn’t have much hope about the sound quality, but it turned out to be quite OK using only a simple RC filter directly on the output of the FPGA. The PCB I’m waiting for has a nice, sharp butterworth filter and a local digital buffer, so it should be even better.

The sound is loaded into RAM on the Pi. Seems it happily allocates at least 40M of RAM. 🙂

Seems YouTube even recognized the music and added some ads to punish me. 😉

Arcade monitor, oscilloscope showing the audio output and computer screen showing writes to the FPGA.

PCB finished

Today i finished the new JAMMA-pcb. I will wait until tonight with my order since I usually remember something I have forgotten just after ordering. 😉

The PCB is designed to be connected to a Raspberry Pi 2 or the older model B with 40 pins I/O. All I/O-pins except CS1 is used. This was enough for 2 players each having joystick, 4 buttons and a start button each. Also coin and test are connected. However, you can use the board with any processor or system as long as they use 3.3V (or have level converters) and have a SPI bus.

I have also added sound. If I can get the FPGA doing what i want it will have 8-bit sound PWMed out of the very last free pin. If you want to use the FPGA sound you will loose a sprite (or maybe two, I’m not sure) since it needs a RAM block and at least 2k RAM. The PWM goes on to a double Butterworth filter (about 22kHz) to get rid of the PWM frequency (probably about 350kHz) that should be supressed by about 100dB by the filter. I added a 3.5mm plug to be able to connect to an external amp, or to connect to the on-board amp that follows the volume pot.

LOTS of things added, so I’m pretty sure something is not OK when the boards arrive. But that’s why they are called prototypes… 🙂

Capture

Font handlig and VSync syncing

Today I implemented fonts. Now you can draw a font of any fixed size anywhere on any bitmap. Well, almost. I still have to take care of what happens when you “paint over 511-0”. But I have a solution for that. Since the font I used was 16 pixels wide nothing was affected.

I also added an important thing. Everyone programming anything to do with video understands the importance on being able to wait for VSync. If you sync your sprite-movements with VSync they will move very smooth. I missed this when drawing the PCB so I had to solder a wire instead. The result was really smooth movements of…everything. 🙂

Or…well. In real life it’s real smooth. 😉 Note the layer handling of pacman, ghosts and text.

 

Graphics HW more or less done…

I spent a few hours today trying to come up with a good API for the graphics board. Started good but sort of got messed up after a while. Probably due to hunger. 🙂 I will have to re-think how to handle everything in a good manner.

However, it did result in a graphics test program.

Pacman and his ghosts uses half resolution, i.e one Pacman pixel is 2×2 pixels. Arthur is at his original resolution, but you can hardly see him due to my mobile camera. Also I didn’t get his animation right, it looks like he’s having stomach problems. Also the ghost eyes seems to big, but that is the camera being overexposed or something. Looks fine in real life.

I have also implemented layers for sprites. There are three bitmaps you can play with and each sprite can be in any depth position (under/over/in between).

Sorry again for the crappy video…

So, the HW is fully fit for some serious game programming!

Graphics handling on the way

Ok, after struggling with the SPI a bit (I still have not managed to transfer more than 4096 bytes/transfer) I decided to code around the problem for now.

I implemented a color handler that builds a color table of all sprite shapes and bitmaps needed for a specific “scene”. This seems to work well.

So, tonight, for the first time, I loaded a BMP file with 320×240 pixels and about 80 used colors. Tadaaa! 🙂

2015-03-28 20.49.07

I then loaded a few test sprites which added a few colors more and placed one on a higher layer. And that worked perfectly too, both concerning colors and everything else.

Happiness! 🙂

All ok!

Ah! Now everything seems to work as expected. Sprites look perfect, there are no ghost pixels, I can abuse the SPI as I want without display problems, FPGA is stable… So, tomorrow I will start coding a small demo and extending the API. Let’s hope no more bugs turns up! 🙂

Color working

Color is up and running!

2015-03-23 20.16.24

I had a lot of problems with instability. Sometimes a build worked, I then changed some small detail and it stopped working. The synthesizer says it should work up to 115MHz and I ran it at 100MHz. Should be OK. But when I went down to 90MHz the problems seemed to stop. Now it seems stable.

Just a few strange problems left. When a sprite is half outside the screen to the right some red pixels show up to the left, outside the picture. Should be impossible. Very strange. 🙂 A color seems a bit off on the sprites as well. If you look you can see that the right white stripe on each sprite is thicker than the left one. It should be a black and a white stripe. Not two white. But I don’t see this problem on other sprite shapes. I have to investigate…

After that, if nothing else turns up, it’s time for some serious C and C++ coding to make use of it. 🙂

Sprites seems ok!

After some tinkering I found a nasty bug in the sprite-data-loading-stuff that made the FPGA hang now and then. With that out of the way I looked a bit more at the sprites. They looked sad. 🙂 After some creative clocking/buffering/cheating I finally made them look as they should! 🙂 Let’s hope there are no more lurking bugs in that section now.

2015-03-22 19.21.35

Now, on to colors! 🙂

Sprite work….

Ok, if I want to test the sprites in a good way I have to make it possible to load some graphics from files. I found this tool for drawing sprites, and I made it export my sprites to a .bmp file. I then found the .bmp file format specification and made a class that imports .bmp files and can send the sprite data directly to the RAM on the graphics board. (Note: .bmp files stores lines “upside-down” compared to normal graphics. The line at the bottom is stored first. Strange.)

This is how my sprites should look, a number with a white border:

2015-03-21 20.40.16

And this is how they look:

2015-03-21 20.39.21

So, they are “rotated” one pixel in one direction, and one line seems to be missing in the other. Interesting. 🙂 This means I’ve got plenty of stuff to do tomorrow night. 😉

Animated sprites

Ok. I’m not really sure how this happened. I spent about 3 hours last night coding Verilog. I re-designed the sprite module and I made a whole bunch of new states in the main state machine, most involving a pipeline used to get data at 100MB/s from the RAM. I just made it compile. Today I tested it, and…

…it just sort-of worked! You can see one issue, the bottom rows in the sprites seems to be wrong (these are the first pixels on each sprite on each line, monitor is on it’s side), but as a whole it worked better than I could ever have hoped for. Luck actually strikes sometimes. 🙂

I will try to do some more tests tonight. I have to start writing some C-functions to handle sprites and bitmaps so I can import some real image data. Lines and gray-scale sprites are boring. 🙂

“Sprites” and bitmaps

The potential problem with the address pin was a problem. Not with the PCB, but with the FPGA module. One pin is stuck low. 🙁 Fortunately I had another one. Using that one there were no repeating random pixels! 🙂

Yesterday I worked hard to solve a really strange problem with the graphics. It turned out I just wasn’t finished thinking when I wrote the Verilog code. I tested my theory tonight and…. tadaa! No more strange graphic problems!

“Sprites” are still only white 16×16 pixel squares. These are the next step.

I drew two thick lines on the top bitmap. Behind the top bitmap the sprites are displayed, and behind the sprites there are two more bitmaps with one dark stripe each. Not that visible in the video, you will have to look closely. Also testing the separate X and Y offsets for the bitmaps, as you can see. 😉

Next step is to look at the sprites. After that I have to re-work the design of the main state machine. There are some serious optimizations needed to make this work without issues… When that is done I will add the color decoder.

Arcade Monitor Inteface PCB FINALLY arrived!

After 5 long weeks of waiting it finally arrived today. I even left work half an hour early to get it in my hands as soon as possible. 🙂

Will the RAM fit? Will I be able to solder the RAM? Will the 8-bit R2R ladders work ok? Will it burn?

Itead Studio did a good job as usual.

2015-03-17 18.02.59New PCB with RAM IC on top.

Ok, the footprint for the RAM IC was perfect. I wasn’t all all sure it would be as I made the footprint myself. After some tinkering with my solder paste I managed to smear it somewhat even on the pads, and then used my hot-air to solder. Worked good except on some pins that was a bit bent. No problem to fix.

Then I added the resistors for the three 8-bit R2R-ladders.

2015-03-17 18.52.52Resistors added!

This was much quicker than anticipated. All of them (about 75 or so) was soldered in no time at all. I then moved on to the connectors.

2015-03-17 19.09.25Finished board!

Ok, time to power it up! Will there be smoke?

2015-03-17 19.41.12All connected, running on 5V from the Jamma connector and feeding RGB + sync back.

At first there was no working sync. I examined the board and found that I made some sort of mistake. The sync signal was not on the correct pin on the FPGA. A quick swap in the FPGA code and… voila!

2015-03-17 19.41.33Taking photos of a CRT with a mobile phone camera is not easy… There are no stripes in real life!

Random pixels! Beautiful! This is the contents in the RAM after powerup. At least it seems to read RAM as it should. Or…. There actually seems there might be a problem, I see some repeating patterns in the random pixels. Might be a stuck address pin. We’ll see later. The picture is perfectly still, no changing pixels or anything. Promising.

What happens if I press the test picture button?

2015-03-17 19.41.58

Ah! Totally PERFECT shades of 8-bit RGB. The picture does not do it justice. It really looks awesome! This means you can get away with generating 24-bit video directly from output pins from a FPGA using R2R ladders with a really good result. You need 0.1% resistors, but still! This result is much better than I dared to hope for. So far this is a total success. Now I will move on to some tests using the SPI to write to the RAM. I expect to find some problems here since I see a repeated pattern… See next post for results.

 

PCB for Z80 debugger arrived

The PCB’s for the Z80 debugger arrived!

I’m still missing one of the IC types, 74LS244, so I couldn’t finish the assembly. But, so far so good!

2015-03-12 20.06.05The pod is to the right. It will connect to the main PCB using a ribbon cable, 40pin, to the top connector. I thought I could use an IDE cable, but I had forgotten about the alignment pin… So I have to order some new 40pin connectors. To the left on the main board the 5V supply and the connection to the Pi is placed. Only half of the FPGA board connectors are soldered for now, otherwise it will be hard to solder the remaining IC:s.

2015-03-12 20.06.36This is how it looks with the FPGA module mounted.

And the FPGA module fits! Good news, since I use the same footprint on my arcade monitor board as well. That one should arrive next week. Exciting!