(Topic ID: 288981)

55516 vs 55564 and WMS Sound + Speech ROMs

By barakandl

7 months ago


Topic Heartbeat

Topic Stats

  • 29 posts
  • 5 Pinsiders participating
  • Latest reply 7 months ago by Quench
  • Topic is favorited by 2 Pinsiders

You

Linked Games

Topic Gallery

View topic image gallery

Untitled (resized).png
20210310_160941 (resized).jpg
20210310_160900 (resized).jpg
Sys7_Speech.png
Untitled (resized).png
20210302_015756 (resized).jpg

#1 7 months ago

* edit the BK roms are fine, it was the speech chip, 55564 does not seem to be compatible with Black Knight and Alien Poker. Alien poker uses sound 3. see post 3 for 55516 vs 55564 *

Going through all the WMS sound and speech ROMs on IPDB and I have encountered a few issues. Most system 7 game downloads come packed with "sound 12" but I have found about eight different versions with the same "Sound 12" label. The manuals make mention of sound 5, sound 6, etc. Most on IPDB seem to be the right data but I have two sets I can't get to work right.

Alien Poker. On IPDB one ROM pack comes with "SOUND 2". A different IPDB ROM pack download comes with "SOUND 3". The manual says sound rom should be "white labeled", does that mean unique data for AP? When I pair sound 2 with the AP speech ROM I get no speech in test mode, speech is skipped. When I pair the AP speech ROMs with sound 3 I get silence during when speech should be playing in test mode. Same behavior with English Speech or French Speech ROMs. I am guessing this game has a unique sound ROM? Does anyone know what sound ROM goes with Alien Poker and any issues with the IPDB rom packs?

Black Knight. All IPDB ROM pack versions come with the same "sound 12". Manual says it should be "SOUND 5". In test mode I get silence when speech should be playing. In game mode I get some static at times speech should play. I think the sound ROM is right as I recognize some of the sound effects even tho I am testing in a firepower. If I use the French black knight speech ROMs it talks fine, I only get silence with the English black knight speech ROMs. Has anyone had trouble or success with the IPDB BK speech ROMs?

All the other game sound/speech ROMs from IPDB seem to be working ok. If you ever wanted to know what Thunderball speech sounded like...

BK SOUND 12 = DD2F
BK VIC4 = 07B5
BK VIC5 = DEE5
BK VIC6 = 0C08
BK VIC7 = DCB8

SOUND 3 = BDCA
AP VIC4 = NOT USED
AP VIC5 = 17B0
AP VIC6 = 6DE0
AP VIC7 = 0329

#3 7 months ago

So it turns out 55564 is not directly compatible in all cases with 55516. Black Knight and Alien poker do not work with 55564 but all the other system 6 and 7 talking games seem to be ok with 55564. I desoldered a 55516 off of an original speech card and then Black Knight started talking just fine. I got 55564 from Rochester Electronics in two batches so they should be legit. Both are 55564-5 in plastic dip with one batch is 99 date code the other 96. I found one 55564 that tries to work if the temp is under about 70f. It starts out ok but within a few minutes, it heats up, becomes, garbled, and eventually goes silent. Hit the chip with cold spray and it starts to work again until it gets back to about 70f then it shits out again.

I just spent a bunch of money on 55564 that seems like it will not work in all games which sucks. There is a system 11 service bulletin for this speech chip I may try. Looks like it isolates pin 1 from +5v with a resistor.
https://www.ipdb.org/files/1308/Williams_1988_Jokerz_William_Service_Tip_For_Audio_Hum.pdf

If that does not work Black Knight and Alien Poker will not be supported by the replacement sound board until / if I find can 55516.

Alien Poker uses Sound 3, not Sound 2.
20210302_015756 (resized).jpg

#4 7 months ago

Have you tried the more simple HC-55536?
The 55536 is the exact same part but for decoding only, there is no internal encoder. The Williams boards did not use the encoder.

There is essentially no difference between the three parts -- 55516, 55532 and 55564 except for the speed of the DAC/ADC & other analog circuitry. As the parts moved along in years, the circuitry got faster allowing higher conversion rates and clearer text. But Williams never took advantage of that.

