I regularly do the KSFO-YSSY (SFO-SYD) big flight. I have been doing that flight for many years. When I started, United was flying the 744, the Queen of the Skies. After those were retired, there was a short time they were flying the 772. Then they switched to the 789. What a beautiful aircraft that is. Finally, they switched to flying the 77W since 2019. Last year, they started operating TWO flights. At least seasonally. They are still operating two flights daily. One with a 77W and the other with a 772. The million mile aircraft was N79011, an old Continental 772 with first flight 1999-06-18. Age 24.7 years. Probably TMI. Sorry.

No. It was a solo with me in the captain's seat. In hindsight, I probably should've asked for one with him as well as a commemorative photo. Too late for that now and I won't be hitting 2 million - ever. United calculates miles flown as actual (no fare class boosts) PAID "butt in seat" (nautical) miles ONLY on United aircraft. While waiting at immigration, another passenger in the cabin congratulated me. He overheard the conversation. He said he was at 500k. He's got a ways to go.

I had created a dual ROM board allowing selection between two game ROMs. Typically useful for situations like regular versus tournament or Pembot and Pinbot in one.

I hadn't considered creating a board to replace U26(27128)+U27(27256) with a single U26+U27(27512). It's theoretically possible. I will create a small board to do this. I created a schematic to do this and it should work. I'll add it to the next (pending) fabrication order I make.

I've seen something similar to this with a small test/prototype board that I built using the (shown above) water soluble flux solder. I forgot to wash it and left it. Came back to it and saw similar to what you see. The water soluble flux is acid based and you MUST wash it off with water. I think the recommendation is no longer than about 48-27 hours but I wash it off immediately after working on the board. It is recommended to use distilled water but I've not had a problem with just regular water. I use a surfactant to help remove as much as possible. Rinse well. Then let it dry. That is why it takes me days to build boards. I build them in phases and wash between phases. I like to have all the flux removed between phases.

And an update. Two separate posts to keep things separate.

While away, I worked a few things in the copious (cough) amounts of free time I had. I have a bunch of boards waiting fabrication but I batch them and try to limit the batch so it is not excessive. I will try to document the boards when I get around to laying them out and capturing images of them.

I typically start building the small boards. I did this during the adjustment period to avoid big boards. Big boards with mistakes are not good. I had these sitting around waiting for verification since I had a big board batch I wanted to get to. I have another big board batch to get to but I need to make a fabrication order so I have to complete layout for some other boards to batch into this fabrication order. It makes better use of the time (overlaps fabrication with my building).

So what's in this post?

boards_349.jpg

A bunch of small boards. From top left in a clock direction:

