Butler in a Box reverse engineering and repair

[kevtris]

Fellow forum goer NeXT sent me his Butler in a Box that needed some help so I can take a look and trace the schematic out and attempt a repair. His original thread is here:

Thread 'Secrets Within: The brains of the Butler in a Box'

Jul 1, 2023

Way back in 2017 I followed up on by first entry into Mastervoice and their Butler in a Box ( https://forum.vcfed.org/index.php?threads/stuck-in-the-80s-mastervoices-butler-in-a-box.1070062/ ) with their follow-up product before Mastervoice folded and disappeared entirely, the Mastervoice ECU. ( https://forum.vcfed.org/index.php?threads/mastervoice-ecu-the-butler-in-a-box-tries-again.1070407/ )

To bring everyone up to speed, the Butler in a Box and the ECU were the 80's equivalent to the Amazon Alexa or Google Home Assistant. It was a box that you could speak to and with...

• NeXT
• Replies: 4
• Forum: NeXT

• 

Getting right into it, normally I wouldn't remove all the parts to trace the PCB out but due to the potting compound and them placing the part designators UNDER every component, there isn't much choice. Fortunately it is a 2 layer board so removing everything shouldn't be much of an issue. Last month I took the ROM dumps and did some basic disassembly and figured out a few things; namely the potted EPROM only contains part of the code. The rest is "encrypted" (cough) and stored in the unpotted EPROMs, and is decrypted and loaded into RAM on boot. The total size of the executable is around 20K which is a lot of 6502 asm.

The VFD was broken on this unit too, so I will try to source a compatible replacement display and get that working if all goes well!

Guess nothing else to do but jump right in! First step is to remove every part from the circuit board, and enter them into Altium as I go to keep track of each part as it's removed:



Fortunately the bad potting compound seems to be susceptible to mild heat and isopropyl, so removing the remaining stuff wasn't terrible. I heated the gooey chips up with 150C hot air and they just kind of.. oozed off the board. The chips with potting on them were dunked into a cup of alcohol and allowed to soak.

Here's the back side for completeness:


Fortunately the PCB is pretty decent quality so I managed to only lift 1 pad on one of the power diodes.



Some reassembly required. I ended up replacing all the caps and resistors that got covered. Those monolythic capacitors don't clean up very well and I have plenty of them on other boards to harvest.

Here's how the schematic is going:




(digital)



(analog)

 

[marshallh]

Loading part of the code into RAM is pretty good protection, but it looks like you sussed it out quickly. Surprising also that the PCB didn't disintegrated with heat as those tend to.

Btw, any idea why there is a (tant?) cap soldered across that DIP14?

 

[kevtris]

Loading part of the code into RAM is pretty good protection, but it looks like you sussed it out quickly. Surprising also that the PCB didn't disintegrated with heat as those tend to.

Btw, any idea why there is a (tant?) cap soldered across that DIP14?

Yeah I'm surprised the PCB held up but it seems to have. I will know for sure if I can get it back together. loool.

The chip with the capacitor across it is the PROM that does something with the DRAM refresh. I suspect they were having RAM corruption problems at some point. the DRAM is battery backed when the power fails, so maybe with the power switched over it was corrupting something, and this was their attempt at a fix.

 

[kevtris]

Work continues. I started with the DRAM part since it was the most interesting and seemed like a good place as any. They used a small PROM and a 4 bit binary counter to make a complete DRAM access and refresh system! This is... quite interesting and I do not think I have seen anything quite like this before. There's a 16MHz crystal oscillator feeding into a 4 bit counter, and the output of the counter feeds straight into the PROM's address lines. I was curious how the CPU and DRAM were synchronized with each other, but it's implicit by having the CPU clocked straight off the counter at the "1MHz" tap. A4 is effectively the "chip enable" for the DRAM; it goes low at 0200-DFFF which is where the RAM lives. When A4 is high it only performs refresh cycles, and no access cycles. The PROM's 16 steps is one complete refresh and one (optional) CPU access.




The contents:



I decoded what the bits do and it looks like this:

clk - 6501 clock input
wr - write pulse to 8255's and other peripherals
ref - gate refresh counter onto A0-A7 of DRAMs
hi - gate A8-A15 from the CPU onto A0-A7 of DRAMs
lo - gate A0-A7 from the CPU onto A0-A7 of DRAMs
ras - /RAS on DRAMs
cas - /CAS on DRAMs

(CPU accessing DRAM)

clk ________________----------------
wr __________--------------------__
ref ----____------------------------
hi ------------------------____----
lo ------------------____----------
ras ------________------____________
cas __------------------------______

(CPU not accessing DRAM. refresh only)

clk ________________----------------
wr __________--------------------__
ref ----____------------------------
hi --------------------------------
lo --------------------------------
ras ------________------------------
cas --------------------------------


I haven't touched the analog much yet, that's next. Here's how the digital is going:

 

[kevtris]

It was the day of the analog! I found a few weird things that I still need to investigate. Digital's about done now, just a few things left there. Analog has a bit to go yet.


Nothing too surprising on the digital end, except that they used an entire 8255 to read an EPROM. They use it as kind of a "disk drive" with two 32K EPROMs attached. I am not sure why they did this and didn't just bankswitch it in. The second 8255 is used to send and receive the audio data, with some shift registers to serialize and deserialize it. I peeked in the code but they do not use the audio in functionality at all, so they wasted a bunch of hardware. Maybe they were thinking of letting you record custom response messages?



I started on the phone interface section, and the... "speakerphone" chip and the CVSD audio stuff. The use of a speakerphone chip is really interesting- a speakerphone is kind of a difficult thing to implement since the phone can hear itself so to speak, and doing automatic level control to adjust for the speaker's distance from the microphone and such. Using an off the shelf chip for this made it a lot easier for them to listen for spoken commands from the user.

The power supply is pretty conventional, though the way they power the RAM to do battery backup is pretty terrible. They used a 5V low dropout regulator, but I guess its dropout wasn't low enough so they just... stacked a second one on top of the first.

Then there is this... thing.




Looks like some kind of low pass or something. We'll see when I get there.

 

[NeXT]

I have tried to get in touch with Gus however all my ways to reach him (that is the one email connected to him that's public) isn't bouncing but also not responding back.

 

[kevtris]

Finished up the analog end. There's a few interesting things in there. It looks like they had two tone decoders on the board which were not stuffed, going by the pinout of the chips and other things in the area. The circuitry looks like this:


I have seen similar things before on answering machines to detect a single touch tone before. ("NU" means not used on the schematic) The audio in comes from the phone circuit. That weird little resistor/capacitor mess appears to be a clipping/lowpass filter. This must be a hack to make the speech recognition work better:


All the "RX" and "CX" and DX1 are those added parts.

The telephone interface is frankly a disaster, and I would not plug this into an active phone line. The phone line routes pass less than 1/2mm from other routes which are near ground potential on the board, so any kind of minor overvoltage event (lightning strike nearby, for example) would blow up a lot of the stuff on the board.
There is an added PCB with an 8748 microcontroller and a "call progress" detector chip, which is connected with flying wires soldered to various points on the board. This is wired in place of the missing tone decoders above. They had a lot of problems figuring out how to couple the phone line audio also, and the circuit looks like this:

I am not sure what's up with all of this, lots of missing (NU = not used) components, capacitors replaced with 0 ohm resistors, etc.

There's a couple cases of things like this as well:


It'd be cool to get some insight as to how things went down during development and production that led to all these hotfixes.

The main PCB is 100% traced out at this point and all of its secrets have been placed into my schematic. I have the hot glued board with the 8048 left, and the display board. Once those are done I will post the final schematic.

 

[kevtris]

Almost done. need to do the bodge board, but display board is done now. There's nothing too special on there, it's about what you'd expect. the PIR sensor signal conditioning is kind of interesting, however. these days that is all 100% done inside the sensor now instead of a fleet of external components.

 

[Hugo Holden]

I certainly admire your reverse engineering efforts here, and the idea of keeping track of everything by entering it into Altium.

I have reverse engineered a few boards by now , such as the Dazzler board set, the Votrax Type'N Talk and the Taylor Wilson PET printer interface and the RM-65 video card (that was 4 layer beast) and I have done it for some VDU's too, but nothing as elaborate as what you are doing here, I can't wait to see the outcome. I had never heard of the Butler.

 

[kevtris]

I certainly admire your reverse engineering efforts here, and the idea of keeping track of everything by entering it into Altium.

I have reverse engineered a few boards by now , such as the Dazzler board set, the Votrax Type'N Talk and the Taylor Wilson PET printer interface and the RM-65 video card (that was 4 layer beast) and I have done it for some VDU's too, but nothing as elaborate as what you are doing here, I can't wait to see the outcome. I had never heard of the Butler.

thanks! yes I've tried a lot of things and this seems to be the best. I enter all the parts first (and mark up a picture of the board with part numbers if the board does not have them) first, before tracing anything out. It speeds things up because you're not constantly looking for and making symbols. I traced out the type n talk a long time ago and then traced it out again relatively recently in altium.

I did finish the schematic for the butler in a box, so here it is. The display arrived with the glass missing so I will probably post a few things about retrofitting another VFD to the board and making it work fairly soon. I think I found most of the errors in the schematic when reinstalling the parts!

After its brush with death, the board is indeed working again, but without a display. It boots up and says "hello!" now, and seems to be doing the things it should. I am not sure if the keypad is working yet, I had some issues tracing it out but we'll see.







I am powering it with +/- 12V into the AC input from the transformer. It has a center tapped transformer and two full wave rectifiers to generate + and - voltages, so this works fine.

And finally the schematic!