But based on your description of how one part kind of works at lower temps and one doesn't at all, I have seen this before and I believe you have a timing problem. As parts got capable of faster rates, they also got pickier on the data/clock relationship.
Compare the data/clock relationship going into the CVSD. Ideally, the clock should be rising edge mid bit in relationship to the data (also known as a "180 degree clock"). And the clock must have a 30-70% duty cycle.
If your clock edges are too close then you may need to skew (or invert) your clock into the CVSD.

Here's the differences between the CVSDs from an old post:
HC-55516 (~1975) -- encoder and decoder, optimized for 16kbps rate (replaced by 55532)
HC-55532 (~1977) -- encoder and decoder, optimized for 32kbps rate (replaced by 55564)
HC-55564 (~1986) -- encoder and decoder, optimized for 64kbps rate (replaced by nothing)
HC-55536 -- same as HC55564 but decoder only.
All of these were intended for voice and not music so they all have a pretty bad bandwidth.

Few extra digits added "x" and "y"
HCx-55564-y

x = package
1 = ceramic DIP package
3 = plastic DIP package
9 = SOIC (surface mount) package

y = temperature range
2 = -55 to 125C
5 = 0 to 75C
9 = -40 to 85C

And for those that are interested in the prefix.
HA = Harris Analog
HC = Harris Communications
HD = Harris Digital
HM = Harris Memory
HI = Harris Interface

#5 7 months ago
Quoted from barakandl:

There is a system 11 service bulletin for this speech chip I may try. Looks like it isolates pin 1 from +5v with a resistor.
https://www.ipdb.org/files/1308/Williams_1988_Jokerz_William_Service_Tip_For_Audio_Hum.pdf

This separates the analog power from digital power to remove digital noise on VCC line from being introduced into the analog circuitry.
The proper method to do this is to add an LC low-pass filter to the input of the CVSD. I would consider doing that to avoid noise problems in the future.

#6 7 months ago

I went with the 55564 because it was the only one I thought I could find NOS in bulk from a reputable place (~$7ea rocelec.com, they have like 10k). I actually did not even think to look at GPE for whatever reason but I see you have the 55532. I have not tried 55532 yet but I have a few system 11 games with a harris speech chip. I will look to see if any are 55532 to try as I seem to remember seeing them used by WMS. If 55532 works without changing anything else I may be trying to buy a large number from you. I will also compare the speech clock/data and see if I notice differences in BK and AP from the rest later. Maybe there is something easy I can still do to make 55564 work.

This sound board is doing great in regards to hum and noise, specially compared to later sys 9 and 11 games which always have lamp switching noise. The separate transformer tap and 12v supplies probably have a lot to do with it. I will check out the low pass filter too for the future though too.

#7 7 months ago

Doing a combo board is great because the biggest failure point when I was doing repairs was almost always the ribbon cable. Followed close behind by the op-amps, sockets were third.

Did you design it to also be compatible with the various ROM sizes for video games? Those boards were pretty common in Williams video games in the era as well, more often without speech.

-Hans

#8 7 months ago
Quoted from HHaase:

Doing a combo board is great because the biggest failure point when I was doing repairs was almost always the ribbon cable. Followed close behind by the op-amps, sockets were third.
Did you design it to also be compatible with the various ROM sizes for video games? Those boards were pretty common in Williams video games in the era as well, more often without speech.
-Hans

Yep! The combo sound ROM is built around 32K of space. For 16K games the first half can be filled with FF and then the game data goes in the upper half. Just doubling the data seems to work fine too.

That ribbon cable with the tight bends for sure the single most commonly failure point of the sound + speech boards I encountered.

#9 7 months ago

I am going to have to order a 55532 to test with. I could not find any around the house.

I checked and the BK, AP, AP French 55564 compatibility issue exists on the original hardware too. BK and AP cannot use 55564. Not sure about 55532 yet.

I found a HC3-55564 I wrote BAD on the tube it is in some time ago. I just tested it and it actually works fine. I must have been trying to use it in BK as that game was pretty popular when I fixed boards.

#10 7 months ago

I'm willing to bet the part wasn't bad and that there is a timing issue with the board.
You said it works with some ROMs but not others. I'll bet the software delay between change of data and rise of clock has changed.

Do you have a dual trace scope that you can get a picture from? Would be interesting to see both data and clock for a ROM version that works and ones that does not work. Primary point of interest is what happens to the data just prior or just after the rising edge of the clock.

Another thing to try as a test (but not a fix) -- hang a tiny cap such as a 22pF between clock and ground at the CVSD.

#11 7 months ago
Quoted from G-P-E:

