Wednesday, September 2, 2015

Time flies!

Apparently I'm using a really really old version of MPIDE to compile the code with....
The servo-problem was solved a while back:

  12/21/2013 <BrianSchmalz>:
    * Fixed bug that caused glitches every 107 seconds.

The question is - do I dare to update the core software, considering the numerous changes I've made to the stock libraries? Can't say I recall exactly what I've changed and where.

But I suppose I need to do this someday anywho since the laptop I'm using is a very old one and can't even compile the code with optimizations active. For the release version I'm pretty sure I want to use compiler optimized code. :)

Also, a programmer called Majenko suggested that the Arduino cannot reliably communicate over serial at higher speed than 9600 baud. I'm not sure what to believe here, since I've used much higher speeds - but still, Majenko is a great programmer and has supplied a lot of libraries and corrections, so I figure he/she knows better. If the serial interface used to program the device is different than the actual interface the MCU is using for the pins inside sketches this might explain why the sketch is running great connected to my computer while failing connected to the MCU.

"The Arduino is unable to communicate reliably at higher baud rates due to the clock being unable to accurately divide down to the right kind of values, but the chipKIT boards, because of the higher speed master clock, can do it more accurately. As a result the Arduino sometimes can't communicate through serial with the chipKIT boards. Try running at a lower baud rate (9600)." [Chipkit forum]

9600 baud could possibly be enough for my needs, but I'm not sure what the "damage" to SD-reading and frame building would be. Still, it's something that can be investigated in the future.


I've installed the sound board and light board now (light cables are still not done thou).

There's a slight ghosting issue present, hopefully it won't be disturbing with the proper lights as I've seen commercial machines do this as well, if you look closely enough. The problem is caused by the weirdest error ever - the lights are running perfectly when connected to a computer and receiving serial input. But when connected to the Chipkit it just goes bonanza. Naturally I suspected the Chipkit first due to recent interrupt changes, but the sound board worked fine on different serial ports and speeds so there's no problem with the serial ports, of that I'm sure.

I realized I was using a rather long (with delayMicroseconds()) interrupt routine on the Arduino and this caused problems with the serial input - but only when connected to another microcontroller... I shorted it down and now it works with the Chipkit, but is instead plagued with ghosting. Which it really shouldn't be doing. It's pretty weird, but for now this "workaround" will do great, but I'll  revisit this in the future if it turns out to be a proper problem. 

I've also programmed highscore saving/loading as well as proper settings saving/loading and a hardware alert routine during boot. The servos started acting up as a result of the interrupt driven display so I replaced the interrupt servo routine with a software based one instead. Seems to work well, except for an occasional servo "tick" now and then on the first out of two servos. This can probably be avoided by doing some magic in the library-code, as I suspect it's dropping due to a timer reset or similar. Quite possibly a dummy servo can be configured to take the hit instead...

Overall the machine is starting to feel really slick now and the software is bumped up to version 0.85!

Monday, August 31, 2015

Major Code and Sgt Refactor

I haven't gotten the motivation yet (damn weather!) for soldering the new light cables, but I have spent some time with the code the last days. Figured I could do something better than what was in place.

Said and done -
Previously the code was run sequentially and always in the same order. This has now been changed to be done via interrupts instead. I am drawing line by line, layer by layer, and it works great!

I've also sacrificed a little RAM for speed/comfort by adding a backbuffer. While the display is blazing away as fast as it can from the drawbuffer (i.e frontbuffer), all new drawings occur on the backbuffer. When the buffer is finished it simply redirects the current line-pointer to the other buffer and the display never knew what happened. I've tried this in the past, but I never got the flickering to go away. I realized I was going about it the wrong way - there's no need to restart the drawing from the top whenever the content changes. I'm already drawing the screen line by line times eight so nobody would notice really. I was also previously stalling the rendering for buffer creation due to the sequential handling and that caused flickering too. But by avoiding the above and rendering with double buffers, interrupts has given me a rock solid 60 fps screen that is flicker free and brighter than it's ever been. Best of all - it's fixed fps, so it will never dip below this. Ever.  

