Mostly Behind The Scenes

What is up, Internet!?

Most of the work at the moment isn't very visually interesting, but I'd thought I'd share a little snapshot of the current (messy) state of the debug screen. What I'm verifying here is that the various conversion and positioning functions are functioning properly. Which they are.

On top of this, I've fleshed out the switch callback handling, which includes buffered and queued switch hits. This allows the best of both worlds; the interrupt routine can register switch hits as fast as it can detect ( 1000+ > Hz per switch) while the game loop is chugging along at 40Hz. So no switch hits are missed, and the response for each hit is a maximum of 25ms late. Certain switches such as flippers, slingshots and bumpers are allowed to trigger the corresponding solenoid immediately and allow the sound and gameplay events to happen "later". It might be possible to queue sounds right away since the serial out is asynchronous, but I have yet to test this. What ever decision is made has to manage up to 8 simultaneous switch presses so each response must be pretty tight. I don't want the machine to run fine during single ball and crash during multiball etc. :)

I've enabled printing a copy of the internal switch matrix and the current animations, lights and so on in the console maintenance mode, which is guaranteed to be correct at all times unlike an offline version in Excel, for instance. On top of that I have started work on the state machine for modes and various scenes, so things are progressing nicely, albeit slowly!

1) Development board with debug options enabled on the DMD. I've also created a "overflow" function for scores,
so that any score larger than 999 999 999 will be visually divided by 1000 and rendered correctly. I believe this is how newer tables by Stern work, unless I'm mistaken.

Terminal Madness!

I decided it was time for a proper maintenance terminal function, so I coded up a rather crude but functional terminal maintenance function.

It goes hand in hand with logging boot status and game state changes etc, and will allow for _much_ speedier creation of game rules without actually pressing switches. Commands can also be chained, so I can easily create a sequence of actions to be simulated to properly activate features and modes instead of faking it by turning a specific mode flag on etc. This prevents me from mistakenly forgetting to reset something that might break the game - very handy! 

 

1) UECIDE (how's the new name going, Majenko? ;) ) with a terminal active. Me gusto. 

Now, if only there was a smart and efficient way of handling game code from EEPROM or SD-card. That would be excellent since a re-flash both take a long time and waste a full erase cycle on the Chipkit (a process that eventually will break the board).

It should be relatively easy to achieve, but it must be robust and extensible.

Weirdness and wetness!

Spent some more time with the code and got dual animations on a single SD-card up and running!
It's an unlimited number really, but limited to two for performance. The theory is simple, since I'm not using a file system I simply load raw sectors and can grab any frame at will.

For simplicity and synchronicity's sake, I've decided to load SD-card animations with a blocking approach (as opposed to interrupt driven). This greatly simplifies things as I can keep the main loop/scene rendering to a single function instead of spreading out across several frames and wait for various inputs to complete etc. Since switch inputs and all I/O in general is moved outside the main loop, it doesn't matter really. I've locked the main loop to 40Hz which should be plenty for updating animated text, verifying animations and other non critical reasons. 

1) Basic render "geometry" examples with background animation, textlayer and front animation (layered above the text-layer).
The lower left are status flags for SD card, MCP, ULN etc. All 8 should be lit for a 100% functional machine.

The extra FX-layer really spice up the DMD, since I can overlay smoke, sparks and what not at will. I could also use two background layers, or two front etc.

I've also found a way to successfully detect if ULN and MCPs are functioning correctly, and can alert and disable features accordingly. I've completely lacked this troubleshooting feature previously, so this is a major leap forward.

I've also had the "joy" of realizing that the flash-burning sometimes fails, and that verification fails. It has been like that for a while, and I never knew why and it has "always" worked. But this weekend some simple code started to fail seemingly randomly and it basically boiled down to 'if verification fails, the upload isn't correct' after all. Usually a reboot or reselecting the toolkit in UECIDE allow me to upload successfully. As long as I know about the issue I can work around it. It wasn't exactly a straight path trouble shooting it though, since I both suspected that the DMD was broken. I took a rewrite of the routine in a new sketch to see that it was indeed working correctly. A new screen is _not_ something I want to buy at this stage...

