Been a while since I posted any updates on things.

Big thanks to @ j_m_ for all the work he has done with annotating the board images. It should help tremendously for those building their own boards.

There are far more requests for complete boards than bare but that's understandable. Building a big board is a challenge! It's fun though. Well, at least, my idea of fun. It's certainly very rewarding when you build one and it works.

It's about this time of year that I take time off to visit family. That means that the months of December and January have no builds. In order to satisfy some of the demand, I have spent most of October and December doing pretty much nothing but building boards. I went above my usual quota for November by about threefold. It was almost all WPC-89 CPUs and PDBs. I spent the last two weeks building boards for transport across the Pacific Ocean. Those are almost complete.

In between all that building, I did find some time to work on some other things but at least one the boards I had completed in September has not been built and another was built but doesn't work. That means I have to sit down and figure out why it doesn't work. No time for that.

So what's been happening?

• I revised the WPC-89 DMC (dot matrix controller) board. I added a daughter board for the high voltage section so if it fails, it's a simple matter of replacing the daughter board to keep the machine running. The broken daughter board can then be repaired at your leisure (or discarded if you so desire).

  Unfortunately, when I built the first board, I must have spaced. I tested it on the bench (digital logic), it passed. I tested it in a machine (with a plasma display), it failed. I inspected the board and it was pretty obvious why.

  boards_258.jpg

  Once I fixed that, everything works.

  boards_259.jpg

• I got a request to make a modification to a System 9 board to partially support System 8. This would have required cutting traces. I decided a (signal) converter board was a better solution. Two boards. One to map solenoid signals from System 9 to System 8. Another to map address select signals so that the sound PIA is located at $4000 (System 8 sound section) instead of $2000 (System 9 sound section). The person who requested this has the boards for testing.
  boards_260.jpg
• I have a plan for an upcoming board that I will probably need to use a surface mount regulator instead of the usual through hole regulator. So I built a small surface mount version of the +5V switching regulator and tried it out. It works. No heat sink required. The back side of the board is a ground plane and after a few games the board was only slightly warm. I didn't bring my thermal camera so no thermal images are available. The board supports LM2576 or LM2596.boards_261.jpg
• Finally, as part of the boards being built for transport, I had to build a WPC-95 AV board. I hate building this board. Did I mention I hate building this board? It's the QFP ASIC that gives me the most grief. It was also what gave me grief when I was doing "bring up" on the board. Typically, the only feedback you get from the system is "SOUND BOARD INTERFACE ERROR". Did I mention I hate sound board interface error?

  Well, this board I just built gave me the same grief. The display side of the ASIC worked but I got sound board interface error. Good thing I put the ASIC on a daughter board that acts like a socket. I swapped in a known good ASIC and everything worked. Ok. So the ASIC is the problem. Is it the ASIC itself or my soldering? Continuity tests showed it was my soldering. I visually inspected this board but I still missed the error. Can you spot the error? Oh, wait. I used my magic highlighter to show you. This ties the DSP_PA19 and ROM3 signals together.

  boards_262.jpg

  So I fixed it.

  boards_263.jpg

  Put it back on the bench and everything works.

And finally, I have a teaser.

teaser.jpg

This board doesn't work properly. It mostly works but I've had to revert to prototype status on the board until I can get it ironed out. This board won't be ready until some time in the new year.

I do these by hand with my standard iron tip. No magnifier nor microscope.

I find the most time consuming part is actually aligning all the pins to the pads (straight and evenly spaced). When the ASICs arrived, the pins were bent all over the place. I'm always worried I'll break a pin off the body and render the IC worthless.

It's 120 pins of pure soldering pleasure. NOT!

I do have this board working. It is not a commonly requested board. I suspect most people choose an aftermarket alternative board. There are a lot of that board in machines. There, consequently, must be a lot of unused boards floating around.

I thought I had posted this image but I cannot find it, so clearly I did not.

boards_230.jpg

I may have a complete board lying around unclaimed. I can make a note of requests (for tracking). I cannot service requests until about the end of January.

Alternative color poll thread.

https://pinside.com/pinball/forum/topic/dumbass-reproduction-boards-alternative-colors

Hope everyone had a great holiday season!

While away (I am still away), I have worked on some boards in design. Some small tweaks to a medium sized board and some other small boards that serve specific purposes (verification and prototyping).

Having completed these, I turned my attention to again staring at the Unified System 3-7 CPU/Driver board that I have made zero progress on for many months. I have stared and compared and cannot see anything obvious. So I decided I would try to write some code to execute and see if I can figure out what's going on.

