Just testing the sprites a bit more, all of them at once. Also changed to a 14″ monitor.
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!
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! 🙂
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.
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 is up and running!
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. 🙂
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.
Now, on to colors! 🙂
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:
And this is how they look:
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. 😉
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. 🙂
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.
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.
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.
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.
Ok, time to power it up! Will there be smoke?
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!
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?
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.
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!
The 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.
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!
The “sprites” are still only white boxes. But they are now 29, and most important, the program controlling them now runs on a Pi2!
I knew the Pi2 was quite a bit faster than Pi, but I was surprised of the speed when loading X anyway. X started in a few seconds. Very nice!
Hm, accordning to http://www.raspberrypi.org/forums/viewtopic.php?p=309582 it is possible to extend the amount of maximum sent data of the SPI bus! This is most interesting. This means I should be able to transfer a full framebuffer in one single transfer. Using 352×288 i might be able to do a full frame 30Hz update. If I succeed in increasing the SPI reception in the FPGA to 60Mbit I, in theory, can reach 60Hz.
This is not what it was intended for, but…. Still good to have some power in the SPI.
My monitor interface PCB is done! Now I just have to wait two weeks for it to arrive…
This is a picture of my first I/O-board for the Pi, using I2C.
A simple board using MCP23017. I was planning to use it for debugging arcade boards by connecting it to the processor socket pins. This actually worked better than you may think, but I found a problem with the board. It seemed that if bit 7 of a port changed during some critical passage in the I2C communication (I only had my analogue scope then, so I couldn’t measure it exactly) all port pins was read as “1” by that particular read. I couldn’t find an error in my code or on the PCB (which is not advanced at all) so I asked around on some forums and got another nice guy to test it. And sure enough he found the same error. It all ended with Microchip writing an errata.
Now I needed another I/O-board without these problems. The MC23S17 is the same circuit but uses SPI (which is also quicker, better in my case). This IC does not have the bit 7 issue, and worked flawlessly.
Even if it worked as good as can be expected it was slow in this context, and I could not read and/or write to some devices on the databus due to timing problems. I had to seek another solution for my Z80 debugger. This resulted in the FPGA Z80 pod which has it’s own section, and should be able to emulate read and write cycles of the Z80 flawlessly.
The SPI I/O board will find other uses. My plan is to build a 2532 EPROM programmer using one of them. Even if SPI using MCP23S17 is not very fast compared to direct I/Os (although I tested it up to 10MHz clock speed successfully) it is nice to have boards with a lot of I/Os at hand. The Pi can use SPI clock speeds up to at least 60MHz, and using bigger blocks of data (it can handle 4096 bytes/transfer, it seems) you can actually get some speed. I hope it will be enough for my Pi Arcade monitor interface. See separate section. 🙂
In the 80’s Hantarex made arcade monitors. One of the best monitors around was the MTC9000. I like them. They give a very good, solid picture. They are fairly easy to fix and most parts are still available.
I have an old cocktail cabinet which holds a 14″ tube. Unfortunately the European 14″ tubes use a smaller neck connector than 20″ tubes, even if they are electrically the same. So…either I could make some quick hack and just solder a tube socket with wires to an original neck board….or I could make a new, fresh PCB capable of both 14″ and 20″, depending on what socket you mount. And voilá, this is how it turned out:
I got the PCB for the PI2 / PI B+ arcade controller adapter the other day. I have actually soldered one together and I will test this as soon as I find my Pi B+ board that seems to have grown feet. Or maybe I should buy a new Pi2 instead…
Well, here is an image of the unpopulated PCB.
Previously I did a similar board for the older Pi. This is for one player only.
I added some more functionality to the sprite module. Instead of writing to the registers that control X, Y, shape and visibility directly, I added buffer registers to hold the written data until the next frame starts. This should give glitch-free update of sprites no matter how you send the data. And it certainly shows on the moving demo. Perfect squares all the way! 🙂
Sorry, no pictures or demos today!
The PCBs I designed for the Z80 debug pod is on their way! Two PCBs, one debug pod and one board that connects to the Pi and the FPGa module.
Ok, after quite a hassle with a hard to find bug the sprites are now working as far as I can test them without RAM. I made a small demo. 🙂