What's new
Pinball info

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Controlling Bally Sound Boards

myPinballs

Site Supporter
Joined
Nov 19, 2011
Messages
5,410
Location
Pudsey UK
Alias
Jim
As i have produced 2 sound board remakes now i decided to write a test software program for my 2 bally compatible boards. The idea being that you can specify the board type in the program and it will then play the full set of sounds for you. I also thought of having an input where you can specify the sound id directly. I like this idea also for the purpose of using with some of my other projects such as my custom pinball controller and also for recording high quality samples of all bally sounds.

Whilst developing the software I came across something that was interesting whilst working out how to access sounds from later games like gold ball and xenon which are 7 segment games and use a larger 2732 rom. It also provides supplemental information on the tech information written regarding how the later sound boards (namely the Squawk & Talk) receives information.

img_f.pinside.com_201507_2547558_424089_i.jpg
Before the 7 segment on Bally games was introduced the control line was using a sound address line 5 to allow upto 32 sounds to be played. When the 7 segments came out this line was then used to drive the 7th segment and so if the sound access program remained the same then only 16 sounds would have been possible. At this point I believe that the double 4 bit nibble process was introduced (yet to confirm this through tests though) to allow upto 256 sounds to be played. This would mean that this system was in place as soon as 7 segment games came out (Skateball onwards?) rather than from the introduction of the Squawk & Talk Sound board.

Also, as mentioned in the technical documentation by Clive Jones

"Strangely, the schematics that I'm checking against show a *fifth* solenoid select line wired to PA4 (if the "EE" jumpers are installed, which, we'll come to shortly) or IO4 of the PSG. Maybe Bally kept their options open by keeping this fifth solenoid select line available on S+T?"

The 5th select line is still connected on a S&T board, but on closer inspection of the manual schematics and wiring diagrams, this line is tied to ground through a looped connector so the signal is purely used on the display front here. Also on games such as Xenon the manual states sound address line 5 as Not Used. This rules out some sort of possible multiplexing for both signals, and i'm not sure how that would have even been possible with the current design.

This is info is also posted on my blog here: http://blog.mypinballs.com I will update as i find and learn more.
 
May you be the man @myPinballs to help me with the sound issue I have on a WPC DCS board?? I get a U3 Checksum error even when the ROM is fine ??? I swapped the ROMS into another board and they all worked fine so it deffo appears to be something on the board - any ideas ?

CHeers Kev
 
I've been doing exactly the same thing with my Arduino to test the AS-2518-50 board in my PARAGON and the AS-2518-51 board in GOLD BALL. I'd noticed the same thing! But that's about as far as I got and the Arduino code is well... just embarrassing at this stage :oops:

Do you have any plans to release the test software? And will you bring it along to NLP for a demo? I'm looking forward to the Hacking Lab!
 
Do you have any plans to release the test software? And will you bring it along to NLP for a demo? I'm looking forward to the Hacking Lab!

Yes happy to demo it on my hacking lab. Stop me anytime during the weekend for a chat. I will release the code on my site once I fathom the more complicated double nibble control.
 
May you be the man @myPinballs to help me with the sound issue I have on a WPC DCS board?? I get a U3 Checksum error even when the ROM is fine ??? I swapped the ROMS into another board and they all worked fine so it deffo appears to be something on the board - any ideas ?

CHeers Kev

This should probably be in the tech section as a seperate topic, but I would double check ribbon cables and install each rom in sequence starting at the lowest numbered end to see what bongs are heard and when the checksum error appears ( as per clays repair guide tips) the checksum is not always telling you the truth, so it's worth knowing which rom specifically causes the fault. Also, which dcs game are we talking about?
 
Last edited:
Quick update on what i'll be bringing to the hacking lab in regard to this thread.

I'll have one of my bally computer sound boards (space invaders/nitro ground shaker/future spa/xenon/gold ball etc etc) hooked up to the arudino test software, which will be able to play various sounds from the boards rom. I'll also have the software code available for people to look at if you are interested in learning how to write a test program. I'd really like to get the test program working on later boards to like the s&t board, but we will have to see what time is available before the show as the stern indy project is taking up most of the non board assembly hours currently. :)
 
