And this is how the game sits today.
IMG_20211015_073216384 (resized).jpg

I picked up some cabinet guards from PBL to protect the interior paint as I dropped in the playfield, and indeed they worked well for their purpose. I didn't fasten down the apron or shooter gauge, but I laid them in place to check the color scheme and it seems to come together nicely. The playfield slide rail hardware had been tumble polished, but what really gave it smooth action was a thin layer of grease. No more horrible screech as I pull the playfield forward for service!

At this point, I will be giving the project a rest for a few weeks. Besides needing to do some cleaning (as probably evidenced by the photos), there's only three weeks left until Midwest Gaming Classic. VB wouldn't have been ready in time for it, but I have another popular homebrew project that needs some love and maintenance before it hits the show.

So expect a necro of the Undertale thread soon!

The last few days, I took a mighty plunge and soldered a lot of through-hole joints. A LOT.
IMG_20211127_195153144 (resized).jpg

With card table space finally cleared up, I arranged everything approximately as it will appear on the playfield. Admittedly I'm expecting a bit more wiring than I'd initially hoped with this PCB arrangement, but in general I don't think it's going to be too messy-looking.
IMG_20211127_210717875 (resized).jpg

Whether I get the playfield pulled out tonight and the boards mounted is uncertain. Left a piece of padding sitting in front of the game and my fluffy baby melted on top of it. Removal of playfield would disturb his beauty sleep.
IMG_20211127_205840177 (resized).jpg

PCB modules now installed on the game. Well, all but two of them.
IMG_20211128_144801819 (resized).jpg

That would be because some idiot decided to assemble the two single-RGB boards with the header pins facing the wrong direction.

The rest of last night was spent on a spreadsheet of devices and connections, making sure everything on the playfield was accounted for and listing every wire connection that must be made. It took quite a while but will be very worth it, both for assembly and for addressing in software.

One pop bumper switch had to be moved, due to a positioning conflict with a lamp+driver board. I'm glad I waited to wire everything up, because this could've been hard to move depending on how I may have chosen to route the wires.

IMG_20211128_141321955 (resized).jpg

Remember the lit playfield photo? It was made by hanging thin wire from lamp sockets just to see how things would look.
Not this time.
IMG_20211205_195550864 (resized).jpg

This is after soldering down what I hope to be the final lamp wiring. Seven of the eight lamp drivers are used on each of the lower two flipper controller boards, and now the lamp wiring for both of them is done. Well, except the GI socket that illuminates the Hot Springs sign, and the trough light. But at least there are hanging connectors for when those components are added/wired.
IMG_20211205_195839284 (resized).jpg

I actually had a bit of an oversight when I was doing the left side, and included a bit of extra GI sockets in what was originally intended to be a very short string. But I'm considering this to be one of those mistakes that's good in the end, because it's still a reasonable number of sockets and it actually frees up a lamp driver so I can move the orange flasher (by left scoop) to a more sensible driver board.

Most of the wiring could be done from a normal seated position. Clarky-boy liked that.
IMG_20211205_151955751 (resized).jpg

Playfield lighting and communication channels are nearly all wired up, with the exception of jets, flashers, and four lamp boards for which I didn't have enough connector housings. Order is on the way.
IMG_20211212_205633813 (resized).jpg

I think I will run wires towards the bumpers but leave them hanging for now. Bumper lamp sockets are not fun to deal with, so it would save me frustration to just leave them disconnected until the final playfield assembly is underway. Flashers don't need to be wired immediately - especially since the sockets are not yet mounted topside - but I will leave some Molex connectors hanging near their future access holes so they can be easily plugged in once installed.

Somebody photobombed me at bottom left!
IMG_20211212_205658254 (resized).jpg

A few zip ties have been left loose so I can finish up those missing connectors. Once that's all tightened down, I can start on the second wiring harness: switches and solenoids. Given that the switches can't be placed neatly on circuit boards like the lights, I expect this part of the wiring to be a bit less smooth of a process.

Thanks!
Yes, there are a couple of subway branches. In the top right (top left in the wiring photo, of course), there is a skill shot drop hole in the outer orbit. The center ramp has a lifting mech, and shooting the ball under the ramp lands it in the second branch of that same subway, with the ball ending up in the volcano from either shot. From there, it can either be fired upwards to "erupt" via the VUK, or that repurposed kickback mech pushes it out of the VUK and into the volcano tunnel scoop (also hittable from the playfield, to the right of the ramp), where it makes its way down the longer bent subway and eventually emerges from the left scoop. This sets you up with an upper left flipper shot either into the hallway (eventually reaching the VUK at the far back of the playfield) or into the hot spring, which is the long-ish scoop you can see at the left side of the photo, that sort of subways into a VUK that feeds a ramp back down to the right flipper.

....man, there's a lot going on here.

BACKGLASS.
IMG_20220212_022329348 (resized).jpg