You said it works with some ROMs but not others. I'll bet the software delay between change of data and rise of clock has changed

I had a quick look at the software yesterday comparing Black Knight to Jungle Lord.
Jungle Lord raises the speech clock line (6821 CB2) high, then clears it two instructions later.
Black Knight uses features of the 6821 to synchronise the CB2 speech clock pulse against the "E" clock from the CPU and a port B write. This method looks like the clock signal is opposite phase compared to Jungle Lord.
A cursory look at the generation of the speech data signal was also different.
Suffice to say they are rather different from a software perspective.

#12 7 months ago
Quoted from G-P-E:

I'm willing to bet the part wasn't bad and that there is a timing issue with the board.
You said it works with some ROMs but not others.

Yes, it works fine. Has a mid 80s date code and behaves just like the 90s ones as expected I guess.

Quoted from G-P-E:

I'm willing to bet the part wasn't bad and that there is a timing issue with the board.
You said it works with some ROMs but not others. I'll bet the software delay between change of data and rise of clock has changed.
Do you have a dual trace scope that you can get a picture from? Would be interesting to see both data and clock for a ROM version that works and ones that does not work. Primary point of interest is what happens to the data just prior or just after the rising edge of the clock.

My dual trace scope is an old school cathode ray. I guess I can take pictures of it. I have been meaning to buy a new digital one I can do things like export pic snapshots. When I need something quick i have a hand held scope (single trace) and rarely get the old CRO beast out.

Quoted from G-P-E:

Another thing to try as a test (but not a fix) -- hang a tiny cap such as a 22pF between clock and ground at the CVSD.

Hot damn, you are onto something there. Held 27pF straddled across the chip legs and speech comes in but it is really scratchy. I grabbed a 150pF and then it talked and sounded fine.

#13 7 months ago
Quoted from barakandl:

My dual trace scope is an old school cathode ray. I guess I can take pictures of it. I have been meaning to buy a new digital one I can do things like export pic snapshots. When I need something quick i have a hand held scope (single trace) and rarely get the old CRO beast out.

Hot damn, you are onto something there. Held 27pF straddled across the chip legs and speech comes in but it is really scratchy. I grabbed a 150pF and then it talked and sounded fine.

Yeah, my old 2465A scope can't do that either. If I want pix, I gotta take it into work or use a camera.

The cap on the clock suggests that the changing edge of the data and rising edge of the clock are too close together. This is a common timing design error that seems to be rampant on some of the Williams boards (Gottlieb is worse) -> violation of setup and hold times. Adding the cap pushes the clock back in time a hair which is a good thing. But the addition of the cap also increases rise time of the clock - which is not a good thing.
There is probably a very small change in the data to clock delay in the Williams software - quicker delay for the versions that don't work, longer delay for the versions that do work. And only the parts with the faster response time are affected. This means the clock should be delayed. But by how much? Need to see a good data/clock scope trace compared to a bad data/clock scope trace. If you ran the incoming clock through two logic gates for a delay then you would probably be fine but it would be good to physically see how much delay is really needed. Also need to make sure that the newly added delay doesn't bugger with the versions that already work.

What Quench said supports this - they mucked with the clock on these versions and I believe they have the data and clock edges too close to each other.

#14 7 months ago

Delaying the clock with a capacitor is a good fix, but I suggest inserting a series resistor so that the clock driving PIA pin doesn't get overloaded by added capacitance. Probably a 220 ohm resistor would be fine, then also the capacitor value could be reduced - maybe 100 pF would do it?

#15 7 months ago

Proper method is to align the clock properly and not add an RC curve to the clock line.
Figure out what the difference is and correct it properly to work with both versions of software.

#16 7 months ago

True. But that would require either modifying the SW, or adding more circuitry to clock line. I agree that the RC delay should be followed by a Schmitt trigger to square the clock and ensure it works in wide temperature and supply voltage range.

But if the added capacitor makes it OK for the original poster, then it is good enough for him.

#17 7 months ago

Adding a capacitor to a clock line is a kluge to fix an existing timing design error. If this was to fix a 30 year old board then I would be fine with that. But this problem is occurring on brand new boards - a kluge to fix a simple problem with new boards is not a good answer.
Biggest problem with this type of fix is unpredictability - a capacitor size that works for one board might not work for the next board (e.g IC 10 is 6821 on one board at 26C and 68B21 on another at 21C). Add in an RC curve to the clock and this is asking for trouble in the future.
The best way to tackle this with a new board is to verify the the timing being received by both sets of software and regenerate both data and clock lines so both timing types work properly with the CVSD. That is often a simple fix and done with a pair of inverters and a D-type flip flop.
It's easy to do but we need to determine what the current data/clock relationships are from the 6821, we already know what it is supposed to look like from the CVSD.