Here's a video of the sound tester in place using space indavers roms and my effects board. Note the yellow serial leds on the arduino as i type in the command to play a sound


The test software has commands for :
  • playing sounds in forward order
  • playing sounds in reverse order
  • playing a sound by id
  • jumping to a specific sound
  • stopping all sound playback
 
Another observation evading early bally computer boards. I was investigating the lack of a boot up led on these early boards and found that the board is still going through some sort of check/self test on boot up, as the board will not play sound instructions for a few seconds at power on. You can also here an audible change on the speaker as the system is booted up and all the pins are configured on the pisa and the sound generator, just like on s&t. I wonder if the self test is the same, but just doesn't call an led status output on the pia with these earlier system boards?? intriguing!
 
Another observation evading early bally computer boards. I was investigating the lack of a boot up led on these early boards and found that the board is still going through some sort of check/self test on boot up, as the board will not play sound instructions for a few seconds at power on. You can also here an audible change on the speaker as the system is booted up and all the pins are configured on the pisa and the sound generator, just like on s&t. I wonder if the self test is the same, but just doesn't call an led status output on the pia with these earlier system boards?? intriguing!
Exactly the same conclusion I came to. I even hooked up the same LED driver circuit to the the PIA as on the MPU, but not so much as a flicker. I guess the tests are in there and running but not the call to the PIA. Shame :(
 
Pleasure chatting to you at NLP. A noisy hall with 130+ pinball machines wasn't the most conducive environment for a batter about code and electronics but I do recall you mentioning you were still working on the Arduino test code for S&T boards and nibbles etc.

I've now got 3 S&T boards that I need to test, service and/or repair so I got to reading up about them. I was flicking through the Bally ELECTRONIC PINBALL GAMES REPAIR PROCEDURES manual FO 560-3 when I spotted this info about the data latch timing. You've probably got this but in case you haven't here it is:

farm6.staticflickr.com_5780_22289501966_0d6573aeef_c.jpg

Looks as though timing is critical here. Need to shift in the first 4-bit nybble just 22us seconds after the Bank Select goes high, hold it there for 145us and then shift the next 4-bit nybble in for just 76us! Unfortunately there is no indication of what codes are and aren't recognised or what the 70us gap is at the bottom of the time line.
 
Last edited:
Pleasure chatting to you at NLP. A noisy hall with 130+ pinball machines wasn't the most conducive environment for a batter about code and electronics but I do recall you mentioning you were still working on the Arduino test code for S&T boards and nibbles etc.

I've now got 3 S&T boards that I need to test, service and/or repair so I got to reading up about them. I was flicking through the Bally ELECTRONIC PINBALL GAMES REPAIR PROCEDURES manual FO 560-3 when I spotted this info about the data latch timing. You've probably got this but in case you haven't here it is:

image-jpeg.21610


Looks as though timing is critical here. Need to shift in the first 4-bit nybble just 22us seconds after the Bank Select goes high, hold it there for 145us and then shift the next 4-bit nybble in for just 76us! Unfortunately there is no indication of what codes are and aren't recognised or what the 70us gap is at the bottom of the time line.

Yes, i have this timing implemented in my sound board tester library for arduino, but haven't managed to get it to work yet. Seems there's something i'm missing. This was the control i was talking about above that was most likely implemented after the switch to 7 segments and not when they changed to the s&t board
 
Jim, is it possible to power an S&T board using an ATX PSU on the bench similar to bench testing the MPU? I see the S&T has an additional requirement of -5VDC for the speech section.
 
Jim, is it possible to power an S&T board using an ATX PSU on the bench similar to bench testing the MPU? I see the S&T has an additional requirement of -5VDC for the speech section.

Welcome to the world of the s&t board. You'll need an arcade psu that can inject a -5v power source, as this is needed for the tms5200 speech chip to run. the board won't fully boot without this chip installed and working. Alternatively you can find a 6vac supply and input that so the board can use its built in voltage doubler circuit. I test all my new board remakes in my elektra directly first without any chips installed then again after, its just easier than on the bench.
 
Welcome to the world of the s&t board.
Thanks :p

I started experimenting last night and managed to hook up my bench mini-ATX supply to one of the S&Ts. I connected GND to pins 6 and 16, +12VDC to pin 17 and -12VDC to pin 7:

upload_2015-10-21_11-35-19.png

At this point I got 4 flashes on the diagnostic LED indicating speech chip U8 not ready. Checking the test point voltages that wasn't surprising when I found I was getting less than -2V at TP4 which should be -5VDC for power to both speech chips U8 and U9 (can't see that -5VDC is used anywhere else on the S&T).