Not so quick process getting this one. I finished up the art for this months ago - last modified date on the final art file is September 25. Sent it to the local sign shop with instructions on how to do the somewhat unusual layering (includes a black masking layer to improve contrast). I said it wasn't a huge priority to finish up right now, because I was busy getting ready for MGC anyway. So it got a little delayed.

Okay, maybe a lot delayed. December 9th I finally gave them a call and was told it would be another couple weeks. January 5th....almost done. Two days later, their printing guy called me up. The vinyl backing sticker was done. Just one problem. The sheet of glass I'd brought in from the local glass shop was the wrong size!

Fortunately, it was in its original packaging, with the original receipt (giving the correct dimensions), and the glass shop made it right free of charge. But since it's tempered glass - special order only - it was another few weeks before I finally got it in.

...Fast forward to last Friday, and at long last, Volcano Blast has its backglass. Trim went on with some very careful rubber mallet taps, aside from the top piece which decided to crack into pieces. At least I had enough left over, from trimming the sides to fit, to cover the corners and center, which is really all I needed to protect the top edge effectively anyway.

Thus completes this game's backbox, more or less 100%. I might swap out the speaker panel screws with black ones to camouflage them.

Nearly two months now with NO updates! What could possibly be my excuse this time?
Well, I mean... I bought a house...
IMG_20220407_133642942 (resized).jpg

Some of you may recognize this from the game room thread, but quick summary of the story behind it. My grandfather moved into a home a few months ago and had to sell his house to pay for it, which sucks horribly. What sucks worse is it's the house he built from the ground up in the 50s for both his family and his photography business. On top of that, my mother was tasked with putting her childhood home on the market and was entirely heartbroken about it. After stewing over the situation for only a few days, I derailed the entire plan by selling my own (old and honestly quite poorly laid out) house, and buying Grandpa's instead.

The room pictured was the main photoshoot area at one point, then converted to a computer room at some point during the System 11 era. Half of it will remain a computer room - although with a fair amount of counter space kept free for board work - and the other half will be my private arcade. Yes, the windows will be blocked eventually. Still quite a big mess of unsorted personal belongings in the way, but once that's all said and done, I'll be able to get working on VB once again. The house also came with a workshop area and a very nice selection of shop tools (drill press, table saw, vices, bandsaw...) so I think that will be a big improvement on both homebrew and restoration work in the future.

Settled in decently well for right now, enough that I can at least prioritize doing VB work when I have free time. I love the new game room, there's enough floor space to set up sawhorses as a poor-man's rotisserie, allowing space to walk around it while also blocking access to two perfectly good games!
IMG_20220530_161949504 (resized).jpg

So, I've been working on the wiring, which has been waiting since before I moved out of my old house, and definitely not because I've been procrastinating at all, no sir. Fortunately, with everything planned out in advance, coils were super easy to do wire routing, and switches are going to be up next. Not all coils are done yet - still need to finish up power/ground and build a couple of assemblies to drive the diverters - but that stage is nearly done.

As far as the coils I'm using, I had a ton of them sitting around - but, being sourced mainly from System 11 games, most of them were 23-800. Which is fine for a few applications, such as the autofire and the volcano VUK (easily the deepest VUK on the game), but why put extra processing into doing high voltage PWM when you could just install the correct coils in the first place? Anyway, I wanted to build some mechs with fresh new/restored parts, so I used that as an excuse.

Ew:
IMG_20220627_205949620 (resized).jpg

Since the new arcade/workshop has that countertop, I cleared off a bit of space and set to work, with new coils from PBL and some nicely tumble-polished brackets and hardware.
IMG_20220627_210254497 (resized).jpg

And voila, two fresh new slingshot coil mechs, built to Williams WPC specification.
IMG_20220627_211728742 (resized).jpg

As long as I was at it, I rummaged through the organizer and found that I had enough restored parts to build a new outhole kicker. Since the one currently sitting on the whitewood is pulled directly from a parts playfield, tarnished and full of dirt, this will be a nice and quick replacement once I turn the playfield back over to add Molex plugs to the few topside coils.
IMG_20220627_221908584 (resized).jpg

Solenoids are wired up!
IMG_20220703_224806249 (resized).jpg

Well, aside from the ramp diverters and outhole kicker, which are mounted topside, but at least they only need plugs. I definitely didn't waste any zip ties by tightening them too early or bypassing them with wires, no siree! Yes, flipper mechs are a little ugly and EOS switches not quite mounted right... oh yeah and drywall screws holding the return springs... yes, this is all temporary.

The only playfield wiring remaining is switches, then I expect to be able to properly play this whitewood. There aren't any holes cut for rollovers, so I'll just mount those switches near-ish and call it good until it's time to swap over to the real playfield. Also waiting on two magnetic reed switches from @Sonic, which will cover the two lock positions in the volcano subway.

The standard lower third is now fully wired up!
IMG_20220710_204006698 (resized).jpg