I've also moved solenoid and switch handling into the very same line-drawing-routine, except that I only process information from these once 32 lines has been drawn (i.e at vertical blank, like the good old days). This has almost given me a 100-200x frequency on I/O without causing any flickering!

This is extremely good news as this means less chance of a missed switch hit or a solenoid firing too long. Previously, if the rendering and SD-card loading took 30ms, that was 30ms that couldn't be spent on anything - i.e a switch hit would not be registered during that time. That is remedied now thou and just to be extra sure I rewrote the switch code to be 4-5x faster as well. Turned out that piece of code still used the old and slow digitalWrite-code, but I took care of that. 

Furthermore - with the changes above the logic loop didn't have to be running as fast as possible. So I've locked the game logic to 40Hz, including SD-card reading, buffer creation, transitions etc. I did a little counting and found that it never dipped below 42 Hz (this is all done on the machine's "spare time" now, mind you), so I lowered it a little extra for safety. A fixed rate means no surprises to game logic and the frame is guaranteed to be finished in time. Should it not be, however, the double buffering will prevent any flickering - which is always nice!

For the record.
I've tried using interruptTransfers in the DSPI-library, but they refuse to work for me due to trouble with the Max32 board definition and conflicting hardware vectors. Ironically, I'm the one who reported the bug in 2013 and it hasn't (to my understanding) been fixed yet...

Anyhow - had that been fixed I could have load animation data and sending data to the display "in the background" and go about my business the usual way. My way works just the same, but different.

Finally, I wrote a script to remove the initial two bytes of junk from wav-files. However, as I didn't read up on the wav-format, the files ended up being the correct size but not valid wav-files. Instead of working around it I simply powered through and converted the 636 sound files (will they all be used anyway?!) manually. That was joyful, for sure, but now the audio seems to be working fine. Still need to convert the old audio routines into new ones and decide on a sound priority/scheduling scheme.

Baby steps...

Thursday, August 20, 2015


I found this pretty interesting -
This is a (blurry) shot of the inside of a Briarwood Aspen pinball machine. That's a commercial game from late 70's.

1) Briarwood Aspen inside. Not much in there to be honest...
Compared to my own pinball that machine looks like the homebrewed one... 

2) My own BioShock pinball. The cabling is arguably neater in the BA machine thou.
But in my defense, so was mine once... :)

On the other hand - had I been making an late 70's/early 80's machine I'd be done by now....

Two Bytes

Two bytes were enough to break the WAV-Triggers loading...

When I did the export of the WAV-files I pressed the "Clear metadata"-button in Audacity. It seems this buttonpress added a "no metadata"-flag, or something like that and thus causing the file to not function in the WAV Trigger.

When exporting the file again and simply pressing "Export" the file is 2 bytes smaller and works.

I'm currently toying with the idea of either exporting all files manually or doing a crude batch script to remove the first two bytes of all sound files...

Wednesday, July 29, 2015


I've been busy with my kids and family lately so not much has happened on the machine, I'm afraid. 

I tried the WAV Trigger, which for some reason doesn't play audio. But I'm pretty sure the problem is in the SD card - OSX has a nasty habit of putting a hidden folder on the card whenever a deletion occurs and that probably interfered with the indexing of the WAV-files. I'll have to look into this - once summer ends... :)

Until next time!

Monday, June 1, 2015

Quick update!

Things are moving along!

Had some trouble getting it to run and I looked all over the board for errors... then I realized I'd simply entered the wrong pin order in the sketch... That's what you get when creating a program before the hardware is made. :)

1) The lightboard works and the light update routine has been written! The last row is blank simply because that power line has not yet been connected. Also - a special "bonus" is getting its programming done as well...

The old Mega-board has made its comeback. For some reason the Nano-board has thrown in the towel and the 5V-pin measurs only 2+V. On top of that the serial port does not get recognized by the computer, so I figure it's broken. But I'll drop in the Mega as a replacement rather than purchasing (yet) another board. :)