I have a mega as well. I'll assume I'll have to issue the NMI via the arduino to handle debouncing though. I forgot that the stack would save the registers, duh!

Was messing around with this today:
BallyNanoAdapterV1 (resized).png

Size is 1.8" X 3.8"

I need to add a point to jump to R134 and the 3 Pole switch

Still has some issues with the traces too close together

DickHamill This thread is of great interest to me, but I have a slightly different goal. I have a -35 MPU board. I want the game to play normal except I want to capture pretty much everything that "happens" during the game.

With your extensive experience I was wondering if you think it is feasible to leave the existing M6800 in the machine and either capture the data to/from the 6810 RAM or emulate the RAM chip itself with the Arduino. The idea would be that the 6810 holds the entire active game state and so following that memory as it changes would give you the ability to "watch" the game state from outside of the machine.

This has some different challenges from your project because you offload the entire game (ROMs, processing, RAM, timings, etc) into your Arduino. I'm not even sure the Arduino would be fast enough to process the data on the RAM bus either as the RAM or just watching it. I suppose I could also work toward implementing your project except as I understand it to get an authentic experience I would have to re-implement the entire game code on Arduino, which probably isn't feasible.

I've posted a similar question on the Electronics StackExchange: https://electronics.stackexchange.com/questions/509846/feasible-to-capture-data-to-from-a-1970s-ram-chip

Curious your thoughts, super cool project.

You would probably be better off with the LISY https://lisy.dev/lisy35.html board in your machine instead, and modify pinmame to capture what you're looking for. Ben Eater has a series where he uses an Arduino mega to capture the bus of a 6502 computer he's building on a breadboard.

It's not just the 6810 that's holding game data, it's the 5101 as well (displays, lamps, audits). For Bally games, every score is pulled from the 5101 down to the 6810, moved to another area of the 6810, added to, then checked against the replay levels in the 5101, then moved back to the 5101.

The hardest part of what you want to do is interpreting the mountain range of data this would generate, and what you would glean from that. What's the goal in watching the game state? Modification, art project, game genie type device?

Why wouldn't it be feasible to recreate the game code on the Arduino? Implementing your stock Playboy code would be relatively easy. The game code in early bally games is really straightforward. The operating system is where all the programming rigor is there.

I see from the stack exchange answers that most of them are pointing you towards FPGA's. I believe there's already open source cores for a lot of the 6800 series.

Can you explain exactly what you want to do with the captured RAM data?
BTW, while the 6800 is rated to 1MHz, Bally only runs it around 500kHz clock speed.

I want to build statistics around my game. Track scores, which switches are hit most frequently, etc. View current state, maybe make a virtual representation of the game board and be able to "replay" the game by stepping through the game states.

My goal started out as simply and automated way to capture the score of every game played. I looked at capturing this right from the display bus. Then the Playboy owners thread gave me the idea about capturing the frequency some of the switches are hit (the Playboy keys). Which one is naturally hit the most? During play try and nudge the ball into the rarer switches. Then I said why stop there? Maybe capture the outlanes to see how dangerous each side is vs the middle, and side targets, etc, etc. But looking at the switch matrix I'll need 8+4 channels to capture that. If I wanted to do displays and switches I would need something like 20 channels... So I read Bally's Theory of Operation and it talked about the purpose of the 5101/6810 RAM in the game so this seemed the obvious "straight from the horse's mouth" location.

If anyone else has a creative solution I'd like to hear it. slochar has given me a good idea with the LISY. Ideally an Arduino (or similar) would replace the MPU and be able to load the original game ROM for play. Then hopefully there would be some way to inspect the game state from outside the ROM execution. LISY seems pretty close to that.

Edit: I've also looked at a computer vision solution for this, pointing a webcam at the playfield and one at the backglass. This could still be feasible (especially for the score) but I think computer vision is going to have a really hard time tracking a mirror-finish ball flying around a playfield with art on it.

You might look into scorbit: https://medium.com/scorbit-pinball/scorbit-pinball-january-2020-update-89b6acb4a79e

For the scoring. For the other things, this is what I'd do:

Get a weebly board. It has more ram and rom on it to track the statistics you're looking for.

Modify the OS rom to record all those statistics. (Not the scores). Once in a while either look at them or record them as well.

To automate this as much as possible I'd likely attach the arduino like Ben Eater did to the J5 connector, and write a sketch to look for a specific strobe to an unused memory location in the stock code, which alerts the arduino to capture a byte. Then, send a stream of bytes along with the strobe to the arduino which comprises your information.