At this point it was time to Google "voltage doubler" and have another 101 lesson in basic electronic circuits. Now I understand why the -12VDC from the ATX isn't being regulated to -5VDC by VR2 is because a voltage doubler relies on an AC input voltage to work! VR2, an MC7905 -5VDC regulator on my boards, requires at least 2V higher on the input so Bally added a half-wave voltage doubler formed by C37-CR8-CR7-C38 to double the negative half of the 6.5VAC power from the General Illumination bus to give a healthy -12VDC to VR2 (the 6.5VAC power for the GI is the only output from the A2 power module that hasn't been rectified to +DC).

My next plan then is to simply bypass the voltage doubler altogether and just inject the -12VDC supply directly in to VR2 (using the base of C38 would be handy as I can just use a clip onto the leg):

upload_2015-10-21_12-5-14.png

Jim, I realise this is nothing new to you. I'm just making notes as I progress and hopefully others will find it interesting and informative. I'm determined to work out how to get an S&T working on the bench under the control of an Arduino. One thing I did read somewhere, possibly in that article by Clive Jones, is that the MPU does send some "command" data to the S&T during boot-up to initialise the volume settings from the audit values. I wonder if without this the S&T doesn't enter a state of, let's call it "readiness", to accept sound data? Maybe it's just sitting there waiting for a couple of commands first?
 
As you can see, it doesn't take long to realise why testing the power side of a board in a game is much easier than on the bench and also why i added a -12v test point to my board redesign. If you do inject a voltage further down the power line, you must remember part of the board will be untested and could be faulty when put into a real game.

Thanks :p
Jim, I realise this is nothing new to you. I'm just making notes as I progress and hopefully others will find it interesting and informative. I'm determined to work out how to get an S&T working on the bench under the control of an Arduino. One thing I did read somewhere, possibly in that article by Clive Jones, is that the MPU does send some "command" data to the S&T during boot-up to initialise the volume settings from the audit values. I wonder if without this the S&T doesn't enter a state of, let's call it "readiness", to accept sound data? Maybe it's just sitting there waiting for a couple of commands first?

Happy to assist you, as time allows and contribute to the enhanced resources and of course the arduino code to get these things working. As previously discussed i have a fairly good library written that will be a good starting point. I'd like to think i know a fair amount about the inner workings and design of this board. An interesting idea about the remote volume commands. There does seem to be some mis information regarding the 5th select line on the clive jones article, as that is tied low for an s@t board as its already used for the 7th display segment.

Also, i have plenty of info regarding how to test a board if your TMS5200 chip is dead, or all its pins are corroded or broken off, but we can get to that later!
 
You've probably done jus as much Googling but did you come across this article about reverse-engineering the code on the AS-2518-51 sound module? Whilst it doesn't solve our problems with the S&T it does show just how clever those Bally engineers were at the time and what we take for granted now. The fact that it contains a custom virtual machine to drive the AY-3-8910 is impressive!

http://zerocharactersleft.blogspot.co.uk/2014/07/retro-pinball-reverse-engineering-bally.html

There was an interesting note about Sound 3:

