I just finished soldering the first Prop Dev Stick and tested it. After installing the FT232 drivers I was able to program the propeller straight from the Propeller Tool. Serial Terminal has also been tested.
I am going to be shipping a couple of these for testing. If you do embedded systems or mess around with micro controllers I would like for you to test it out. I am offering a fully working and soldered board for just the price of parts alone ($20). Simple stuff like usability, durability, and performance will need to be tested in real life scenarios before I move it into production.
The verilog code is almost fully debugged. The demo code that will run on a Parallax Propeller is in the works. Right now the demo is fairly basic. Today I wrote a C program that takes a 4-bit bitmap image and strips out the header and and converts it to a 2-bit image. It then reorientates the data so the image is “correct”. Bitmap images data reads the image from bottom left to top right. This is essentially backwards. So the program corrects this which means less work for the microcontroller and faster transmission of pixels.
So I changed the font of the site and tweaked the hell out of the backend. Hopefully everyone sees a performance increase on there end. I also changed the colors a bit to remove allot of the orange.
So I think I have been bitten by the FPGA bug. I ordered the DE0 board from Altera this morning. Should arrive by this weekend. I have been thinking of doing a “begineer series” on FPGAs much like how the Arduino introduces people into the world of microcontrollers. Would people be interested in that?
I have been wanting to do this for awhile but have not gotten around to it. I took my Open Bench Logic Sniffer and sniffed the e (in picture from top to bottom) of the Atari 7800 MARIA chip. This is what the signal looks like before it goes into the video mod (D/A converter).
I am still learning how this translates into a picture on the screen. If anyone has any insight into this let me know.
So for the new 128×32 DMD I am using a smaller dot pitch LED Matrix with a size of 1.9mm. This means they are the same size as standard DMDs used on production machines. I secured a supplier and I can provide any color LED for the DMDs. Red, Orange, Amber, Blue, Green, ect. These are currently not compatible with production machines but are intended for Home Brew Pinball machines. They are very easy to work with.
Instead of the wacky voltages of a standard DMD mine only needs a +5V supply. Standard DMDs also are hard to drive with microcontrollers because you have to fill each “level” individually and you have to do it fast enough to keep up with the refresh rate. My DMD runs off a FPGA which means you don’t have to worry about how fast you send the data to the display. The FPGA takes care of all the matrixing and color levels. All you have to do is send the data in 1byte wide chunks which is perfect for Microcontroller use. If you are doing animations you can stream data off an SD card by doing byte writes and then pushing that data directly to the DMD.
Prices will be $250 for quantities 1-9 and $240 for anything over 10. They come with the SMD parts soldered on and the FPGA pre-programmed. You will need to solder the LED modules on. The LED modules will be tested to ensure that they are in full working order.
So I was still getting glitches on my inputs for Reset_Vector. I couldn’t figure out what was causing it because it would happen randomly and I couldn’t repeat the problem. The false inputs caused issues with ball triggering, score detection, and playfield actions. I figured it had to be glitches on the lines caused by EMF or something on the input driver. I knew it was the input driver cause when a solenoid fired randomly like the pop bumper it would register a hit which means that the microcontroller detected a hit.
To fix this issue I added a simple debouncer routine. Basically it makes sure a input is pressed for at least 2 Kernel cycles before saying that it was a hit. This keeps random spikes from registering as hits.
What it does is read in the inputs into a variable called new_inputs. The new_inputs then gets anded with a variable called old_inputs and the result is the inputs that where held for two kernel cycles. Then the new_inputs is copied into old_inputs for the next cycle to happen.
This system can be easily expanded to 3,4,ect cycles so the debouncer is extremely configurable in its sensitivity.