Your project idea would go one of several ways as I see it:

1) Snoop the bus to grab the info you want. Difficulty here would be parsing out the information, for which you'd have to understand the original code anyway, or re-write into Ike's framework - which in this case I think would be easier because you could report the information you're after directly. (Either over the serial monitor, or via an SD card library - lots of these exist already for arduino to do data logging.)

2) Add into the original code the ability to track what you're looking for, and use the arduino to collate it and dump it out. Bally Playboy has open romspace as it's shipped on 3x2716, so you have 2048 bytes available there to add your code. The difficulty here is interfacing the arduino to grab the statistics (well, and depending on how well versed you are in 6800 assembly.... if you can't do that, you'll have to find someone willing to do it/has done it already)

3) Add into the original code the ability to track what you're looking for, with the weebly board's extra ram leveraged to keep track of all the extended statistics. This also requires the ability to recreate the source code. Has the advantage that the arduino doesn't have to dump data in real time, the stats for the game can be kept, then at the end of the game, some handshaking can go on between the arduino and the 6800 coding.

Ike's setup with rewriting the whole game is by far the easiest IMO if you are comfortable with arduino coding (I know enough to barely get by, but I was able to follow his code no problem on BJ2020 and Stars2020, to the point where I think I could modify it as I saw fit.... with google at the handy to help)

There is another alternative to recreating the original source, and that's to re-write anew into something like Oliver Kaegi's PCK kit:
http://www.pinball4you.ch/okaegi/pro_pck.html - a ready built documented OS. There are also various other homebrew OS's available, from whatever LISY has, to one I've written (not publicly available) that requires the weebly board, to a Stern OS rewrite (meteor-up, as well as the earlier mpu100 games).

I've used the weebly stern/pinbol [williams] OS to recreate Stars as a proof of concept. I'm in progress of rewriting Bobby Orr Power Play into Stern PIGS' style code, and used the stern os mpu100 game to write CPR's cancelled Lost Vegas software and also rewritten a couple of other games (some williams in there so not applicable to Bally world). I actually track some statistics in the Night Rider game I wrote, although not down to each switch activation.

I keep track of all my games' scores in a spreadsheet and have done so for at least the last 12 years or so. It helps me track if I'm getting any better at the games (I'm not) and more importantly, tells me if I should think about selling a game, based on the # of plays I put on it year to year. There are external factors at play here though, because I'll go hot on titles for a while and then cold for a long time, or there will be something piled on it, or I'm doing a PF swap, etc.

I'm tempted to try and get something hacked into some of the games and add arduinos to it, ideally that communicate back to a database back end so I can get statistics at a glance, like after a party or something. Baby steps first though.

Stern's sb-100 sound board grabs a byte off the bus as its regular operating mode so I think an arduino could do the same.... heck, you could put the logic chips on it that do that and have the arduino read from those chips instead of trying to grab and debug real time.

From your initial question, you can map your own 6810 and 5101 RAM externally from the J5 connector using address decoding to pull the J5 EXTMEM signal low.
Note, in order to replay your states, you'd need to capture the state of the whole machine which also includes the CPU registers (i.e. where's the stack currently pointing) and configuration of the PIA chips. The solenoid/coil/relay states are not stored in RAM the PIA ports are where their states exist. This is an unrealistic approach.

On a different idea with replay, modifying the original game code during the main execution loop where it determines which switch activations are valid you could get it to write the switch number to an unused memory area that an intelligent device hooked up to the J5 connector scans which essentially logs/records those switch activations real time.
You could also scan a memory mapped area during the main execution loop where you real time pass those time logged switches back allowing you to replay a recorded game input.

As slochar said, you can also modify the game code to spit out the end of game scores, again to some currently unused memory address you read from J5 connector.

Thanks for the super insightful post. I think I'm now leaning more towards Ike's solution and recreating the game logic from scratch. I'm an experienced programmer (albeit not C/C++/Assembly) and only experienced enough with electrical engineering to get by. I think I offloading as much as possible to the Arduino and replacing the entire 6800 makes the most sense for extensibility. I should probably go back and read this entire thread in detail.

A few questions:

