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... )