(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

You're currently viewing posts by Pinsider G-P-E.
Click here to go back to viewing the entire thread.

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

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

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

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

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

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

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

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

#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?

You're currently viewing posts by Pinsider G-P-E.
Click here to go back to viewing the entire thread.

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