• The Addams Family - Extra Flipper Supply board. A-15416. There are others out there. My board uses discrete diodes instead of a bridge rectifier. Board is verified.
• The Addams Family - High Power board. A-15139. There are other out there. My board uses 3AG fuse clips instead of the 5mm fuse clips. It was a tight squeeze but I wanted to provide a board that uses the same fuse size as the rest of the machine (reference: https://pinside.com/pinball/forum/topic/hep-this-week-9-17-18/page/270#post-7842871). I was unable to use fuse holders since they are larger and there's just not enough space on the board without making it bigger. I also placed the heat sinks so that servicing the board (replacing the TIP36Cs) is easier since you can use a screwdriver directly rather than requiring a right angle ratcheting driver. Board is verified.
• White Water - Chase Light PCB assembly. A-15761. This board rectifies the AC with an adjustable regulator so it should be possible to use 6.3V #555 bulbs if the voltage is adjusted correctly. Not currently verified. If I get my PWM stuff working, I would consider adding it to this board so that LEDs would provide the true incandescent effect on the (waterfall) topper that LEDs take away slightly.
• White Water - Bi-Directional Motor Drive assembly. A-15680. Standard reproduction. Not currently verified.
• Indiana Jones - Motor Opto Switch board. A-16657. Reproduction but uses 5mm slotted optos with switch matrix isolation and LED indicators of the slotted opto state. Surface mount due to board dimension restrictions. Board is verified.
• The Addams Family - 2-Opto Switch assembly. A-15285. Reproduction using 3mm slotted optos with switch matrix isolation and LED indicators of the slotted opto state. Surface mount for the same reasons. Board is verified.

As you can see, I still have to create a verification harness for a few more boards.

These are more mundane, run-of-the-mill, boards. The next post will contain much more interesting stuff for those that are more technically inclined.

And now for the more technical post. It's LONG. If you're not interested in the technical details then you should probably stop reading.

I have been toying with this project for years. At first, I had no idea how to approach it. I did a lot of searching, reading and research. Gathering information from all sorts of reference material. Reading that reference material over and over and over. 5% sank in at first. Then maybe 10%. Each reading would provide an incremental understanding but the overall understand eluded me.

I built a substitution and simulation board but I got the simulation board wrong. I revised it but it turns out I didn't need it. I got it figured out yesterday with my first success. At least on the initial part. I had planned to do something else today but I got carried away because I kept making progress. Why stop when you're on a roll?

Here are the boards. The project should be obvious from the boards.

boards_350.jpg

There is the WPC-S daughter board for my CPU board, a prototype board to allow using a larger and faster processor with some diagnostic LEDs and two ZIF socket adapter boards to allow easy insertion and removal of ICs.

The two biggest issues with this project are the handshake and the switch matrix reading. I was fairly sure I got the switch matrix reading side working since I already had a prototype board that illuminated the corresponding LED in an 8x8 LED block based on the switches closed in a matrix fashion. The handshake was what was going to give me grief. I did a lot of reading of the same information over and over again and finally got the algorithm working. I had no way to verify it while away so I had to wait for my return.

I got it working on the bigger, faster processor and ported it to the standard processor. The PIC16F57. That's a very limited processor. Not much computing power. I got the handshake working on this processor.

boards_351.jpg

But the switch matrix reading had issues. Purely timing related. The communication protocol between the game and the security PIC is not a true handshake. There isn't any acknowledgement. It's more a post message, delay and expect a response in a certain amount of time rather than a send message and wait for reply. The reason for this is that the security protocol is grafted onto the switch matrix protocol to keep changes to the WPC CPU board and software simple. It really is post, wait, read response. I had to mess with the switch matrix reading code to get it to work on the PIC16F57.

Then I switched to focus on the bigger processor. I chose to use a PIC18F45K42 which is a (maximally) 64MHz processor with 40 pins. One input only pin and 35 input/output pins. Plenty of pins to do what I need. The extra processor grunt allowed me to actually compute the required data for the handshake rather than use static data. The PIC16F57 is so limited that static data is required. There simply isn't enough grunt to compute the data at startup. The ability to compute the data allows for the game number and the serial number to be specified.

One of the interest things is that if the game software gets the incorrect game number, it will attempt to do an "unlock" with the game number that it (the game software) is expecting. This means that the security code knows what the expected game number is. The problem is that the game software sends that information after the handshake and there's no way for the security code to reset the game processor to "try again".

However, the security code can store the expected game number so on the next startup, it can provide the correct answer. Since it computes the data at startup, it can compute the correct result. That's exactly what the security code now does.

Here's the example.

• Game is 526 and security is 536. This results in "INCORRECT U22" but the security code knows the game is 526 so it writes that for the next start. boards_352.jpg
• On the next start, game is 526 and security is 526. This passes and everything works. boards_353.jpg
• Switch game ROM. Game is 536 and security is 526. This results in "INCORRECT U22". Security knows game is 536 so it writes that. boards_354.jpg
• On the next start, game is 536 and security is 536. This passes and everything works. boards_355.jpg

In essence, it's a "smart" security PIC. It only takes one error to fix itself. I can't think of a way to predict the game number. The software just isn't clairvoyant. It can self correct though.

All of this is fine. It all works. So there are a few paths forward that I invite anybody who has read this far to contribute with suggestions. The self correction code is all I need for my bench. I just want something that works on the bench with whatever game ROM is used. Others may want other things, such as the ability to write your own serial number rather than the generic "999999" or "777777" or similar.

The issue with this is that the serial number has to be stored somewhere. It can be stored on chip but access to this requires special software and hardware to read/write the PIC. It's not a simple "serial" interface. Storing the serial number on external storage (EEPROM) means that the security code must read that EEPROM and the EEPROM must be accessible on the board through some interface. Common interfaces are SPI and I2C but there's no software to access this interface from a PC or Mac. This is my quandary.

So I invite comments:

• Is writing your own serial number important?
• Is having a selectable game number better than being self correcting?
• Does any of this really matter? Who cares about all of this? It's a super niche market with almost no demand.

Sorry for the long technical post. I figured someone might find it interesting. A lot of this information is actually available if your search-fu is good. It's putting it all together that was the biggest challenge for me.

I welcome any comments - public or private. My personal usage preference is self correcting on my bench. That's really all I need. I did it for a challenge more than anything else.

Now back to the regularly scheduled program. If I can find some time then I will clean this up (shrink it down the minimum rather than the big proto board). I also want to find some time to work on the PWM stuff but I still have a long big board queue that needs work. Perhaps in a billion years, the Earth's rotation will have slowed down enough that there will be 40 hours in a day.

Actually, there is a cycle that was omitted. On swapping the ROM, the initial start produces "FACTORY SETTINGS RESTORED". I backed out of this to force a normal cycle. This first cycle shows a mismatch which is then corrected. The important part for me is that there's no intervention required on my part. I have one of those game selectable versions and you either need to consult the "cheat sheet" or know binary representations of decimal digits to configure the DIP switches correctly. You also need to know the game number to set the DIP switches correctly. With this self correction, no intervention or knowledge is required. Just power cycles. I'll take that trade-off any day.

The OEM and Ewe22 software embeds the ENCODED bytes into the data written to the PIC. It's pre-encoded on another device (PC) since the encoding algorithm is "computationally expensive". It's expensive for the PIC16F57 to do since it only has a basic ALU that doesn't support multiplication or division in hardware. It's also an 8-bit accumulator and the numbers are 32-bit numbers. It has space for 2,048 instructions, 72 bytes of data and no non-volatile data (EEPROM).

• The OEM IC was (presumably) written on some assembly line that automated the computation of the encoded data before writing it to the PIC16C57 (in those days it was C not F). Nowadays, PPS uses the same OEM software when it sells their PIC but I don't know if they allow you to select the serial number displayed or whether it's a fixed (static or generic) serial number.
• Ewe22 wrote a static serial number. I believe it was 999999. By not bothering with specific serial numbers, it allowed the PIC to be written in a production line without any customization. The goal was to make the machine work without bothering about the correct serial number.
• Flipprojets also offers a PIC but allows customization. Presumably, it takes the data you input, encodes the bytes and writes it to the PIC before shipping.
• The game selectable IC that was offered (and might still be offered) shows 777777 as the serial number. The game number is selected with 2x 4-bit DIP switches that represent the lower 2 digits of the game number. Since it only supports the lower 2 digits, and it presumably assumes the most significant digit is 5, this won't support Safe Cracker since the most significant digit is 9 for that game.
• There might be other solutions available. I know there was one recently published (a year or so ago) that used a different Microchip processor.

The encoding algorithm is published on the web. It just requires a little bit of searching and being able to read the C language.

Two things.

1. s11_cpu_c58.jpg
2. https://en.wikipedia.org/wiki/Logic_family

Those are hints. If it's unclear what the nudge is trying to do then let me know and I'll elaborate. You will learn more if you do the reading.

Small update. Nothing fancy.

• I was asked by a member to reproduce this board (A-19242-1 = the Dual H-Motor Controller). I have it verified but I built a specific verification board for a bunch of these bi-directional "motor" boards. There are three such boards that I can see used through WPC. A single control implemented using TIP102/TIP107 transistors. A double (dual) control that duplicates the single control circuit. A single control implemented using a bridge driver (4 way). The verification board should be able to verify all of them. I have the IJ bridge driver board reproduced but I need to find the L6203 bridge drivers that I purchased (a while ago). I plan to do the TZ version (a revision of the initial IJ version).boards_356.jpg
• I don't build this board (A-20028 = WPC-95 Power Driver) very often. Not a lot of requests for this board. My bench is using the OEM board from my Scared Stiff but now it will use one of these boards so I can put the OEM board back in the machine.boards_357.jpg

I have another small board set in fabrication that I will post about once I get them in, built and verified.

And ... off topic but a follow up.

The other week I got a notification of an expected package to be delivered. Tracking showed it originated from IL. I didn't order anything. Certainly nothing from IL. So I went to the post office to pick it up. This is what arrived. I placed the quarter for relative size comparison.

00_ua_mm_package_front.jpg01_ua_mm_package_rear.jpg

Definitely unexpected. The challenge coin was also unexpected. I found a thread on FlyerTalk about this milestone and people achieving it (or multiples of it). A bunch of wasted time (reading the whole thread) later, it looks like the airline only recently started sending these out.

I opened it up and this is what is inside.

02_ua_mm_package_inside.jpg

And this is the actual plaque. It's crooked (sigh). I guess that's the OCD in me. Nonetheless, a very nice gesture.

03_ua_mm_plaque.jpg

Yes. It took 29 years and 7 months. No. I will NOT be achieving the next (multiple) milestone.