I had a bunch of colored zip ties I got for cheap, so I mixed it up a little. Wire colors are kept pretty consistent throughout:
Red- 5V supply
Orn- GPIO to switches
Yel- 12V supply
Grn- Switch ground
Blu- 48V supply
Vio- Board communications
Brn- Speakers
Blk- Drivers to solenoids (and common grounds because I couldn't find thick enough green wire for those)
Wht- Drivers to lamps/flashers
IMG_20220710_204024196 (resized).jpg

Future wiring will probably come from Wire-Bot, but I stocked up on all this before rockwell opened up shop, I think!

Plenty more switches to go, but this covers the most important ones of all. I'll need to do some cabinet wiring before I can properly flip this, but so far everything is going together pretty solidly.
IMG_20220710_203934901 (resized).jpg

Second draft of the light novel is coming along as well!

Milestone reached: Under-playfield wiring is completed at last!

Well, in theory, anyway. Knowing my history, it's entirely possible I will have messed something up or otherwise need to make changes to this. But everything is solid, wired up according to multiple guides I made up, and it matches all the electrical elements that I've tested on breadboards.

Up next is some cabinet wiring to finish up, then I'm hoping I will be able to drop the playfield in and play this thing at long last.
IMG_20220717_232440212 (resized).jpg

That's exactly what I dealt with on my first build. Had a massive rat's nest of wiring, full of EMI issues, and ended up chopping everything out and redoing it system11-style in time for its first show. I'm hoping my planning has been good enough that I don't have to deal with that situation again!

GUYS. I DID IT.

Getting this to work was... interesting. How, you may ask?

So, the wiring went pretty decently. It's not totally done (still need proper line input rather than an extension cord running through the hole that the power button will go through, etc), but I have the voltages I need. 5v for logic, 12v for opto switches, and 48v for flipper coils. I finished(-ish) that job Sunday night, and immediately wrote up some basic firmware to at least let me test out the new flippers. Tried to burn it to an ATMega328P... communication failure.

Why on earth would I get this problem when I had one working great last year? What changed between then and now? I spent a huge chunk of time last night messing with it, trying to figure out what I was missing or what was not connected or configured properly. It was about 10:40 PM when I finally realized the problem. The clock speed fuses weren't set, so the unconfigured chips were running too slow to keep up with the USBTinyISP programmer.

I'll have to dig through the notes and remember how to set the fuses, but I did find the one chip I'd previously messed with that already had the fuses set, so I programmed it with my quick Fliptronics firmware and dropped it into one of my driver boards. Took a deep breath, fired up the power supplies, and pressed the flipper button.

Nothing.

Also tried triggering the slingshot, also covered in firmware. Also nothing.

I didn't know what it would take to fix. I figured tonight I'd have to open it up again and diagnose my wiring. Check the low hanging fruit first, like make sure it's getting the 5V and ground.

And then I got out of the shower, thinking about it, and I realized I had missed the lowest-hanging fruit of all. I was trying to test it with the coin door open. You know, the door with the high voltage safety interlock.

So anyway, that video is the first proper test of a Fliptronic-style controller in custom firmware, on a custom flipper driver board that happens to be the first complete KiCad design I ever made. I'm happy now. You can also see some lit GI (driver controlled), as well as the reflection of the fully lit backglass logo. Backbox is considered done at this point.

Okay, WHERE does the time go, like WOW.

Guess I was busy doing other things around the house, although I'll admit procrastination was also involved. And scouring the workshop for one single component with which to test a theory, and only today remembering where it was.

Perhaps an explanation is warranted. That video was very satisfying to record and post and show off. And then I tried it again when I arrived home from work, and promptly had the board lock up after a couple of solenoid pulses. Same problem on the left side, random resets and lockups. I wondered if memory corruption was happening, but was directed back to plain old lockups when I set an LED to blink continuously for diagnostic purposes.

It must be so painful to watch someone teach themselves electronic engineering...

Anyway, this disgusted me quite a bit, after all the time I spent planning out wiring, grounding, and routing, and I did a number of online searches trying to dig up the reason why a microcontroller with a wide voltage tolerance would be so unreliable in the game. As it turns out, that wide voltage tolerance only matters when choosing what to steadily run it at. Tiny dips or spikes, like you get when you suddenly burden your power supply with a coil firing, will still cause it to reset or lock up.

So, just in case anybody else is designing a board with a microcontroller, these are the steps leading up to the final fix:
- Set all unused GPIO pins to output, but keep them turned off.
- Add a 10K resistor between 5V and the reset pin.
- Add a 0.1uF ceramic cap between VCC and GND (and I should do the same with AVCC but haven't yet).

The extra components I threw onto the back of the board since it was the only way to make them fit.
IMG_20220826_211842873 (resized).jpg

But it WORKED. Honestly, I was amazed, but I should have known because all the guides tell you to do it. I guess I was just used to testing on the bench without it and having it work fine. Of these three things, the ceramic cap was absolutely the main thing that fixed it, though the other two probably helped. DO NOT DESIGN A BOARD WITHOUT THESE COMPONENTS. I will remember this in the future.

Anyway, time for another hiatus. The component I had to dig for was the ceramic cap, as I apparently have only one of them in the house. Mouser order incoming for those and the resistors, a very commonly needed rating, of which I also have only a tiny supply.

Zener diode trick is interesting, I may need to incorporate that into my next design. (Since I'm really that unhinged.)

The resistor pulls the reset line up to 5V. Although the chip generally works as intended when sitting on the bench, having the reset pin floating means it could end up getting tripped unintentionally. I don't know if this specifically helped my issue or not, but all the AVR help sites recommended doing it.

Thank you! It's been a long journey, with a lot I haven't done before (despite this being my second build), but I think we're finally starting to reach the tipping point where things are going to come together pretty quickly.

Couldn't do board work last night as I'm not expecting the new caps until Wednesday, but I spent the evening on firmware, both for the individual controller boards (I'm calling them satellites) and for the main hub controller powered by the Teensy LC. Downstream communication is perfected, now I just have to solve an issue with switches and I can write up the final firmware routines.

From there, all control goes to the central computer!

For today's update, be prepared for a bombardment of tech details!

Some bits of the code from Undertale can be reused, especially the light sequencing routines, but much of the playfield interface code has to be rewritten for the new system. I can't really complain about this, because the new way is actually quite a bit simpler, at least in the PC framework.

In the old control system, a varying number of bytes would be sent down to the two Teensy controllers. The controllers received bytes in pairs, with the first pair being the number of the device to control, and the second toggling it on or off. To retrieve switch states, the computer sent down a blank data pair, which the downstream controller took as a request for switches and sent that data back up.

The new control system simplifies that a whole bunch. The USB interface code is designed to send 64 bytes of data at a time, so the computer just does that on every 60fps frame. Addressing? Nah. The byte order expected for all the peripheral devices is already known from the start. I just send down four bytes of data for each satellite board, thus 32 on/off bits for each playfield module. The Teensy hub controller sends data out to each module all in parallel at once, one bit at a time, then receives data back from them in the same way.

The boards use this data to turn devices on or off, with some of them programmed to look for other later bits and use them for dimming/PWM. I haven't specifically mapped out the bit arrangements for each satellite yet, but the functionality is there. As a board receives lamp/solenoid output data, it sends back switch states. The hub controller collects all reported switch states, but the computer doesn't get told about them quite in real time. The Teensy incorporates a one-frame data buffer (thus, computer gets switch data closer to 30 refreshes per second than 60), and uses this for error checking. A switch only gets reported as closed if the playfield module reports it that way twice in a row. This way, if EMI or connection issues cause a single clock cycle to mess up, it won't result in a phantom switch closure. This isn't so much of an issue for output devices, as accidentally turning on a bulb or coil for only 1/60 of a second would barely be noticed.

Yes, most of this is already implemented and being tested, so far with very promising results.

Perhaps you may wonder about safety features. What if the computer, or the Teensy hub, locks up while a coil is active? Well, there are two layers of safeguards going on in the communication system. The Teensy checks constantly for data from the computer, and assumes it will get a consistent stream of bytes even if nothing is changing on the playfield. If it doesn't see anything for 50+ms, it zeroes out the entire output array, which kills all lights and coils as soon as downstream communication finishes. A similar version of this same design is in force on the ATMega firmware on the playfield modules themselves, performing the same task on a lower level if the Teensy locks up and stops communicating downstream to them.

The ATMega chips locking up would pose a problem, but adding a few caps to the module boards seems to be solving all the reliability issues I had with them. Another order is on the way, as I've decided to add larger electrolytic caps on their main power inputs. When I hooked up the two left flippers, I had new lockup issues caused specifically by the power dip from operating two flipper coils at once, and adding a new cap to the driver board and a larger new cap to the main supply fixed those problems. If chip lockups do prove to be a problem in actual testing, I have a solution ready - there is one more free pin on the Teensy LC, and I could use that pin to drive a relay to cut 5V logic power entirely, which would force all the module boards to reboot. If this happened during a game, the lights would flicker off for a second, then everything would go back to normal. Because playfield state is constantly refreshed, players would barely notice.

Guys... we're finally making some progress. VIDEO BELOW.
First, a picture: The game with the lights on, except these lights are directly controlled by the computer.
IMG_20220924_222925960 (resized).jpg

Now for this video... after numerous issues with configuration and communication, I was finally able to bring everything together enough to get some very basic gameplay. Flippers, slingshots, and bumpers work (might need to double check an issue with the top two jets though), but most importantly of all... the volcano can erupt!
(Gonna have to turn down the power on that left eject solenoid, though!)
Super quick video:

There's always some new issue to find and fix. Some light indexes didn't match up. Single-clock-pulse communication errors caused lights to flicker and coils to fire every once in a while. One type of lamp controller in particular didn't work.

But they're all fixed.
IMG_20220928_200923888 (resized).jpg

Updating light index numbers is really no problem; I set up a debug utility in the game framework that lets me step through each light individually and turn it on or off. If the name of the light doesn't match the bulb that actually comes on, I just make a note of it and move on, coming back later to correct the lamp names in the code.

Communication errors were something I was half-expecting to see, and before the game was ever fired up, I created a one-way error checking system managed by the central controller. Switches only report as closed if the hub controller receives them in a closed state twice in a row. This way, if clock or data messes up for one brief moment due to interference, its effect will be ignored by the computer, because it will be corrected before the data arrives. I never had any issues with switches. However, once I started testing lights, it became clear that these errors did exist, as lights would occasionally flicker off as other lights (and even coils, depending on IO index) would flicker on. To fix this, I added a downstream version of the same error correction system. Now, lamps and coils work the same way, where they will not change state until they receive at least two same IO bits in a row. Loss of communication from hub or computer results in all devices immediately being turned off.

I did have one board appear to lock up, the upper right aux solenoid driver. It didn't lock on any coils, but it did seem to quit responding. I may give it another chance in testing, but I will very likely be implementing the safety reset on the 5V line, as this would solve the issue before anyone would notice it happening.

Finally, the lamp controller that couldn't. The central mode lights weren't working at all, along with the ramp and target bank lights. I had a couple of theories about this issue, but what confirmed it for sure was when I realized none of the associated switches worked either. The problem was that somewhere in the controller wiring plans, I documented the data in/out ports backwards, and thus programmed the chips to listen appropriately. After reprogramming with the pin numbers corrected, the rest of the lights worked as intended.

The blue flasher doesn't seem to work, although it just occurred to me in my head that the bulb could be missing, as I was running short on flasher bulbs last I checked. Regardless, next order of business will be switches. Most of them seem to register, but I will have to go through each one and make sure they're indexed properly (like the lights) as well as just making sure they work as intended. I had a flickering display issue fixed by switching to single-buffer rendering, as well.

Then I gotta figure out sound. The Allegro sound library fails to initialize on this system for some reason, and even if that worked, tapping the ATX 12V for amp power continues to be a bad idea as it produces a ton of unpleasant noise while the PC is running. Despite the issues, I've made a ton of progress in the last few days and am feeling decently satisfied.

Cool, glad to help motivate! Sometimes I need a bit of that, too, but fortunately it's been going pretty well lately. I will probably think about a video decently soon, now that it's getting a bit more flippable.

Tonight I got most of the switch indexes corrected. I'm not totally sure how so many devices had their wiring order messed up, but a quick software correction fixes it, so it's not that big a deal really. At this point, I just have two switches not working (shooter lane and hot spring VUK) and one light (blue flasher). I still need to do the cabinet switch wiring for the front buttons, coin slots, operator buttons, and tilt, but for quick testing purposes that's not as important.

Shooter lane feeder mech was getting a little gummed up, as I pulled it directly from one of the parts playfields without any cleanup beforehand. Since it got to the point of not even returning to its base position, I figured it was time to pull it and build up a new one. One of these days I'll have to fire up the tumbler again, as I've replenished the stock of old mechs since I last used it.
IMG_20220929_194730931_HDR (resized).jpg

Been a while. Busy with a lot of things. House stuff, work stuff, and also trying to also trying to get the second draft of the story done. However, I did make some important progress on the game. Hmm, where should I "START" with this?

IMG_20221113_144334332 (resized).jpg

Cabinet wiring is mostly done. There are a couple more things to finish up on it. One is audio power. Had a lot of trouble with this after the rework on Undertale, where the amp was for whatever reason heating up super hot (even at idle) when powered by the PC power supply. For some reason, I thought I would have different luck here. Granted, this amp wasn't overheating - made me think it was going to be fine. Unfortunately, when I reached the point of setting up the computer and putting that irregular load on the PSU, things got very noisy. Amazingly, I had the foresight to put the audio amp on its own dedicated Molex connector to the PSU. Fixing the issue can be done as easily as mounting a new 12V 3A supply, and plugging it right into a short power harness that's all set up to go already.

IMG_20221113_144220501 (resized).jpg

The amp sits in the background, with the tilt bob nearby. I ended up not having space for the tilt in the usual spot (more on that later) so I mounted it on the right instead. Just needs a plumb bob to be truly complete. The cable management keeps the wiring out of the way of the swinging pendulum. Everything is nice and modular and installed on plugs down here. Cabinet buttons are solidly soldered to their cables, then each one has a single Mini-Fit connector for super easy removal if necessary.

IMG_20221113_144302019 (resized).jpg

The other side is a slight bit of a mess still, but will be tidied up once the coin door wiring is totally done. The coin switches on my decent-but-slightly-incomplete door don't seem to be working, based on a meter check, so I decided to hold off on finishing the wiring until I have switches that work. The door is also missing the slam switch and any valid place to mount the operator menu buttons. So I just installed those buttons on the front cabinet wall instead. I discovered that the cabinet is bowed slightly inwards on the left, so the piece of angle iron bolted to the left side is to help straighten it. Ahh, the things you find after you've finished the paint job. Even with the correction, there will be perpetual damage to the interior paint from raising the playfield.

Aside from the flipper switches - which get wired back up to the three flipper drivers on the playfield - everything in the cabinet is controlled by the final aux solenoid driver board. There is one playfield solenoid (left diverter) that it controls, and the four remaining drivers are used for the Start and Extra Ball button lights, the knocker, and the shaker motor. The shaker doesn't seem to work yet, not sure why, will have to investigate further.

IMG_20221113_144520495 (resized).jpg

Everything is tested out on the computer, with some keyboard inputs for manual solenoid operation and a realtime updated page of switch diagnostics. "Reflex Devices" enables flippers, bumpers, and slingshots. "Selected Lamp" lets me toggle through every single lamp in the game, using keyboard, and turn it on or off. The "Attract Mode" keyboard command fires up a light sequence script. Lamp functionality and blink pattern handling is mostly taken from the Undertale code, but with some minor improvements. I will need to modify the lamp code further to work with the handful of RGB lights. After which I will never use RGB lights in a build ever again.

And finally, a running under-playfield shot.
IMG_20221113_144240060 (resized).jpg

Not all lights are lit up, due to this photo being taken during the attract mode sequence, but all of them turn on when told. A little below right of center (just above an orange status LED, between a bundle of mostly purple wires, between the slingshot coils and straight back), you can see the head of a radial cap. The resistor/capacitor fixes on all of the satellite boards are a bit ugly, but they work, and I've learned some valuable lessons for future designs.

Across the bottom (besides the uncut zip ties that I'll deal with eventually), you can see the Plexiglas shield that protects the motherboard and power supplies from falling screws. Between shield, side brace, playfield hangers, tilt switch, and operator buttons, everything is unbelievably tight together. But amazingly, everything was able to fit!

Thanks, I'm glad you're enjoying the build so far!

The playfield sits in the cabinet using a sliding and locking rail system. It's the same parts that Williams used in the 1990s. You can raise the playfield a few inches, then pull it forward, where a spring-loaded lock holds it in place. Then the playfield can sit on the front edge of the cabinet, on those two metal braces you can see on both sides near the front. This allows you to easily access the far back areas that would otherwise be hard to reach. From there, you can tip it all the way up to the backbox to work on the bottom. I don't have a lot of pictures of how this works, other than what's already been posted, but I can try and take a few later if I remember.

More or less finished up the twin back walls, which took some wood-cutting tricks but turned out decently in the end. I will still need to pull the playfield so I can properly reach back there and add some support brackets, but for now it's still surprisingly rigid with two screws.

And more importantly, with the back wall cut out and ready, I could also set up the diverter mechs at last! Each one is just a standard Z-bracket solenoid, prepared in advance with shiny new parts. They mount to the frontmost backboard, and sit on the rear backboard to help brace them better. The coil plungers just connect to a thick wire linkage, which I bent to shape to hold in place on the coil and the diverter assemblies themselves.

Not everything works the first time you try it, but I was very pleased to see that my diverter coils worked perfectly as soon as I plugged in their connectors.

That ends all the playfield coils. Next I need to focus on finishing up the school buildings (which are also ramp walls), then I can start properly dealing with code. And the shaker, but that's slightly less priority.

Thanks! Diverters can do some pretty cool stuff with flow, so it'll be interesting to see how this goes. My plan is to make the center ramp (and the left "ramp" / VUK) to both divert to a different flipper than was used to feed it, to keep players from easily hitting the same shot over and over.

I decided to wait on the playfield stuff until I get an electronics order. Need a power supply for the audio, will take the opportunity to install it once the playfield is out. In the meantime, I did some code. You can see a handful of color-changing arrow lights in the background in this video - but more importantly, at long last I could fire off the ultimate test of all playfield coils - a ball search.

It was decidedly not as... structured? melodious? ... as the early-mid 90s Williams ball searches, but a little tweaking with timing and order of coils ought to fix that "problem." Also, HOLY CRAP THAT IS A LOT OF SOLENOIDS.

Yep, 20! (Plus knocker, shaker, and the Start and Extra Ball button lights which use solenoid drivers because there are no lamp drivers on the cabinet board.)

Since I basically left this thread to wither and die, I thought I ought to breathe a bit of new life into it with an update. No pics yet, sorry, but it's coming!

As you could've guessed, I've had a lot of time taken up by things that are unfortunately not pinball related. With that being said, I've definitely chipped away at this project in small amounts here and there. The biggest achievement? Probably finishing (sort of) the tie-in novel! I'm not sure it's quite ready for public consumption yet considering it hasn't been properly edited, but it's already semi-live on its own dedicated web server. It will host the story, the lore, the character bios, and game info, all wrapped up into a sort of ARG-style facade that claims to be the high school's official web site.

And of course it knows its purpose. There are four pinball references in the chapter titles alone:
Pinside_forum_0_3469703 (resized).png
...and also an OMORI reference, since I fell in love with that a while back.

I can't remember if I mentioned this before or not, but I had expanded the code from Undertale to improve upon the handling of music and sound effects. The newer version could lower the volume of music so you can hear the sounds better, and I think it could also do other fading/speed effects.

Ha, ha. How cute.

How cheap, really. I'll be proud not to use it.

Guys, this is an early 90s or even late 80s game in spirit. Everything from the cabinet design to the playfield to the rules is designed to feel like a System 11 or early WPC. And I really thought playing back MP3s was going to give me that kind of feeling?

And so... I wrote a synthesizer inspired by the YM2151 and a music/sfx playback engine inspired by WPC89. From scratch. That is how truly unhinged I have become. It's still in the early testing phase right now, and I'm still working to create a more user-friendly interface for defining instruments and operators, but the basic functionality is all there. Will definitely upload a sample soon.

Currently implemented features:
- FM and additive synthesis. Several operators are allowed per instrument, each with independent attack, decay, sustain, release, optional automatic pitch shift, and choices of combining operation. Each operator's wave period is configurable with up to four independent wave generation algorithms, each of which have their own automatic amplitude shift with time parameters. Choices include the obvious bases of sine/square/saw/triangle as well as two noise algorithms and some harmonics-friendly versions of the basic waves.
- 4-bit PCM drum samples, which seem to roughly match the quality and frequency of the drums on WPC.
- 1-bit CVSD speech samples, the codec itself written from scratch based on the information I could find, and roughly matching Sys11/WPC speech quality.
- Command-based music playback, similar to type 0 MIDI, targeting individual channels and including intro/outro points to automatically loop the music.
- Beat alignment, allowing sound effects or music end triggers to line up to a beat or measure... think BK2K.
- Sound effects played through the same music engine, but on a different command layer. Playing notes on a channel for a sound effect mutes that channel for the music until either the sound effect finishes or a channel unmute command is executed. So a sound effect might choose to mute the lead, the bass, or even the drums, or any combination. However, a muted music channel still executes effect instructions such as tremolo or portamento, which affects sound effects that use that channel.
- Everything uses the minimum data sizes possible, and a simulated "ROM data bank" routine crams everything into one file that's stored exactly the same on the hard drive as it is when actively being run in memory. My 16-second test clip, including multiple drum samples, a speech clip, two sound effects, and music from start to finish, fits into a 20kb file, and that compression will only become more dramatic as I add more music. Best part is that since absolutely no processing is done to the soundtrack file as it is loaded, the entire audio portion of the game should load almost instantly.

Some planned additions:
- There will be music commands for firing flashers and triggering light sequencer effects in tune with the sound effects. The "blink GI in tune with the Multiball Ready music" thing that Data East/Sega games like to do is completely possible on this system.
- I will be implementing some very basic pitch/volume analysis done in real time on CVSD playback, which will essentially give me animated lip-syncing for free. This should be a nice bonus on a game that pretends to be a fully-voiced visual novel.

Already I have super high hopes for how organic this game's music will sound. Instead of playing back pre-recorded sound effects that also take ages to load initially, we're going back to the glory days of pinball music, in which your entertainment came from a whole electronic rock band that responded to your actions!
bocchi_the_rock_saison_2_c36a2855c7 (resized).jpg
(Yes, I love "Bocchi the Rock!", and anime girls playing music seems extremely relevant to this post.)

So, what have I been doing lately?

For starters, finishing up the FM synth studio. (This example soundbite comes from a MIDI file ripped from an old PC pinball game and not part of Volcano Blast's actual soundtrack, but everything that goes into rendering it is fully custom.)

Like all major projects, I use the word "finished" very lightly. I may tweak the quality of CVSD playback to reduce the white noise a tad bit. A composition window would be far more intuitive than the text-file-based music arrangement we have now. And I'm also thinking about implementing the System3-11 programmable noise generator, since I have a pretty good idea how it works.

The Synthem 11 project took up most of my limited free time over the past couple months, but once I finished it, I was able to jump back into the physical VB work. This weekend I finally finished the cabinet wiring! (Insert "your cabinet wiring is never finished" joke here.)

I mentioned the audio issues ages ago, but in short, an ATX power supply is absolutely not what you need for driving a sound system. I assumed it would work well enough, amperage-wise, but it turns out it also puts out a surprisingly noisy signal. I also had some trouble with driving the playfield lights with this PSU; the GI bulbs tended to get dim if a lot of feature lights were on, and the strained power supply noises that would flare up in sync with the light effects made it clear I was putting way too much stress on my +5v rail.

The solution to both issues was a couple of auxiliary power supplies. I probably could've gotten by with just one if I spent enough money on it, but this seemed good enough for me. I had a decent 12v supply from years ago that would drive the amplifier with no issue, and picked up a 5v supply more recently with enough amperage for the playfield lighting and controller boards. And then I hooked up my playfield 5v to the wrong output, and was absolutely sure I had fried all of my chips when I turned the game on and nothing worked.

By some miracle, I had not. How, you ask? How did my five-volt microcontrollers and drop target optos manage to survive the unstoppable onslaught of a twelve-volt assault?

The answer: Because I made *two* stupid wiring mistakes, and the second mistake prevented the 5+12v supply from ever actually powering up and destroying anything.

All three non-PC power supplies (audio, lights, and solenoids) run off a wire that is switched by a solid state relay. Like Undertale, this relay was connected to one of the ATX 5v lines, so when the computer comes on, so does the playfield. But I didn't think about this when switching the game's 5v circuit to the new power supply, so I had a relay that would only be switched on by the output of a power supply that the relay is supposed to turn on. I have never felt so relieved at my own stupidity.

For some reason, once I got the game fully up and running again, I still couldn't get the Allegro audio library to run. Maybe I badly misconfigured something when I was originally setting it up, but even reinstalling the whole library didn't fix the issue. Not to be stopped, I ported the audio streaming code over to libsoundio, which is cross-platform and which I already used for the Windows build of Synthem 11. Other than some minor compilation issues I had to resolve, this ultimately fixed everything, and now I have the game code smoothly running my own retro synth engine.

On that note, I figured out how to configure my FM instruments to create wind and volcanic rumbling. I cannot wait to hear my full sound package.

Don't mind me, just single-handedly building a high school all myself!
IMG_20230921_070600970 (resized).jpg

Honestly, I struggled with the motivation to dig into this for WAY too long, considering the amount of time I already had these parts just sitting in the bin. But I suppose it's better late than never. I did a bit of re-engineering of the left ramp return, because it sat about a quarter-inch higher than the right and was somewhat known for balls falling off of it, and parts orders arrived yesterday.

As long as I was taking things apart and rethinking, I added a spacer on top of the star post behind the upper left flipper, drilled a hole for another spacer above the flipper, and cut out an early template for a new airball shield. I noticed a very real chance of balls getting hopelessly stuck between the ramp rail and a locknut, so this shield (the white plastic on the left in the picture) will do double-duty. It will avoid that stuck situation, and also add a guard to keep balls from falling off the rail on the way down to the inlane. I should have extended the guide wall further down, but failed to consider this situation.

The vaguely rectangular box further up the ramp is the east wing of Obsidian High. I already had mounting brackets built into the ramp structure, so all it needed was some assembly of the flat sections and a bit of drilling. I have a couple more brackets left that I'll need to install before it can be considered solid enough, but already it carries the ball much more reliably now that the ramp actually has a wall. I might add another support that attaches to a post below the blue bumper.

I also added a plastic washer to a not-quite-sufficient airball post, off the photo to the right. Almost got all ball traps dealt with, then I'll have to figure out what I'm doing with the volcano to get that mounted up.

For story reasons, I'm going to switch the logical position of the Hot Spring from the VUK on the right to the scoop on the left. This is going to require either moving the Hot Spring's point value lights to the left, or repurposing them. I like the thought of keeping them, since their arrangement is supposed to resemble the stones around the hot spring in the story, but not sure how I would fit them on the left side. We'll see.

Thank you for the supportive words! I do wish I'd dedicated more time to working on this over the past couple years, but I feel like we'll get there eventually.

Full agree on the need for more video content. There are just a few playfield steps I have to finish up before it will be a fully functional whitewood:
- Airball shield on "entrance" VUK behind backboard. Currently I get a lot of kicks that somehow manage to fling the ball entirely out of bounds, a.k.a. cabinet floor clunk.
- Ramp floors need to be fastened down.
- Ideally I would take out the subways and fix a couple of tabs so I can mount the last two BLAST targets.
- Need to finish the center lift ramp.
- Plunger is still slightly too far left.

Once those are done, I can stop using keyboard input for game flow and actually play the game on real code. Seeing the volcano erupt with flashing and FM rumbles is going to be epic.

Had a cold for the last few days, but it didn't stop me from a weekend of construction work.
IMG_20230923_202537337 (resized).jpg

Not all the way done yet - still need the corner building caps, ramp floors, and the rest of the volcano - but the plastics are almost all the way there now. There's probably no better advertisement for 3D CAD software than watching me build this design and have to modify almost every prototype plastic with a pair of snips to get it to fit the way I originally intended. But that's what the whitewood is for, after all.

I had to cut into a hole intended for a flasher, pictured lower left, so I think I'm going to have to rearrange that area a bit for the final plastics. That flasher is the signal for the left scoop eject, so I do want to keep it at least nearby.

The (visible) backboard is mostly just a scenery piece, displaying the south wall of the courtyard. I think I will be extending a few plastics down a bit further, to help avoid ball traps and maybe hide a bit more hardware. I think this scenery is going to look really good once I've given it some artwork displaying the architecture.

I wrapped up yesterday evening by adding basic lip-sync to my speech code. I would hardly say it's perfect, but it's still better than static character sprites and a lot better than manually animating the mouth for every voice clip.

Pictured: "Wait, you're working on this again? I'm shocked."
IMG_20230923_202132786 (resized).jpg