When the pinball machine wants to play a sound, it triggers the IRQ line on the 6800 through the interrupt logic of the PIA. This triggers the execution of the interrupt service routine (ISR) located at address 0x1023. The ISR performs some initialization and then reads the value asserted by the pinball machine on the AY-3-8910's IO port A to determine the sound that is being requested. Sounds are played with interrupts unmasked, which means that an incoming interrupt request can interrupt the currently playing sound. Since the ISR resets the stack at every invocation, the newer sound completely overrides the older one. An interesting note is that (at least on Nitro Ground Shaker) sound 3 is always played with interrupts masked, rendering it uninterruptible. Sound requests will be ignored while sound 3 is playing.

If that's true about Sound 3 that it can't be interrupted by any subsequent sound requests, then how do you stop it and play another sound? What happens when you play sound 3 on SPACE INVADERS?
 
There was an interesting note about Sound 3:

If that's true about Sound 3 that it can't be interrupted by any subsequent sound requests, then how do you stop it and play another sound? What happens when you play sound 3 on SPACE INVADERS?

Not sure i have read that article, or it was awhile ago so must check that out, but i know about the interrupts stuff mentioned. I believe this was for backwards compatibility with early chime sounds etc where they didn't want them interrupting to match an electromechanical game more correctly. On the digital computer sound boards you could still set the game to be 'chime like'

In terms of controlling the board when sound 3 is played you have to wait i believe until its finished before anything else will be accepted. Normally you can send another sound id anytime and it will just start that one instantly
 
Ah... I see. So sound 3 is like a killer sound that's more important than anything else in that once started it can't overtaken by anything else. I can imagine something like a bonus mode announcement needing this so that it can finish to notify the player of an important even but not be interrupted by the ball in play hitting any other switches, etc.

The article is mostly about decompiling the 6800 code on the -51 board, but is still very interesting to tech nerds and geeks ;) I've dabbled with machine code and am interested in the "pck-bally" kit Okaegi created for re-programming the original Bally ROMs. Only thing that's prevented me thus far is investing in an EPROM programmer.

Hang on... just reading over that page... his library has support for S&T boards... I wonder if there's any info embedded in there about what the MPU sends to the S&T...? :rolleyes:
 
My plan to inject the -12VDC at the base of C38 works, so it's possible to run an S&T off an ATX PSU using just the +12VDC and -12VDC supplies:


Sounds as though these MR & PRS PAC-MAN ROMs are working!
 
All sounds ok, maybe a little tinny/scratchy, but that will be the filtering/amp end.

A few things to note about the sound effects section are:

1) if the AY-8912 ic is used (which it is for pacman), you will have 5 flashes on boot
2) if its not used, and jumpered to ignore it, then you'll only have 4 flashes.
3) installing the chip and not jumping it accordingly will stop a board not using it from booting fully.
4) If it is installed the background sound drone is generated by this chip and all other effects by the ADC ic
5) If it isn't installed the ADC ic does all sound effects.
 
Hacked a very quick Arduino sketch following the specs as laid out in the FO 560-3 REPAIR MANUAL...

farm1.staticflickr.com_655_22175938380_9de743aab9_z.jpg

Not surprised it didn't work! I'm guessing you've done pretty much the same but basically after setting all data lines LOW, the interrupt line HIGH and waiting for 5 seconds so the S&T can finish booting in the setup() :

void loop() {
delay(3000);
digitalWrite(ledPin, HIGH);
digitalWrite(soundInterrupt, LOW);
delayMicroseconds(40);
digitalWrite(soundInterrupt, HIGH);
delayMicroseconds(22);
digitalWrite(soundSelect1, LOW);
digitalWrite(soundSelect2, LOW);
digitalWrite(soundSelect3, LOW);
digitalWrite(soundSelect4, LOW);
delayMicroseconds(145);
digitalWrite(soundSelect1, LOW);
digitalWrite(soundSelect2, LOW);
digitalWrite(soundSelect3, LOW);
digitalWrite(soundSelect4, HIGH);
delayMicroseconds(78);
digitalWrite(ledPin, LOW);
}