1. I've seen some products which replace the entire MPU board with a newer smaller "smarter" board but after 10min of Googling I can't seem to find it. Is this ringing any bells? Any advantages to that solution?
2. For the pinball ROMs for this era is it possible to view the logic code or am I going to have to reverse engineer from the gameplay behaviors/rules? Like I said I don't have any Assembly experience at this point but as long as the logic is accessible I can figure it out. I would like to reimplement an authentic experience as close to the real thing as possible. Something like a ROM decompiler or equivalent...
3. How forgiving is this hardware? Assuming I hook up the physical aspects correctly, is it feasibly possible to damage the machine/components via code bugs? Sounds like Ike has done the OS portion where I think a lot of this risk is with the AC cycle timings and stuff. Not a huge fan of unforgiving learning where a code mistake means you have to wait a week for a part from Digikey.

Sounds like the LISY or the arduino setup. I think there was another one that plugged into the 6800 and replaced it made by someone in the UK, I think he's applejuice here? Not sure on that one. (There was a project from 2009/2010 or so where someone replaced the 6800 in a williams firepower with something else, but I've lost track of that setup, figures, once I want to experiment with it!)

If you mean replacement MPU's, both Alltek systems and Weebly https://nvram.weebly.com make universal replacement boards that are about 1/2 the size of the original Bally board. Alltek doesn't allow end users to change the rom code on it, and it's a direct replacement with dip switches to select your game. Weebly has an auxiliary 27512 eprom socket to allow experimentation, extra romspace via that socket ($1000-$ffff instead of $1000-$1fff, $5000-$5fff on bally original boards), and extra nvram ($100-$fff - which I think can dip even lower than the $100 but I've not formally tried that. Almost 1k of ram is enough anyway!)

Look into Pinmame debug versions. There is a link in the Oliver Kaegi site to it. It emulates the original boardset and you can disassemble the code. It's easier to either play the game and take notes or just take the rules from the manual to implement vs. learning how to disassemble and modify the original code. You can look at the 'stern galaxy disassembly' thread https://pinside.com/pinball/forum/topic/stern-galaxy-code-disassembly to see what some of the code might look like, but only the 6800 code there - Bally doesn't have an interpreted language like Stern mpu200 games did. The backend is very similar though, and the nvram from $200-$2ff is a full byte instead of a high nibble like Bally has.

Seriously, from a gameplay perspective, Playboy is extremely simple, especially if you don't implement odd combinations of dip switches and just decide on one. There isn't even a lot of carry over status IIRC. I have one torn apart in the basement that I should get back to at some point....

Yes, you can blow stuff up. The hardware that drives coils and lamps is completely under your software control. The lamps will turn off on their own if not refreshed but the coils won't - they turn off if another coil fires, or at the expiration of a timer. If you read Ike's blog site he covers the timing issues. If your machine is fused properly it won't be that big of a deal, replace fuse. You learn to trust your ears and nose although once the nose smells the coil, the driving transistor is usually fried. But you'd listen for things locked on and not releasing.

If you were willing to put a weebly board in it I'd be willing to mock up Playboy's ruleset in either my new pinbol style OS or stern pigs, your choice. Stern Pigs I'd be willing to share the source code but the pinbol style OS is staying private for now source-wise. (i.e. it's not ready for prime time, and you can do almost everything in Pigs that you can do in it anyway)

If you want to do the Oliver PCK I can point you in the correct direction, but I don't use that one. I think he has some safeguards built into it for new people. all the pinball OS's do - for instance, on pigs you'd really have to do something dumb to have a coil lock on and stay on. The OS automatically turns off the coil after a specified time when you fire it.