Quench - did you notice how the CRB was setup within the 6821? This would be based on the value written to the "B" control register.
I'm guessing the software that worked was setting the CA2 value first then setting the CB2 value high and then returning the CB2 value to low two instructions later. That method gave the programmer complete control of the data and clock timing.
For the software that doesn't work - they removed software control of the clock timing and gave it to the 6821 to control and obviously the faster CVSDs don't like it. That means the data/clock relationship is on the edge of the acceptable range.
Hard to determine which CB mode they are using without knowing the CRB setup value. But based on your description - it sounds like it may be CRB = 0xF7. If so - the clock is upside down but still difficult to determine where the data edges are. Not enough info to tell yet.

#18 7 months ago

I wonder if this may have also played a part in the issues that Rottendog was having with their boards and speech issues on Black Knight. Since it was the first game to use the blue rom set, and the dedicated sound PIA as opposed to solenoid drivers. Let's be honest, the entire electronic sound system on Williams games was a complete kludge from day one up until WPC.

-Hans

#19 7 months ago

200pF on three boards and all software is working fine across wide temperature. I can take the cap in and out of circuit on the as is working games like FirePower and there is no change in the speech sound / quality. Using HD6821P right now, will try 6820, 68A21 and 68B21 but guess it will work fine with any of them.

0.3¢ cap fix and calling it a day to work on other projects is tempting. I can hide the cap under the speech socket until next board revision. I do have two unused 4069 inverter gates on the other side of the PCB, but pretty sure I could make the route work. I guess I can Frankenstein a board with extra inverters in line to see if that helps instead of a cap.

It seemed like Rottendog had a MPU sound trigger PIA problem. This issue should not be related to Rottendog's BK problem the way I am thinking about it. Sound triggers are well separate from the CVSD clock/data, different CPU and PIA controlling it. Rottendog also emulated the CVSD chip on system 9/11 which does not sound as good at the real thing (which already is low quality).

Can tell WMS got better at coding the speech. FirePower is pretty crappy speech compared to later game like Thunderball, unless they where going for a compressed CB radio type of effect. WMS had multiple people working on the speech software. A lot of them snuck their name or initials visible in ASCII in U4 or U6. Saw at least three different names. One guy may have done things differently than others.

I wonder what Paul D. is up to.
Untitled (resized).png

#20 7 months ago

** KLUGE **

Can be fixed properly with a quarters worth of parts.

#21 7 months ago

All we need is a pair of images to compare data edge to clock edge. With that - it can be fixed properly
And the fix may be as simple as running through two inverters to introduce the delay. Problem is - we don't know how much delay we can deal with.

#22 7 months ago
Quoted from G-P-E:

Quench - did you notice how the CRB was setup within the 6821?

Yes. And before you ask, I replicated the Jungle Lord clock code into Black Knight but it didn't work off the bat under emulation (voice went missing). Other code around it is not the same.

Just a reminder, barakandl said the problem also occurs on original boards with a 55564. It's not specific to his new board.

Sys7_Speech.png

#23 7 months ago
Quoted from Quench:

Yes. And before you ask, I replicated the Jungle Lord clock code into Black Knight but it didn't work off the bat under emulation (voice went missing). Other code around it is not the same.
Just a reminder, barakandl said the problem also occurs on original boards with a 55564. It's not specific to his new board.

Jungle Lord code is simple enough to follow.
But I don't see actual the clock trigger (data reg B write) on the Black Knight code.
I see it setup for that mode, I see the CVSD data value get set but I don't see the write to trigger the clock (B Data Register Write).

That code follows what you said earlier. When the code sets CRB5-CRB3 to "101":
CB2 Cleared: Low on the positive transition of the first E pulse after an MPU Write "B" Data Register operation.
IAW -- the clock is pulled low at this time.

CB2 Set: High on the positive edge of the first E pulse following an E pulse which occurred while the part was deselected.
IAW -- the clock is pulled high at this time. The rising edge is when the data is actually written into the CVSD.
As long as the CPU sets the data before the trigger AND holds the data until after this rising edge then it *should* work.
But obviously we are missing something.

