Empty tank and all that...

 In case you're seeing this as a subscriber to the blog, sorry - no new update to post, really. 

Another year has passed. 

Almost two, in fact. 

The machine is pretty much alive and we've even played a few games, but other than a new 24V for lights and a few basic game rules and programming, not a lot has happened since COVID-19. I've focused a lot more on my family these days, as having a pandemic in such close proximity kind of split my outlook on life in pre / post-COVID parts. 

And now we're moving to a new apartment, or house - both are being negotiated at the moment. 

My BioShock pinball will naturally come with us. ;) 

Debugging

 Long story short, found and squashed a few bugs.

And ever since I removed a big chunk of volatile array data that I kept to reserve space for gameplay uploads have mostly verified ok, so that's great. 

Just for the lulz (and it's usefulness when writing code from the bed) I created a DMD preview of the machine's internal DMD frame buffer on the serial terminal. It... looks a bit weird. The terminal I'm using to debug doesn't support extended ASCII or 256 colors, so I've had to be a bit creative.

But still pretty dope. :) 
I've also hot keyed flippers and start button, so I can navigate menus (and in theory) play a game as well. Of course, all previous maintenance commands like triggering solenoids, switches and lights etc still work as well. 

1) "Four-color" version. Colors turned out weird when photographing this one. 
The red shade is the same as the one below. The spelling error has since been corrected. ;)

2) Two variants; Top - two brightness values. Bottom - max or nothing. 
Having white/red was confusing so I went with the first four-color version in the end.

I won't put more effort into this, but this can be super handy to avoid having to be connected to the machine to test if game logic and various functions are working correctly. The big upside is that I can use actual code and not "log commands" that output something arbitrary to the terminal.    

Should have learned by now...

 ...to not say that things are going well. 

So I've been having some weird issues lately, problems that I've sometimes been unable to reproduce and they are seemingly random in behavior. I've mistakenly assumed these have been part of the conversion to using "several threads" described earlier.

But this time I noticed that some weird graphical bugs creeped in and since that code "cannot" do anything wrong (it basically sets a number on or off in a fixed array), I figured it must be a disk/flash issue since the letters are hardcoded . 

1) The M is consistently erroneous despite working fine the upload before etc.  

Then I realized, I hadn't enabled "Verify flash after upload" .. and, yeah. This. 

2) Verification always fails at the same adress on the installed Chipkit. 

Note that the flash is completed, so the machine boots and is playable. But it appears that whatever ends up in that space (this time it was the letter 'M') gets corrupted and could cause issues.

I've been uploading to the Chipkit a lot over the years, so it's not unlikely that the flash has finally failed. I also tested to do an upload and verify against a spare Chipkit MAX32 that I have, and that verified just fine.

I might try to keep uploading and trouble shoot on the broken (?) Chipkit until it completely breaks rather than swapping it now, since I'm working on isolated code segments at the moment.  

Update: 

The verification sometimes do succeed.  Obviously I won't leave things to chance later on, but for development of game scenes and thing that are "fixed" in scope - I can manage. 

Setting myself up for success!

Still tweaking and improving on the general flow and function on the machine. 

I found out that I could have one more interrupt "loop" attached beside the one I've been using for, well, mostly everything - so I've migrated to using two separate loops for display and switches etc. 

Doing solenoid and switch updates at 1400+ Hz turned out to be a bit overkill, so by separating screen refresh from that loop I could increase frame rate while still keeping a solid 200 Hz refresh rate on solenoids and switches. This is more than enough to dim/fade lights and from what I can tell, I haven't been able to *not* register a switch hit.   

The downside is that code is somewhat more complex (servos in particular has proven a bit challenging, since I obviously struck gold with my magic numbers the first time...) but I'm getting there. Getting all time & counter values updated took a while too, but now I got TIME_1MS variables to use that are exact and not "40 loops", which can be whatever... So it's all good. 

Basic gameloop as in start game, play game, end game, award match or highscore etc is in place. Not "final" but in place. And that's quite a relief - and this also means that for the first time in YEARS I've actually progressed further than I've ever been. *optimistic fanfare* 

1) Highscore is in place, both reading and writing to EEPROM - and of course, earning them in-game.
The eagle eyed might notice a slight ghosting. This is due to insufficient wait time during display-enable/disable cycle, but I'll get that fixed soon enough. I might even revisit the DMD rendering routine eventually to see if it's the most optimal version. I'm not terribly sure the timing is 100% when reading the documentation for the display, but it can't be far off either.   

2) Various stats are being recorded and available to view in the audit menu. Beyond being interesting I plan to use the data to decide if a feature is too easy or too hard, balls drain to fast etc. 

 