For instance, the pigs code to fire the grotto in playboy would be: enable_solenoid_07 $14 - $14 is the time (longer, because it's a kickback) and solenoid 07 fires Q8. Now if you did something dumb like put $ff for the time, you'll likely blow a fuse, because that's just too long.

The only thing that pigs won't do is control the sound board, that would have to be written custom. I'd probably enlist Quench 's help for that since he has a bally playboy working AFAIK whereas I don't even though I have the game (it's a project!) I don't 'think' it would be too hard to implement the sound board, they are pretty basic in their operation, vs. say the sb-300 that's in the stern mpu200 games (which I was not able to get the timing down to activate on the pinbol os....yet....)

The arduino code looks C-like to me, you could probably get by with modifying what Ike's got going in it. I still think that would be the easiest to do what you're thinking, sound board code needs to be written for that as well I think.

I didn't spot a 6800 emulator for the arduino on a very cursory google search, but that doesn't mean there isn't one. Looks like someone did port over a 6809 emulator that I'll have to go checkout, but that wouldn't run the original code at all (6809 is source level compat. with 6800, but the opcodes are all different).

Awesome community here, truly. I'm going to move forward with an Arduino Mega attached to J5 (and interrupt pin from the 8600 socket). I'm still reading through the thread but I'm way far on the novice side so I'm going to start slowly. My previously segmented knowledge is now coming together on how this works. As I understand it eliminating the need to communicate with the ROM/RAM chips greatly simplifies everything because all you're doing is interacting with the PIA chips and some timing signals from the board. You now get to choose how to react to those signals and what signals you send in response.

Mentally this is a really attractive situation because the game hardware now becomes just input and output devices and you have full control (for better or worse). I'm so glad I found this thread because it means the sky is the limit. Why WATCH the game when you can BE the game? I suppose you could do all kinds of crazy stuff like having a game mode where you have unlimited balls, just don't hit a specific target, otherwise gameover. Heck, the outhole could be a key game component now and emulate a mini-game within the larger game. Hit the 5 keys, drain the ball to enter a mini game mode where the whole playfield is reset for a short period to rack up a multiplier, then drain the ball again to resume the actual game, bringing back the previous playfield state before the minigame, but now with a point multiplier. If you were committed to 1 or 2 players only you could even use the P4/P5 displays for other game info, or even a LCD on the Arduino.

Is anything I'm saying there overstating the capabilities, or am I correct the sky is the limit (physical game capabilities aside obviously)?

Sort of - the ram/rom is replaced by the equivalent on the arduino, and the signals are another layer. You're interacting on an upper layer, one step removed from the hardware. You just let it do its thing, refreshing displays, timing solenoids, refreshing lamps, sending sound data to the sound board, and reading switches. You're not going to be changing that part too much I'd think, if at all, unless you want to tag a special message on when the switch is hit. I'd put that in the upper layer instead (reaction to the switch).

What you are choosing to react to and how is basically the switch events. All the rules in playboy are 2 pages in the manual, and that's if you want to implement all the dip settings (I wouldn't bother with that). Not having a multiball game to deal with or other oddball hardware helps.

Depends on how sloppy you code it, I think Ike said he's at 96% capacity with a very generous amount of extra rules for Stars. Your data logging could take place via the serial monitor on a laptop or something to make it even easier, you don't have to get SD card support working.

One thing that you may wonder about (I did when I first started doing this) - is trying to identify what memory locations are keeping track of how many lamps you have lit, or keys on playboy, etc. - game status. Almost always, the game status is just whatever the lamp is.... there's no separate register in most cases that says "5 keys lit" - any routine that needs the key status just counts the lit lamps. That's not to say that you couldn't/shouldn't implement it if you have variable space, but if you do, document it well. I know when you write the code it seems obvious, but I'm a big fan of the one assembly directive, one comment philosophy, and more lines if needed. This will help debugging later.

So I'm making progress on this work. I purchased an Arduino Mega and was surprised to find that I need to make modifications to the code because the pins don't line up with the Nano. I was able to refactor the code to at least get the MachineDiagnostics.ino file to work.

I ended up with this pin configuration, of which the J5/Nano columns were taken from the latest Stars 2020 PDF.
Arduino Mega Pins

Node the PD entries had to be changed to PL. As far as I can tell the Arduino Mega does not have PD4/5/6 pins, so I couldn't use them. I was able to reuse PB/PC pins.

Bottom line is I had to do a find and replace in the MachineDiagnostics.ino for the following:
DDRD -> DDRL
PORTD -> PORTL
PIND -> PINL

When booted I get this:


Start of program
Monitoring VMA signal, looking for presence of M6800 processor
Saw no sign of M6800 -- program will continue
Attempting to read & write from U10
Testing U10A Control Register
The U10A control register passed
Testing U10B Control Register
The U10B control register passed
Testing U11A Control Register
The U11A control register passed
Testing U11B Control Register
The U11B control register passed
Testing the clock cycle (if this hangs here, the conncection to clock is faulty)
It took 19144 microseconds for 10000 clock cycles
Clock frequency (very) approximately = 522 kHz
DIP Bank 0 = 0xFE
DIP Bank 1 = 0xFE
DIP Bank 2 = 0x7F
DIP Bank 3 = 0x4F
Starting interrupt tests - this is going to take 5 seconds to test
In 5 seconds, saw 601 U10B interrupts and 1722 U11A interrupts
Zero-crossing approx. 120.20 times a second
Display interrupt approx. 344.40 times a second
Interrupt tests done - if frequencies aren't approx 120 & 320, there's a problem with the interrupt line.
END OF TESTS


I was getting nowhere for a while but turns out I was clipped to the top of R34 instead of R134 and only noticed when watching one of the videos and I was like "my alligator clip doesn't go down there".

My next steps are going to be to create the test suite for the Bally Playboy and then on to game design.

DickHamill As I do work I'll be using a lot of your code and probably making some modifications. Are you interested in making this more of a community project? If so I don't mind doing the legwork to create a GitHub organization and do some re-arranging of the code files into repositories by purpose. Obviously you've done the majority of the work here so it would only be worth it if you agree to use the new organization. If you're not familiar with GitHub organizations it's no different, just instead of everything being under your name it would be under something like BallySternOS.

Example: https://github.com/BallySternOS

Then you would have like:
https://github.com/BallySternOS/Diagnostics
https://github.com/BallySternOS/SternStars2020
https://github.com/BallySternOS/BallyBlackjack2020
https://github.com/BallySternOS/BallyPlayboy2020

If you don't want to go down that path, do you want me to submit my changes (or new Playboy files) to you as a GitHub pull request, or not and just continue working on my own code base?

Thanks for all your work, even just getting this far is awesome. More to come...

I currently have my 1978 Bally Playboy working through Self Test Mode using this code base. Sound doesn't work, but I think that's just because no sound self test code is written.

For now I'm maintaining my forked copy of the BallySternOS code with some updates (code and docs): https://github.com/ckabalan/BallySternOS

I found a few items from the last post I forgot to include, mostly that there were a few normal port accesses that were fixed too. You can see all the things I did to fix the Machine Diagnostics to work with the Mega here: https://github.com/ckabalan/BallySternOS/commit/5f37973de3e88270c14aa712b68ac63cc25c101a

Basically, I refactored the code itself to be more port-name agnostic and then set up a define section at the top which does the mappings. I also needed to refactor the VMA and RW ports (I forgot to include it in my last post, but it was in the code).

Anyways for now I'm doing Bally Playboy 2020 here: https://github.com/ckabalan/BallyPlayboy2020

Small annoyance is that I can't drop "Bally" from the name since Stern and Bally both made Playboy machines...

It's basically the same refactoring as the diagnostic code, but performed on the full code base (BallySternOS, SelfTestAndAudit, BallyPlayboy2020). Here is what I had to change to get it working on the Arduino Mega: https://github.com/ckabalan/BallyPlayboy2020/commit/c6aff9fb133fdc175240d73eb97bcc97d9f377cc

I can't overstate how amazing this project is. When I pulled down the code, did the refactoring, tweaked the timings, and uploaded it and it mostly just worked I was amazed. Of course still a lot to do with mapping switches/solenoids, and figuring out sound should be fun.

Again would love to collaborate and maintain a central codebase if people are willing to.

What Arduino IDE is everyone using? I'm getting by with the default for now but I see a lot of people online are using PlatformIO with a text editor (VSCode/Atom).

20200714_153848.jpg

Before I started development on re-creating the game rules I wanted to go back and make a perfboard with the switch in the front of the pinball so I didn't have to remove the backglass everytime I wanted to work on it or someone wanted to play using stock CPU/ROMs. The pins are the same as my post above, with the addition of the 74HC125 chip to HALT the stock CPU. Those pins don't affect the Arduino AT ALL, they only control J5 pins 10/13/24.

Here is my basic wiring (red = traces, blue = wires). This doesn't include most of the data pins, and it is mostly meant to be instructions on what to do first. That would be to get the 74HC125 hooked up right with the switch, power/ground to the Arduino, and the special MPU R134 IRQ hookup. After I did the tracework on the diagram below I worked through the pin table and did the rest of the point to point wiring.

Perfboard Diagram

Here is the final wiring:

Perfboard Wiring

And "mounted":

Mounted Arduino Mega

This passes the machine diagnostics and test/audit mode.

A few things I'm curious about:
- The Stern Stars 2020 PDF connection diagram shows J5 pin 17 going to Arduino Nano Pin D13. Pin 17 isn't in the connection chart and I didn't notice until after I wired everything up. So far mine seems to be working fine. Is J5 Pin 17 used or not?
- The post on this thread references the 74126 chip, and the Stern Stars 2020 PDF shows 74125. The wiring is a bit different so the chips might have different purposes. I implemented it using the PDF version and chip 74HC125. I also noticed the diagram here (and some datasheets) use 1G/2G/3G/4G for the pins on the IC, but others use 1OE/2OE/3OE/4OE. I'm not sure the difference. The datasheet for the chip I used used the OE names but it works as intended.

Next on to adjusting the Self Test and Audit mode to cycle through the right solenoids and hopefully get sound working.

I blew the 1A playfield fuse accidentally because I flashed my Arduino Mega with the Arduino Nano MachineDiagnostics code. Because all the pins are different it incorrectly detected that the M6800 was missing (it was running) and started talking to everything during startup. I had about 10 2A, 2.5A, 3A fuses, but zero 1A fuses... Isn't that always the way? Anyway I got the right diagnostic code and all is good again (except the playfield solenoids).

Some pretty interesting things happen when both CPUs try to control the system. I'm sure you've seen it too. When I go into the stock test mode all the settings are screwed up. Weird stuff like the free credit settings when you pass certain points are set to random numbers like 18,100. I didn't get out the manual to check what data I was viewing but I'm pretty sure it screwed all the audit stuff up too, like six-figure play counts. I assume wires got crossed with both CPUs communicating on the bus and the NVRAM received all kinds of crazy values.

Does this apply to the Bally AS-2518-32 sound board? I current don't have D13 connected, will that inhibit me there? I've yet to hear sound from the Pinball Machine Base test mode, but I don't think that base does sound. I haven't looked into it though. The knocker does work though, and I think that's controlled somewhat by the sound board on this machine.

What exactly are you trying to do? I can help out. Typically people just leave behind the history if they move file between repos. The problem is usually_ all branches in a repository have a common ancestor commit. That's usually the first commit of the repository, or the commit where they branched off. What you're talking about is fairly advanced git work, and is merging with unrelated histories. I haven't done this before myself, but I'm pretty good with git, so if you let me know what you want done I can probably do it if the target repo you want everything to end up in is in the BallySternOS organization.

The Teensy 3.6 has been my goto-board lately. Nice and fast (180Mhz), no funny Neo-Pixels, onboard SD card slot, lots of memory and I/O, programs easily from the Arduino IDE.

https://www.sparkfun.com/products/14057#features-tab

There is also a 4.0 board with processor running at 600Mhz but that's faster than I need....

Not sure if we can do that in the Arduino code, but people do use other IDEs. I've been playing around with PlatformIO ( https://platformio.org/ ) with Visual Studio Code, which a lot of people seem to use. PlatformIO is pretty opinionated about project structure (defining the directory structure for you), but bringing in the Arduino code was easy. I just used the "Import Arduino Project" function and it gives you some hints. Basically rename the .ino file to .cpp and add the Arduino.h header. After I did that I was able to compile and push without issue. You can see an example in the Bally Playboy 2020 code here in the Arduino directory: https://github.com/BallySternOS/BallyPlayboy2020

A easier way might be to leave all definitions commented and require uncommenting of the relevant device? That way it wouldn't even compile unless someone read the documentation. Better would be to (as you've implied) make it a setting between "ArduinoNano", "ArduinoMega" and "None" (default).