Based on release timing - Williams introduced BK and Alien Poker at about the same time with the same bugs and while 55532s were widely available.
After this - they introduced Jungle Lord and fixed the code so obviously they knew about this.

As far as both old and new boards doing this - yes, I know. He copied the old bug into the new design.
This is an implementation bug - both software and hardware related. If they create the clock themselves, it works fine with the faster parts. If they use the 6821 to create the clock, it does not work with faster parts. Problem is there are plenty of faster parts out there and locking the design into the slower parts may not be a good thing to do. He either needs to fix the code or fix the hardware. Fixing the hardware is probably easier than rewriting the code.

First thing barakandl needs to do is obtain a simple logic analyzer such as Sigrok:
https://www.sparkfun.com/products/15033?_ga=2.167448828.355327918.1614970800-38432262.1607974606
https://www.sparkfun.com/products/9741
Sigrok module is pretty limited and probably won't catch spikes but should get a majority of the picture.

Get lots of samples of the data and clock lines of both good boards (CPU creates clock) and bad boards (6821 creates clock). This is the only way we can see what is truly happening between the data and clock lines and how to fix it properly.

#24 7 months ago
Quoted from G-P-E:

He copied the old bug into the new design.
This is an implementation bug - both software and hardware related.

It is a software bug. Quench will have more info about the software.

My made in west Germany hameg scope seems to have died so I picked up a Siglent, maybe two of them.

Yellow is speech clock.

BK Stock software
20210310_160900 (resized).jpg

FirePower
20210310_160941 (resized).jpg
Untitled (resized).png

#25 7 months ago

Curious - what is the time scale on these? 20uS/division?

I don't see how you can definitively call what appears to be a spike for a clock to be a software error.
*As shown* that is an invalid clock into the CVSD (AKA hardware error). This error *can* be fixed with software.
This makes it an implementation error - as currently implemented it is a hardware error and it can be fixed with either hardware OR software.

************* Option 1 - fix the hardware ********************
Piss poor data sheets for the CVSDs, what kind of dummies did Harris hire during this period? Oh, yeah...never mind.
The only thing Harris specified is the data setup time. They don't specify many timing critical values such as clock low minimum and clock high minimum times, duty cycle or anything else. These are needed for a dog slow device that uses both edges of the clock internally. Attaching that cap in your earlier post is both delaying and widening the clock pulse period. It appears that the widening of the pulse is what fixes the issue. Too small of cap = insufficient pulse width, too large of cap and the VIL to the CVSD may not go low enough. Strictly putting a cap on a clock line is a kluge and may not work for certain combinations of components as well as different temperature ranges. And the cap on the clock would look to be more of a triangle than a square wave - not good for a device that uses both clock edges for operation.

You can *reliably* fix that entirely in hardware so that it would work with both of those clock sources. But to properly fix this, you would need to revise your design. There's a number of ways you can fix this but probably the easiest is to simply recreate each clock pulse based on the rising edge:
For example, use a 74HCT123. Tie the A* input Low, tie the B input high and tie the PIA clock into the R* input. Q output pin becomes your new clock. You just need to calculate the RC time constant. I would base the pulse width based on the Firepower clock width, maybe a hair longer.

************* Option 2 and the preferred method of fixing this - fix the software ****************
Leave the hardware and revise the software to use the CPU generated clock as done by Firepower.
You may need to use a disassembler, modify the code and reassemble -- the software to do this is in public domain.
To avoid massive amounts of pointer changes, I would probably take a small window of unused memory - add in the Jungle Lord code into that window, find all calls to the CVSD data write and change the pointer to the new code segment.

*****************************

And lastly -- look into using 55536 (not 55532) CVSDs which are more widely available.

#26 7 months ago
Quoted from G-P-E:

Curious - what is the time scale on these? 20uS/division?
I don't see how you can definitively call what appears to be a spike for a clock to be a software error.
*As shown* that is an invalid clock into the CVSD (AKA hardware error). This error *can* be fixed with software.
This makes it an implementation error - as currently implemented it is a hardware error and it can be fixed with either hardware OR software.

Splitting hairs here but the software is what screws up the clock. Every other software works... so I will call that software bug. The hardware works fine with patched software which quench will have more info on.

Adding extra hardware to fix the software problem is a route that thankfully I will not have to go down.