• Verify that all the RAM is accessible. Both the regular SRAM and the CMOS. I will write some simple code to write patterns to NVRAM and then read the NVRAM in a programmer to see what got written.
• Verify that all the ROM is accessible. Write some code that spans $C000-$FFFF (the available ROM space) and make sure that each "page" is correctly accessible. I will write the expected PC (program counter) to the SRAM (NVRAM) and read it back in the programmer.
• Verify the ROM banks are accessible and correctly selected. The main board supports a single ROM on the board itself, or multiple ROMs (banks) on a daughter board that can be selected using buttons (much like a DIP switch).
• Verify that the diagnostic features (LED or digit display) is correct and accessible.

To do the above, I wrote my own 6800 disassembler. I started by looking at the Leon code. I expected to be able to figure out what it does and am surprised by how "simple" the code is. Well, not really surprised because it doesn't do that much but it does allow me to understand how the PIAs are accessed.

The "guts" of the Leon code is shown below. Essentially, it configures the PIA ports A and B as output and then programs the port bits. First "0", followed by a delay, then "1", followed by a delay and looping. In between this, it also programs CA2 and CB2. This programming of CA2 and CB2 is not shown below.

leon_sys7_functionality.jpg

Hopefully, I can establish how much of the system (ICs and address space devices) are working. I know the Leon code does work because I can see the port bits pulse. That's a good sign. That was as far as I got last time. Hopefully, I can get the above going to figure out what the issue is and get it all resolved. This board has gone nowhere for quite some time.

I still need to actually write the code. Instead of writing an assembler, I will probably just hand "assemble" (encode) the instructions for this simple testing purpose. A full blown 2 pass assembler is definitely overkill for this purpose. This has definitely piqued my interest in System 11 code and WPC code. For WPC code, I will probably need to write a 6809 disassembler. The 6809 is a progression of the 6800 but my understanding is that it is a different instruction set.

I wasn't aware of the System 7 games being the only ones using A15=1. I actually didn't look at a System 6 game. I just took a quick peek and can see what you're saying. I used the 6802 "manual" to follow what the processor does when released from reset. I just looked at the reset vector (as well as the other vectors).

From a hardware standpoint, the full address doesn't matter because the board ignores A15 from the CPU. In essence, $7000 and $F000 are the same. It means you could also access the PIAs at $A000 through $BFFF. This is the same principle that made early Macintosh machines "not 32-bit clean" because they operated in 24-bit REAL address mode.

From a software standpoint, as long as it stays within the allocated $4000 bytes of address space that is portioned off ($4000-$7FFF or $C000-$FFFF) it doesn't matter. The software could jump from $D000 ($5000) to $5000 ($D000) and it would still execute the same code.

As far as selecting ROMs, the hardware does that with a 2:4 decoder. The software just sees a continuous address space. System 6 sees $6000-$7FFF and System 7 sees $4000-$7FFF although the hardware supports $5800-$7FFF.

I appreciate the information and any corrections for any information if I have it wrong. I surmised all this information from the schematic. By doing this, I assumed the schematic is correct. That can be a dangerous assumption when it comes to Williams schematics.

I hope everyone had a great festive season! My travel is complete and it is now the adjustment phase. With a fair amount of time off, the build queue is long - both bare and complete. I appreciate everyone's patience in both answering messages, but more importantly as I work through the workload that is ahead. I do also want to finish some of the investigative tasks I had started (the unified System 3 to 7 board), as well as having to handle local requests for board repair and home repair visits. Thankfully, both of those don't happen often but I do have some of those items waiting.

The remainder of this post will be quite technical. Feel free to stop reading now.

Results are shown, but it might also tickle the reader's interest in both how some things work and how I do some aspects of building / engineering. Some things I do might be considered overkill, but sometimes you have to return to basics to know what's going on. This is particularly so when you don't have a single machine low level debugger (or debugger nub).

Let's get started.

This continues from the last big post about verifying the unified System 3 to 7. I wanted to establish the address map is correct, as well as access to the diagnostic LED (System 6) and diagnostic digit (System 7). There are four distinct tests below. I have not tested the bank feature (multiple game ROMs on a single 27C080). I will leave that until later as I need to get a single game ROM executing properly first.

The RAM test.

The system has two separate RAMs. System 6 has SRAM at $0000-$00FF backed by 2x 6810 ICs each holding 128x 8-bit data elements. System 7 has XRAM (SRAM) at $1000-$13FF backed by 2x 2114 ICs each holding 1024x 4-bit data elements. Both have CMOS at $0100-$01FF backed by 1x 5101 IC holding 256x 4-bit data elements. To maintain System 6 compatibility in System 7, the first $100 bytes of XRAM is double-mapped at $0000 serving as the SRAM.

This is the code.

unified3to7_ramtest_code.jpg

This is the result.

unified3to7_ramtest_sram.jpg
unified3to7_ramtest_cmos.jpg

The ROM test.