When I get there I'll post back here...

For your GitHub issue, honestly here is what I would do. I would take your BallySternOS code (which currently includes Stars2020) and push the entire repo to the Stars2020 repo. You would have BallySternOS and Stars2020 repos with effectively the same code and history. Then I would just delete all the unnecessary files out of the Stars2020 repo, refactor the structure as you like, and do your commit/push. Any files that were delete will still be in the history, but won't be obvious. No one will find the deleted BallySternOS code in the Stars2020 repo there unless they're specifically looking for it. If they want to see the history of a Stars2020 file the whole history will still be there. I'm usually pretty picky about keeping projects clean, and what I've described doesn't seem unreasonable or "dirty" to me.

If you want me to do it, let me know. Only takes a few minutes.

I'm just an impressed bystander on this thread which is such a cool idea and whilst beyond me to offer contribution is great to follow along and read about.

When I ran into performance limitations on a Nano for a WMS display replacement I started looking at ESP32-S2 boards. Cheaper than Teensy and much faster than Nano. It's being / has been implemented into the Arduino IDE so might be worth a look and suits your price point.

I hope it is okay to ask questions about the technical details at the beginning? Can someone help me understand the combined solenoid and sound data?

How is a solenoid held on for multiple zero crossings unless you have to hold up doing any sound requests while the solenoid is on? Solenoids have to stay on for a long time compared to normal data transitions. I saw a comment by DickHamill about interrupting the power briefly to service a sound request but I thought that would violate the need to only shut off a solenoid near a zero crossing?