Luckily the audit stats are getting reset eventually, since ball times aren't exacty... spectacular... during testing... :) 

I've also added a lot of settings that can be tweaked, including ball save time, lamp brightness, coil power, hold start to launch ball,number of hits required for this and that. Each setting comes with a type of setting that is rendered differently such as slider ("volume bar"), cycle values, on/off, yes/no and so on. I've also added the possibility to disable certain features of the game, for instance - if the drill-arm breaks it can be disabled so the game won't try to run it etc. I'm trying to plan ahead and add as many settings I can (and since it's simple to do - why not) that allows for greater flexibility when designing the game. It would be great if some years down the road the machine won't be completely inoperable in case of mechanical failure of some part. Most professionally constructed machines compensate for broken switches and machinery, so I'm trying to be at least on par. 

But...

I'm at 62% flash usage already. 
Hopefully actual game rules won't have to be just random points and sound, hehe.

I'm not expecting and issues really, since most of the heavy lifting is done with all the various classes, mainframe and scene management. Game logic is relatively simple, after all, and worst comes to worst - I could probably offload all maintenance names and text to EEPROM and stream in when required. It should free up a few KB of valuable space, at least, and if necessary I could also squeeze out a few more KB by using binary values for letters and numbers instead of having a byte per pixel. That means I won't be able to use per pixel colors, but I'll cross that bridge if I ever get there. 

All in all, code is shaping up pretty nicely! 

Down for maintenance...

 ...is something you might say during maintenance. :P 

Almost got all parts of the maintenance modes down by now.
Naturally, I will have to keep coming back to update certain features as the game programming goes on, but I feel most of the menues and how everything works feels pretty good. 

1) This menu will be super handy if something doesn't work as expected! Here, we see that the watchdog is disabled (due to open coindoor), and that in turn disable power and solenoid+flash MCP's. I'm thinking of enabling a "secret" debug menu that adds this screen and others as overlays during gameplay too.

One of these days I'll update with a video, hehe. 

Here Be There Pixels...

 Been working a bit on the maintenance menues and the part from boot to attract mode lately. 

Not complete, but feels pretty good so far and having a proper maintenance mode is crucial. Before coding the first one (a few years ago) I thought that perhaps I wouldn't need it for a home pinball... But boy, has it helped. So I'm spending some extra "bucks" getting the newest iteration up to par with a commercial machine incl trough test, standard and feature adjustments etc. 

Behold the "slightly washed out due to sun reflections"-images below!

The icons above are created by first designing them in Pixel Art Studio (free version) and then converting to regular C arrays using Google Sheets. 

It's a few extra steps, but since there won't be a lot of them it goes really fast to "trace" them manually. Took about an hour to get the 19 icons I have converted to C. 

The good thing about Pixel Art Studio is that I get the exact pixel coordinate for each pixel, so I can do mockups of entire scenes and get the layout exactly right when recreated using various draw calls and texts. 

Good times! 

(Oh, and I broke my start button. So I need to fix it/order a new one... )

Achilles, Agony and Ecstasy In Eight Parts

So, I decided to fix the power rails. 

First I removed the old fuses.... 

 

...built a board to host all three PSU's. 

Yes, three. The scratches on the 12V line is me severing that line to allow me to use a 24V PSU instead of 12V. This line also provided power to the Chipkit, so Chipkit got its own jack now too. Real pinball machines strobe their light matrix with 18V, so 24V should provide more vibrant lights and flashers. 

Black is the new ...black, baby! 

Prepared the little power circuit.... 

And removed / accidentally messed the traces when removing a capacitor (more about that later)...

....but finally got everything in place! 

Nice! Looking almost as if was part of the plan. 

The board lights up! 

But, did it work? 

Of course not. 

It's infuriating and fascinating how something can be tested and tested again, and work perfectly in a controlled environment - and yet fail miserably in the real world. Even when loosing my cool and removing a few of the caps (and doing a hack-job at it too....) it wouldn't work. 

So here's Mr Cable once again. At least it's before the fuse this time, although I'm not sure that'll help. 

The big downside is that I cannot start the PSU after I've inserted the USB-cable, so I have to power up the machine/board - then - plug in the USB-cable, or only use the USB-cable. 

To be fair, it does work without the extra cable - eventually. After a few attempts and the power has stabilized it's possible to re-init the IC's that fail and they'll work. But it's highly unreliable and even when removing the 5V fuse, the LED still lights up, so power is sourced from somewhere. I don't really know where the power creeping is coming from - it feels unsettling to leave it without the extra cable.

 Anyhow, win some, lose some. Story of this build. :)