But on the plus side the 13h+ troubleshooting made me rewrite SD card and DMD rendering routines, further optimizing them and avoiding unnecessary variable writes and operations. The downside is tough-to-read code, but once in place they won't change often (at all?).

So - three steps forward, one temporary step back.

ULN2803A!

1) Fully populated board with everything up and running. Since this is my first circuit board ever made
and my first venture into advanced electronics, I'm very proud to see it functioning properly!

Yes!
It was a broken ULN2803A that was the problem with the light matrix.
Very satisfied with that little bit of knowledge, as this now means that all parts of the hardware has been checked and verified. Now it's simply a matter of fine-tuning everything and create, solder and connect the final cabling.

Exiting times to say the least! :D 

DJ SD is in the house!

...SD card loading is in! 

The graphics library is still in its infancy, so there's no shadows etc. But all-in-all I'm pleased with the results!

1) DMD with SD-card loading (and displaying) demonstrated. The 16 shades shows the possibilities pretty good here,
with a dark big text in the background, several layers of graphics etc. Once shadows are in place it will be killer!

We shall rebuild!

Getting closer...
I've been struggling getting the light matrix to run properly, since all rows are for some reason active at the same time. I'm thinking the ULN2803a is broken, so I've ordered a replacement. The ULN activates by pulling the row TIP107's to ground, which seems likely in case of a short circuit or similar. We shall see. 

On the other hand - input and output are all up and running and running "very often". I haven't crunched the actual numbers, but it should be in the 500-600Hz range at least. The graphics are a rock solid 60hz (or so, there's no noticeable blinking which would suggesting a minimum of 50hz ) and it doesn't matter if the drawbuffer takes 1 second to create itself, it won't affect solenoids, switches or graphics etc. This means I can most likely use several layers of DMD animations, for instance, one background and one foreground. Should be pretty wicked!

1) Here's a snapshot of my Enterprise Commercial Grade Ultra Deluxe Setup 2000. Still, the various shades
does make a huge impact on the graphics. Looking forward to getting SD card animations up and running!

I'm quite satisfied that there's absolutely no delay anywhere in the code. When the DMD is crunching bits into its registers, the MCU is processing switches/lights etc. The result is a nice double buffered screen in 16 shades and super responsive inputs/outputs. The setup even allows for "autonomous" triggering of slingshot, bumpers and flippers with microsecond delays instead of 15-20 ms previously.

Overall I'm very pleased with the progress thus far!

Turtles....

...are faster than me.

But at least they're not doing a million things at once. Or building pinball machines. :)

Since last I've had some issues with the MCP23S17's, and they didn't want to function properly. I think I got the hang of them now though. There were a couple of issues, for instance;

1) One of the MCP's relied on the Max32 to send an enable signal to it, but it seems the pin can't supply the necessary voltage and/or amperage needed to keep it enabled. I temporarily jumpered it to 3.3V and that solved that. I will probably solder this to the watchdog output instead, since that and the other two MCP's relying on it seem to function properly.

2) The switch matrix MCP displayed the status incorrectly on the DMD. I'm still using a temporary DMD "library" that lets me dot pixels for basic trouble shooting. I forgot to add the clear buffer function, so every draw could only add to the screen and not remove. This fooled me to think that the built in pullups malfunctioned and/or the software for it. I've verified functionality with a LED instead and everything works as intended, and has most likely always done so.

3) I've moved away from all fancy MCP-libraries and communicate directly via SPI, and that probably helped a lot in knowing exactly what's going on. Will encapsulate this into functions optimized for the "thread" handling I've planned for them.

Lastly, I've, err, confirmed that the fuses function properly.
While testing the inputs I did something very wrong (i.e voodoo connecting things) and blew the 5V fuse. It's rated at 3.25A so that's a pretty decent amount of current that was blocked instead of frying other components. 

But at least things are moving forward! :)