The sound code saves the PIA register for the momentary solenoids, the sound select pin is toggled, the sound data is put on the the PIA port, sound board grabs the 5 bits (4 from the PIA, and one from the address E). Then the sound code puts the original contents back.... it's so short that the solenoid driver board doesn't drop the solenoid being currently activated.

If I add the WAV trigger do you have a library of the WAV files you used in your video, or do I need to supply my on files? If I need to supply them do I need to name them something specific to line up with the code?

Perfect, thanks for the info and for making this awesome project available!

Soldered up 2 of RoyGBev's boards today. I only had my Eight Ball to try them in. One board would not work but the other fired up with FG2021 and produced an interesting attract sequence. Never found anything wrong with the other one but after cleanging it with contact cleaner and a tooth brush it now worked.

I tried FG2021, Meteor, and Mata Hari code. Each one came into attract mode. What I found odd is that the diagnostic sequences don't seem to match the list in the BSOS code. I also noticed that in the Mata Hari solenoid test, the kick back on Eight Ball actuated when it should but also when at least 3 other solenoids fired.

Really exciting update for me. As soon as the rev2 kit is available I'll be building one for my Meteor. Thanks for all your work.

DickHamill, I posed a question in Solid State Tech, re: replacing MPU-200 with -17 Bally, received a NO answer, based upon processor speed and address mapping. That post didn't address my purpose, as I didn't state it, outright.