20us time

#27 7 months ago
Quoted from G-P-E:

I don't see how you can definitively call what appears to be a spike for a clock to be a software error.

The first two Black Knight instruction descriptions I posted above explain how the 6821 CB2 signal is pulsed for the CVSD clock signal (taken from the 6821 datasheet). The pulse ultimately takes a period of one CPU E clock. A 3.58MHz crystal is hooked up to the 6802 CPU which internally divides it by 4 resulting in the E clock signal having a period of about 1.1us. That's the time length of the CB2 low going pulse to clock the CVSD in the Black Knight waveform shown above.
This is an unforeseen implementation issue for the 55536/55564 but like you said, poor Harris datasheets probably didn't help.

barakandl now has working software fixes based on manually changing the PIA CB2 state like Jungle Lord. Interestingly, Gorgar which was the first Williams game with speech is what Jungle Lord CVSD code was based on. So they did it correctly to start with.
Black Knight and Alien Poker were likely done by a different programmer to the other speech games as these two also implemented the ability to change voice pitch, both of which have the issue with 55536/55564.

The challenges are that Black Knight has no free ROM space, and the instruction cycle count needed to be maintained in order to keep the voice pitch the same since the software loop for spitting out the data stream to the CVSD is CPU execution timed. But it was managed.

Another minor software error they made was at the very start of any spoken word, the clock signal is pulsed *before* the first valid speech bit is applied to the CVSD data input.

#28 7 months ago
Quoted from Quench:

Another minor software error they made was at the very start of any spoken word, the clock signal is pulsed *before* the first valid speech bit is applied to the CVSD data input.

Curious - do you actually see them hit the clock before the first bit? Or is this a remnant of the nasty looking inverted clock?
In second photo of post 24 - it shows rising edge of clock followed within the same data bit by a falling edge of clock.
In first photo of post 24 - it shows rising edge of clock but the falling edge doesn't occur until next data bit.
I do know these devices used both clock edges but don't remember how - my memory is shot and the datasheet is unclear.

Based on the 20uS scope time base - it appears to be clocking about every 85mS or so (eyeballed from above photos). That comes out to nearly 12KHz for clock rate... that's not exactly 'high fidelity'. But, hey, back in 1980 - "it talks!".
We used these in digital voice communications long ago (back when electronics was still 'fun'). We had dedicated satellite links between Omaha and Thule and ran these at 28.8Kbps and 14.4Kbps (depending on available bandwidth at the time). Conversations at 14.4K weren't very good but still usable. At around 16K - you could start to hear huge differences in audio quality with increase in sample rate. If you get the CVSD to run in the 20K or more range then it actually sounds quite good.
If we could only get the original Black Knight sound tracks resampled at 32Kbps... store triple the amount of data and rewrite the software to play back at that rate. Easy, peasy - right?

#29 7 months ago
Quoted from G-P-E:

Curious - do you actually see them hit the clock before the first bit?

Yes. Both implementations update the clock and if all data bits are processed then exit, otherwise apply a data bit and loop back to the clock update. This is slightly simplified but there is one extra CVSD clock pulse at the very beginning of every word stream. All speech is broken up into single words so they could create multiple phrases by grouping different words.

See below - the extra first CVSD clock will have a different effect because of the different clock phase between say Black Knight and Jungle Lord. Of course the error is not perceivable being only a single output bit step.

Quoted from G-P-E:

I do know these devices used both clock edges but don't remember how

The 55564 data sheet says the data bit is strobed in on the rising edge of the clock. On the falling edge of the clock, the 55564 output is updated.

Quoted from G-P-E:

Based on the 20uS scope time base - it appears to be clocking about every 85mS or so (eyeballed from above photos). That comes out to nearly 12KHz for clock rate... that's not exactly 'high fidelity'. But, hey, back in 1980 - "it talks!".

Heh, only two years before there were still games with mechanical chimes/3 simple electronic tones being manufactured. Things were changing fast.

Quoted from G-P-E:

If we could only get the original Black Knight sound tracks resampled at 32Kbps... store triple the amount of data and rewrite the software to play back at that rate. Easy, peasy - right?

We wish!

Hey there! Got a moment?

Great to see you're enjoying Pinside! Did you know Pinside is able to run thanks to donations from our visitors? Please donate to Pinside, support the site and get anext to your username to show for it! Donate to Pinside