I don't get a squeak from the S&T. Next step is to put the board back in VECTOR, attach 2-channel oscilloscope to the sound interrupt line and least significant data line, press a playfield switch to trigger a sound and see what the MPU is actually sending the S&T!

One thought, but I can't imagine it's that critical is that digitalWrite(HIGH) takes about 3.3us and digitalWrite(LOW) takes about 3.5us.

Will try switching to C-based operations as they're about 20 times faster.
 
Last edited:
Hacked a very quick Arduino sketch following the specs as laid out in the FO 560-3 REPAIR MANUAL...

farm1.staticflickr.com_655_22175938380_9de743aab9_z.jpg

Not surprised it didn't work! I'm guessing you've done pretty much the same but basically after setting all data lines LOW, the interrupt line HIGH and waiting for 5 seconds so the S&T can finish booting in the setup() :

void loop() {
delay(3000);
digitalWrite(ledPin, HIGH);
digitalWrite(soundInterrupt, LOW);
delayMicroseconds(40);
digitalWrite(soundInterrupt, HIGH);
delayMicroseconds(22);
digitalWrite(soundSelect1, LOW);
digitalWrite(soundSelect2, LOW);
digitalWrite(soundSelect3, LOW);
digitalWrite(soundSelect4, LOW);
delayMicroseconds(145);
digitalWrite(soundSelect1, LOW);
digitalWrite(soundSelect2, LOW);
digitalWrite(soundSelect3, LOW);
digitalWrite(soundSelect4, HIGH);
delayMicroseconds(78);
digitalWrite(ledPin, LOW);
}

I don't get a squeak from the S&T. Next step is to put the board back in VECTOR, attach 2-channel oscilloscope to the sound interrupt line and least significant data line, press a playfield switch to trigger a sound and see what the MPU is actually sending the S&T!

One thought, but I can't imagine it's that critical is that digitalWrite(HIGH) takes about 3.3us and digitalWrite(LOW) takes about 3.5us.

Will try switching to C-based operations as they're about 20 times faster.

This is the method i wrote for control of the double nibble

https://github.com/mypinballs/bally...es/BallySoundTester/BallySoundTester.cpp#L179
 
One thought, but I can't imagine it's that critical is that digitalWrite(HIGH) takes about 3.3us and digitalWrite(LOW) takes about 3.5us.

The timings are all pretty exact in the bally tech notes and are at a microsecond count, so maybe we have to adjust for the command operation lengths with any delays? It could be that the board is ignoring them as the overall length to receive the first/second nibble is too long?
 
Hey, Jim. I got it working!