The OEM board supports multiple ROMs at specific addresses, as well as multiple IC types (2316 vs 2716 or 2532 vs 2732). It's all very confusing. It's much easier to just use a contiguous address space from $4000-$7FFF or $C000-$FFFF. This test records the PC (program counter) in the XRAM to make sure the processor is executing as expected.

This is the code.

unified3to7_romtest_code.jpg

This is the result.

unified3to7_romtest_CD.jpg
unified3to7_romtest_EF.jpg

The diagnostic LED test.

System 6 boards have two LEDs (LED1 and LED2) used for diagnostic indications. This test just makes sure that both of them can be accessed and display correctly.

This is the code.

unified3to7_6led_code.jpg

These are the results.

unified3to7_6led_1.jpg
unified3to7_6led_2.jpg

The diagnostic DIGIT test.

System 7 boards removed the two LEDs and replaced it with a 7-segment digit for diagnostics indication. This test just makes sure that the digit responds correctly. All the digits are correct but only 4, 5 and 6 are shown.

This is the code.

unified3to7_7digit_code.jpg

These are the results.

unified3to7_7digit_4.jpg
unified3to7_7digit_5.jpg
unified3to7_7digit_6.jpg

The basics of the address space work fine. The diagnostic indicators work fine as well. There must be something else wrong on the board. After staring at the schematic even more (prior to travel), I think I have isolated a difference. I need to figure out how to "patch" the fix into the board. I've done this before with cutting traces and such but this time I had a few "pass through with interception digital logic" boards made. These small boards allow me to selectively pass some signals through and intercept (re-route) others. These should help reduce the clutter of cables that I would normally have to construct when testing. I can use these boards in the future when troubleshooting, so it's win-win. While waiting for these boards, I will pick off items in the build queue. Always work to do.