Since I received a "not so good" reply on using the weebly.nvram.com replacement board with the Arduino, and having a -17 board on hand, I wondered if I could place the Arduino onto a -17 and have the combo work in a Stern Meteor, considering that the Arduino has its own clock.

So.. will Arduino (on RoyGBe board, with wav trigger), on Bally -17 MPU board work for Stern Meteor, in place of MPU-200?

As long as you connect that extra jumper that comes with the RoyGBev board I would expect that the -17 board will work well. Actually may work better than on an MPU-200 at the moment.

I'm having issues getting the WAV Trigger working on my Stars. I'm using the RoyGBev board with the included WAV Trigger connector as shown in the pic. I can hit the test button on the WAV Trigger and it plays the first sound file, but I'm not getting sounds during gameplay. Here are the steps I took. Could someone see if I did something wrong or missed something?

- Downloaded the WAV Trigger Arduino Serial Library
- In the Arduino IDE I included the .ZIP Library
- Went to the libraries folder and edited the wavTrigger.h file to comment out all of the serial #define lines
- In Arduino IDE I went to the library and added the #include <wavTrigger.h> line at the top of Stars2020
- Also commented out #define USE_CHIMES and then added the #define USE_WAV_TRIGGER
- Uploaded to the Nano

Appreciate the help in getting this working.

PXL_20210422_032049704 (resized).jpg

Are you supposed to comment out the serial define lines? I think you need those to serially talk to the WAV trigger.

I believe per the instructions pdf that you are supposed to comment them out to make sure it uses the hardware serial port of the Arduino.

I'm used to the updated Meteor code and never had to touch those entries. Only had to tweak a field to specify what version of the Firmware is on the WAVtrigger. Maybe that is different for the other games it runs on.

I didn't do anything with the Firmware on the WAV Trigger. I wonder if I need to update that somehow. I also didn't have the WAV Trigger board connected to the Nano when I did the upload. Could that also cause issues?

Not having it connected shouldn't make any difference uploading the code to the NANO board. On the WAV trigger the only thing that needs to be done on all is to solder bridge a couple pads so it can be powered through that 6pin cable.

You may not need to update the Firmware on the WAVtrigger. It was optional for Meteor and I did it. There are two lines to configure what version of WAVtrigger firmware is in use. By default it was the older versions that ships on the boards. If you update the firmware then you uncomment the line for the 1.3x firmware and comment out the other. This is on Meteor so it is possible requirements are slightly different for other games.

The new model of RoyGBev adapter, supporting SB-300 and Squawk and Talk, will be released next week, thank you.