After spending several hours with a dual channel oscilloscope analysing the data signals being sent to the S&T from the MPU I came to realise that the data timings in the Bally REPAIR PROCEDURES manual FO 560-3 are not altogether accurate! With the correct timings in hand I reprogrammed my Arduino MEGA2560 to replicate the signals. Only a very quick and dirty test passing in two different nibbles (I think this is what I was passing - I don't have the code to hand): 0000+1000 and 1000+1000. Seems as though I've triggered a sound effect and a speech effect. Nice!

First up, the data lines A, B, C and D, are always HIGH (1) unless a LOW (0) is required during the 145us and 78us nibble data slots. Extra data line E is always low on VECTOR. The Sound Interrupt data line is obviously always high too as it's the 40us LOW that triggers a sound.

The initial 40us LOW on the Sound Interrupt line starts with a nice clean almost instant drop to 0V but actually starts to rise at about 30us and is a distinct curve rising back to 5V HIGH after about 36-38us.

Then comes the 22us delay before the LSN (Least Significant Nibble) but what I noticed is if the data is 0 the drop has actually occurred around 50us after the interrupt dropped LOW rather than the stated 62us (40+22) later.

The LSN should stay LOW for 145us which it seems to if a 0 then 1 is sent but the biggest surprise was that when an LSN 0 is followed by a MSN (Most Significant Nibble) 0 the totally low time is way longer than 223us (145+78) and is more in the region of 2,000us!!!

I've got screenshots of all this including some very interesting goings on during the MPU boot sequence but you'll be pleased to know that no initialisation of the S&T by the MPU is required.

More to come but in the meantime please enjoy a video of my simple test sketch:

 
Last edited:
Hey, Jim. I got it working!

After spending several hours with a dual channel oscilloscope analysing the data signals being sent to the S&T from the MPU I came to realise that the data timings in the Bally REPAIR PROCEDURES manual FO 560-3 are not altogether accurate! With the correct timings in hand I reprogrammed my Arduino MEGA2560 to replicate the signals. Only a very quick and dirty test passing in two different nibbles (I think this is what I was passing - I don't have the code to hand): 0000+1000 and 1000+1000. Seems as though I've triggered a sound effect and a speech effect. Nice!

First up, the data lines A, B, C and D, are always HIGH (1) unless a LOW (0) is required during the 145us and 78us nibble data slots. Extra data line E is always low on VECTOR. The Sound Interrupt data line is obviously always high too as it's the 40us LOW that triggers a sound.

The initial 40us LOW on the Sound Interrupt line starts with a nice clean almost instant drop to 0V but actually starts to rise at about 30us and is a distinct curve rising back to 5V HIGH after about 36-38us.

Then comes the 22us delay before the LSN (Least Significant Nibble) but what I noticed is if the data is 0 the drop has actually occurred around 50us after the interrupt dropped LOW rather than the stated 62us (40+22) later.

The LSN should stay LOW for 145us which it seems to if a 0 then 1 is sent but the biggest surprise was that when an LSN 0 is followed by a MSN (Most Significant Nibble) 0 the totally low time is way longer than 223us (145+78) and is more in the region of 2,000us!!!

I've got screenshots of all this including some very interesting goings on during the MPU boot sequence but you'll be pleased to know that no initialisation of the S&T by the MPU is required.

More to come but in the meantime please enjoy a video of my simple test sketch:


Interesting. Post your example code so i can see the timings you were using in more detail. I'd like to try this on the later roms for the computer sound board. If the manual is wrong, or out of spec then that is pretty annoying to say the least! Why write a tech manual that is useless?

Note regarding the 5th select line. As i was mentioning earlier, the 5th select line is tied low for s&t boards by the cabling, as shown in the manual here (this is an ebd manual). They don't include this on the s&t schematic (nice!)

IMG_4468.jpg

so as you saw will be low all the time. This is because of the 7 segment displays are using it for the 7th segment, which is what started this whole project and investigation!!!! :)
 
WARNING! WARNING! HEAVY DUTY TECHNO-BABBLE ALERT! ;)

Here's what I found out using my Hantek6022BE Series dual-channel USB oscilloscope about the data signals sent by the A4 MPU to the S&T board.

Below is the basic sequence at power on. The SOUND SELECT channel (also the SOLENOID BANK SELECT) goes up to about 1.4V for around 4.6 seconds until the MPU completes "boot up" and does the 7 flashes of the diagnostic LED. At the same time all the SOUND DATA lines go fully HIGH to about 4.4V. When the SOUND SELECT goes fully HIGH at ~4.6s there some random oscillations on the DATA lines then all HIGH pause of about 2 seconds until some further data at about 7 seconds after power on at which point the first sound is triggered - in this case it's the VECTOR speech sample "I am a P. A. C. Play Analysis Computer":

farm6.staticflickr.com_5690_22218656539_f891ced825_c.jpg

Looking a bit more closely at what happens at "MPU Boot Complete" there's a brief period where the SOUND DATA lines go into a momentary state of oscillation. Maybe the MPU is still configuring the final state of the PIA I/Os? There's a breif 100μs LOW on the SOUND SELECT with a corresponding 200μs pause on the data lines after which they start to oscillation again at ~1.44kHz at a higher voltage.

farm6.staticflickr.com_5775_22379494456_8ea4822523_c.jpg

farm6.staticflickr.com_5657_22416319441_f6cdc41793_c.jpg

