Can you use a 3-to 8 decoder or 4 to 16 decoder to increase the # of pins (especially for single direction address pins) available? The sound board shares 4 lines with the solenoid driver signal so you have those already, then a separate sound interrupt line.

https://robertsonics.com/wav-trigger/

$50 but pretty versatile and can stand alone. Could likely be triggered by adding some port expanders or using a different flavor of Arduino.

SB300 isn't controlled the same way as Bally sound boards - there's no cpu on the sb300, just a timer, that the game sends bytes to to program. It's the stream of bytes sent that generates sounds. Now if someone can figure out how to actually generate new sounds, I'd be very interested in that.

The sound engines are even different from game to game depending on the programmer who wrote it.

So anyone looking to implement new game code on the nano with the original sounds is going to have to duplicate the timing and sound data to do so.

That makes sense now when the test chip was talking about the rows and columns for the lamps, that didn't make sense on whatever thread that was.

Andrew is talking about the display digits themselves, with the 4543 segment decoder any BCD info sent to the display that isn't 0-9 (ie. ABCDEF in hex) is displayed as a blank.

That's not to say it couldn't be changed to a different decoder, though. Especially if you have aftermarket LED displays in a kit, easy to change at that point.

The only digits that aren't specifically 0-9 that are sent to the displays are F (for blanking) and occasionally $E (for specific purposes in showing or hiding credits/match numbers) - those would have to be corrected.

Slam switch to clear the memory is smart I will steal that idea for my stuff I was using the coin switch instead like Bally did in -35 boardset games, but the slam is a better idea.

The numbers that you think are sound boards might be for SB-100 and SB-300 on stern games? What is that test chip in the alltek board or the 2 bit ones?

So looking through the code, seems like you're HALTing the 6800, which tristates it. Am I right in assuming that you can take over the bus at that point via the arduino and address memory locations? i.e. see what's in the ram, etc. - I know that won't get the 6800 registers from the processor (there'd have to be a 6800 emulator running on the arduino to get that) but at least contents of ram could be explored as a debugger? That might get me where I'd like to go with this. I plan on trying out the code on my stars next week with an ancient Duemilenove I have laying around.

I know the debugger memory stuff would require many more I/O pins (although not so much if I just want the Ram contents, nothing with roms).

Maybe I can rig something with an external interrupt to have the processor save the registers into memory somewhere (the extended ram in the weebly board would help here) - what does the 6800 do when it comes out of HALT? All its registers are internal so does it just resume where it left off or does it reset?

Still keeping the dream of a monitor alive.....

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!

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.

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.

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

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.

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.

No, you just don't add an interval.

Nothing stopping you from programming in 6502 and Tgol. What changes?

If you just want to change the software (I'm talking about the original stuff here) you don't really have to worry about the hardware level just the software layer.

Going a little OT from the original thread here but PM me if you are interested in doing anything with the original.

https://pinside.com/pinball/forum/topic/arduino-pinball-controller/page/16#post-6693094

another possibility, if he means the same black knight as you do (the original)

looks like he's working on getting black knight going in apc

That's what I'm thinking....