Ha. I am scared of it, too. It's kicking my (dumb) ass. It doesn't help that I don't have a control (i.e. I do not have an OEM board). OEM boards are expensive and they don't seem to pop up for sale that often (or at least at prices that aren't outrageous). Once I have a functioning board (not there yet), I would consider making changes to improve it. I must have a known good baseline first. Otherwise, I am introducing more variables that will just make differential diagnosis (debugging) more difficult. Learn to crawl, then walk and finally run.

And a brief update. I have a work queue that needs addressing. I am trying to make more efficient use of time by front loading some changes on some boards. While the revised boards are being fabricated, I will start working on the work queue in earnest. Right now, I am overlapping (task switching) between items in the work queue and working on board changes. This slows down the work queue, so I apologize to those waiting. I don't like having a long work queue but I also don't like being blocked on required changes to move things forward.

There is a thread on this forum asking about a dual software board (specifically for System 11). I built two versions of this board. They both work but don't fall into the "ready for public consumption" category. The double ROM board works but the LED switch sense is reversed (the LED is on when the switch is not latched rather than when the switch is latched). The single ROM board works but the U26/U27 select is reversed. When building a compatible ROM, rather than ordering as U26 ($4000-$7FFF) followed by U27 ($8000-$FFFF), it requires U27 ($8000-$FFFF) followed by U26 ($4000-$7FFF). Not intuitive and therefore not ready for public consumption. I need to revise these boards to fix these minor problems. It's polish but I like polished products.

boards_264.jpg

I take verification seriously. I verify all boards before I send them out. I try to verify every aspect of functionality. Some boards I don't always fully verify (such as high voltage). I have built and verified many of them and I have yet to have one fail so the odds of this are low. That doesn't mean I won't make mistakes building boards. I still do make mistakes. Verification (quality assurance) is supposed to catch these errors.

I revised a verification board that I was using to verify slotted opto and lamp boards. The quintessential example of this is the Indianapolis 500 Illuminated Target board. This board has a slotted opto and lamps. Other boards only have slotted optos. The first revision of this verification board was not adequate to test multiple slotted optos on a board. Hence the need to revise it.

I also built a verification board for the proximity sensor boards I have available. These are just like the OEM board - i.e. they are dumb. I spent some time (during my time off) looking at the possibility of making a "smart" board. There's a learning curve for this so it might be some time until I can figure out how to do this. Hopefully, not too long but I have a lot of "unfinished" things. Remember that this is supposed to be "fun" (and a learning experience) for me.

boards_265.jpg

After having revised the verification board, I also need to build a bunch of cables to test them. That takes more time than I would like, but once I have the cables built, I have the infrastructure to verify more of them quickly. This new verification board is also capable of verifying the 3-opto, 7-opto, 10-opto, custom 10-opto and 16-opto boards I have available. I was verifying them on my full WPC-89 bench rig but with this new board I can verify them much more quickly.

boards_266.jpg

And finally, the verification board was used to verify this new board is electrically correct. There are numerous physical issues with this board.

boards_267.jpg

Pros:

• Single board design.
• Uses open collector (drain) comparators to isolate the slotted opto from the switch matrix. This is what the gold standard Ingo board does. See https://groups.google.com/g/rec.games.pinball/c/FY0bSS7UqaA (specifically the post by ED (GPE)) for reasons to do this.
• Full wave rectification of the GI (AC) to remove any LED flickering that may be seen on other boards that just use the AC to power the (LED) illumination.
• Illumination brightness can be adjusted with a simple potentiometer.

Neither pro nor con:

• Uses surface mount components. This recovers more board space to make routing around the slotted opto hazards a little easier. There are no ICs that are surface mount. Only simple components like capacitors, resistors, diodes and SOT-23 transistors.

Cons (for the moment):

• Physical problems. It is electrically correct.
  • Headers are not correctly aligned. The are not centered to the hole in the clock housing.
  • Slotted optos need to be mounted much higher than the leads allow. I am investigating a reliable way to have these raised the significant distance off the board that is required for them to protrude through and allow the minute hand to interrupt the slotted opto.
  • Alignment of outer hour optos is not correct. I'm afraid to run the actual clock motor as the interrupter might drag against the slotted opto. The minute optos must be a 3mm slotted opto. The hole in the clock housing will not allow a 5mm slotted opto. The hour optos could be a 5mm slotted opto, but this would mean having to have two different slotted opto types to build the board. Not really "build your own" friendly. It would make the interrupter alignment a little easier due to the extra (2mm slack). I have to shift the outer hour opto positions to align with the interrupter track.

Getting all these changes done is what is slowing me down from working on the work queue. Once the changes are made and the boards are in fabrication, the time taken for fabrication is overlapped with the work queue items. Much more efficient use of time rather than making changes and then waiting around during fabrication.

Yes. Use messaging (PM).

I can try to build one for you in spare time (time where there is not enough of it for board building). You might have a complete one before I do. An example of issue I have with building carts is:

• Resistors
  • Carbon film
  • Metal film
  • 1/4W standard size
  • 1/4W miniature size
• Capacitors
  • Some have Z tolerance (-80%,+20%). Tolerances of M (20%), K (10%) and J (5%) are acceptable. Lots of available options.
  • 50V is typically the minimum voltage rating. Higher voltage ratings of 100V are acceptable.
  • Varying body dimensions (size).
• Packaging
  • Bulk (loose components).
  • Cut/Tape (components taped at both ends in a string).
• Price
  • Some might want the cheapest component that fits the rating requirements.
  • Some might want to increase quantities to potential quantity price breaks.
• Out of stock.
  • Supply chain issues cause some items to be out of stock from time to time.
  • Adding alternatives to the cart creates unwanted redundancy and doesn't guarantee items will still be in stock.

Yes. Lots of reasons why a cart is not ideal.

For those building carts and you are unsure about components, feel free to share the cart and I will take a (quick) look and see if the components are compatible.

Back to building boards. I need to squeeze two months worth of build queue into one month as I will be away (again) for the month of March. I am going to be busy.

Verifying a batch of three WPC-89 Power Driver boards tonight. Normally, all boards verify without incident. Every now and then, I find an error in building. This typically happens when I build faster than I would like (time constraints). I still verify everything before sending boards out. Nothing leaves without passing my bench.

This particular board didn't pass. So I did a quick visual inspection and quickly found the problem. Yes. It's a simple error but it goes to show that humans make mistakes. The only thing that matters is the mistakes are caught and corrected. Bonus points for correction in a timely manner.

boards_268.jpg

I fixed the error and the board passes.

I'll probably be looking for someone to test the board and give it a good run. I will run the clock test on my bench and make sure it passes but there's nothing like using it in an actual machine. Unfortunately for me, one of my TZs is in a garage that used to be accessible (the machine is playable) but there's a lot of stuff now stored in the walkway so it's now effectively inaccessible and unplayable. The other TZ I have is "empty cabinet with parts in a storage tote". This one has been this way for about 4 years now since I've have been doing this board adventure.

Through hole T1-3/4 (5mm) LEDs are common and cheap. They should provide sufficient illumination. There is a brightness adjust potentiometer present as well. I like to keep things simple (for starters). If the four LEDs don't provide enough illumination I would consider adding more LEDs to the base board or alternatively, creating connection points and mounting a daughter board and putting more LEDs on that board. I don't think I'll need anything like an LED strip (which are also typically 12V rather than 9V). 9VDC is the expected (RMS) DC output from rectifying 6.3VAC. Using LED strips or SMD LEDs would be another item I would need to stock.

The revised board is out of fabrication and headed to the shipping carrier. Hopefully, I'll have them by the end of this coming week. I would like an answer on the changes I made, in order to know if I need to make more changes (for physical reasons).