Further along the timeline at around the 7 second mark we start seeing what look like proper data messages. There's a whopping 4.6 millisecond LOW on the SOUND SELECT followed by a 2.65 millisecond LOW on the SOUND DATA lines. After this there appear to be 3 sound messages. The first 2 don't appear to be the triggers for the speech sample (I did a rudimentary timing comparison against the audio output which seemed to match the third message) so at this stage I'm guessing these are COMMAND messages where the MPU is sending AUDIT volume control data for the sound and speech channels (ignored on this S&T which uses hardware volume control):

farm6.staticflickr.com_5704_22405470915_d346faf333_c.jpg

Next the nitty-gritty of a sound message. Here I've triggered the "VECTOR" speech sample by pressing the shooter lane roll-over switch which is active even in attract mode. I've gone all fancy with my graphics and overlaid a scaled copy of the S&T timing chart from the Bally REPAIR PROCEDURES FO 560-3 manual. As you can see it's close but not exactly the same. The 40μs "play sound" LOW trigger on the SOUND SELECT line is a little shorter at about 36-37μs, nothing major there, but the 22μs pause before setting the LSN (Least Significant Nibble) data is noticeably shorter because here the SOUND DATA (A) line has gone LOW (0) after just 15μs. The next difference is that the LSN only appears to stay in this state for around 125μs, not 145μs. In this case the SOUND DATA (A) doesn't change again so I assume the bit in the MSN (Most Significant Nibble) is HIGH or 1:

farm1.staticflickr.com_633_22217775308_65dd45e896_c.jpg

The bit I don't understand is the significance of the 70μs gap marked on the timing chart? Does this indicate there could be a 70μs delay between changing from the LSN to MSN data? I suppose the switch from LSN to MSN could occur at 35μs (70μs/2) before the end of the 145μs block, i.e., as early as 110μs after setting the LSN, which does roughly align with the chart.

So far, although a little different we're within the boundaries of acceptance. You can imagine the AY3-8912 PSG latching the LSN and MSN data within those time scales. The strange part happens when we see a LOW (0) bit on the MSN. From the timing chart we'd expect to only see it low for 78μs but check this trace below of the SOUND SELECT (D) channel for the same "VECTOR" test sound.

The SOUND DATA (D) stays LOW for massive 4,323μs! I've included the TIMING CHART again to scale but as you can see it's tiny! In this test the LSN was HIGH (1) and dropped LOW (0) for the MSN 140μs after the SOUND SELECT. This is at exactly the same time (140μs = 15μs + 125μs) the MSN went HIGH (1) on the SOUND DATA (A) line:

farm6.staticflickr.com_5834_22379494016_70b7d3f354_c.jpg

This means the entire message time is 37μs + 15μs + 125μs + 4,232μs =4,500μs. Whoa! 4.5ms. That's a lot longer than the documentation appears to indicate.

This begs the question: what happens if another sound event it triggered within the 4.5ms? Say the ball rockets back and forth between a pair of pop-bumpers? Or do you think the MPU simply wouldn't trigger sounds down to that sort of resolution? If sound messages are 4.5ms long that's still over 200 messages per second! Way more than needed ;)

So, armed with all this empirical data I shall now further refine my nasty Arduino sketch! I'm going to switch to using C instead of functions (as this will allow finer control of timing), hook up a 2x16 LCD test display and keypad to view data and do manual triggering.
 
Last edited:
Not the most riveting video to watch but here's a film of the next version of my Arduino Bally Sound Tester.

It was supposed to play sound 0 to 32 in 5 second intervals but after uploading I realised I'd messed up my bit-shifting and it's not playing the right sounds because it's not passing the binary data as shown.


After this I fixed my schoolboy coding error and got it running a loop to plays sound up to number 255. I also made the hold time of the Most Significant Nibble closer to 4,000us to match what I measured with the oscilloscope.

I then retested using my VECTOR board which played sounds up to number 78 which ended with the classic "Hit the showers!"
 
Back
Top Bottom