• Please review our updated Terms and Rules here

Early 1990's telemarketing dialer

Bruce Tomlin

Experienced Member
Joined
Jan 6, 2010
Messages
364
Location
San Antonio, TX
I've finally gotten around to trying to make some of my accumulated stuff work. The thing I'm working on now is a bare board from an early 1990s telemarketing dialer. The software has a 1994 date in it, so this would be shortly after the Telephone Consumer Protection Act of 1991 (TCPA). It was made by Kolker Systems Inc., which was one of the companies at the forefront of the auto-dialer brouhaha.

The board itself uses a 6802 CPU, which has the original 6800 instruction set, but adds 128 bytes of RAM. And it is packed full of stuff. There are four 6821 PIAs, for a total of 80 bits of I/O. It has 24K of ROM, 32K of RAM, a 4x4 keypad, an 8 x 7-segment display, a 6850 ACIA, a 6840 timer (which is also the baud rate generator), a DTMF generator, a voice recorder chip with additional bank switching for up to six times its normal capacity, and what appears to be two cassette tape controllers. And a 1 Farad supercap too, because why not?

I found it with the cords chopped, but at least they were left connected. I was able to rig up a terminal block for the power. It needs 5V regulated, and 24 VAC center tapped. Of course the +/-12 volts is for RS-232 and some of the analog stuff, so I just hooked up a 5V 3A power brick. It also has no silkscreen, and having no designators is somewhat annoying when trying to build up a schematic. I've already got 8 pages of KiCad schematics just to rough out the big stuff, and none of the analog circuitry.

Of course when I finally applied power, nothing happened. I was able to tell that the reset line was stuck. The reset traces went three ways, so of course to narrow it down I ended up cutting the two that weren't the problem. The third one went under five chips, and was inverted through a 74LS00 NAND gate. So I lifted the 74LS00 pin (yay sockets). Since reset already had a pull-up to 5 volts, I added a capacitor, and a pushbutton for manual reset. That's the bodge on the left. I still don't know yet what is wrong with the original reset circuit.

The next problem was that it was running long slow tests, and would fail one of the RAM tests. I still don't know exactly what the problem was, but I was able to patch around it and a couple of other tests, and still couldn't get it to reach the main code. I was, however, able to write my own code to make the display work.

The next problem was that it was really picky about EPROMs. I tried some 2864 chips which seemed to have some bytes flake out after being used a couple of times. Oh well, I still have my 9-chip UV eraser. It also had problems with some EPROMS that I tried, and since the original was 120ns, I gave up on the 250ns chips that I was using, and picked out a bunch of 27C512-15 chips. I think there's also a loose connection on the board, because once or twice it failed to work even with the original EPROM installed.

The display uses a chip that does its own scanning, and I noticed that the decimal point wasn't working. Sure enough, it wasn't connected, but they left space for a jumper. So I hooked it up, and it turns out that the decimal point bit is inverted! No wonder they left it disconnected by default. I bodged in a jumper block for that.

At this point I need to figure out how to get the timer chip to generate a 9600 baud clock, and I'll probably bodge in a TTL serial-to-USB adapter so that I still won't need 12 volts. It would be nice to write some kind of trainer monitor for it, but that keypad is not great, and a good user interface is hard without more keys. (Heathkit used 16 keys plus reset on the ET-3400, and it's a pain to use!) A serial monitor would be better, because I could load code with it. I might even try to bodge in an external keypad just so I don't have to use this keypad. (It would also be nice to desolder that keypad for a photo, because it has a rats nest of traces going under it!)
 

Attachments

  • IMG_20240428_145351289_HDR..jpg
    IMG_20240428_145351289_HDR..jpg
    3.3 MB · Views: 20
  • IMG_20240428_145413516_HDR..jpg
    IMG_20240428_145413516_HDR..jpg
    3.8 MB · Views: 20
  • IMG_20240428_162022001_HDR..jpg
    IMG_20240428_162022001_HDR..jpg
    2.3 MB · Views: 17
  • IMG_20240428_162002195_HDR..jpg
    IMG_20240428_162002195_HDR..jpg
    2.9 MB · Views: 21
  • robo-dialer.zip
    54.7 KB · Views: 0
So it's picky about chips, but I've found a few 27C512 and even two 28C64 chips that it's happy with. The next thing is to get RS-232 working, because that would be the best way to get some code running on it without having to go through the burn / erase cycle all the time. And that's made worse because my EPROM programmer is on the other side of the house.

In order to avoid the need for +/- 12V power, I'll probably remove the 1489 and bodge in a header for a USB TTL serial adapter. But first I have to get serial working. I was able to poke at it to send bytes out the 6850 ACIA, but they seemed awful slow. I had to dial down my old 1990s oscilloscope slow enough that it flickered as it scanned, so something was wrong. So I finally ordered one of those handheld oscilloscope things that I had in my Amazon shopping cart.

The way that serial works on this thing is that the 6840 generates the 16X baud rate clock, then the 6850 does the serial port stuff. So I put the (modern) oscilloscope on the baud rate clock signal and... 3.6KHz? What? I put it on the output of the 6850, and the serial data seems to be properly divided from that, but what the hell, ~3.6KHz is not right for the baud rate generator, it should be more like 38KHz. The 6840 generates it from the CPU's E clock divided by a programmable value.

So I put the probe on the E clock, and... just under 100KHz. Wait, what? While some would consider it cool to see how slow a CPU clock can go, that's just not right. It has a 4MHz crystal, so I probed one of those pins. It had a really weird bouncy waveform that I had seen before with my big scope, but I had simply assumed that the frequency was 4MHz. Now I can see that it was only 100KHz. Time to dig through my crystals collection for a replacement! Well, looks like I have one, now let's see about replacing the old one. Ah, um, wait a minute...

IMG_20240502_200106050_HDR..jpg
(There's a nice close-up of my reset bodge on the left, the green cap and resistor are original, the can and button were added, the white wire is ground for scope probes, etc. The red wire at the bottom was from one of my attempts to fix the stuck reset.)

Yes, that's right, both crystal pins were broken at the base. It was just oscillating on the driver alone. I'm impressed that it was running at all. Suddenly my demo code went nuts with its delay loops running 40 times faster. The baud clock is now about 36K, close to the expected 2400 baud value. Put the original EPROM in, and it only takes a few seconds to get to FAULT 20, rather than a minute or two.

Time to fix up my delay subroutine.
 
The replacement crystal was acting flaky, so I decided to avoid the whole problem and use a can oscillator instead. Except that I didn't have any 4MHz can oscillators, so I made a little board with a second socket for a 74LS74 so I could use an 8MHz crystal, which I did have, and divide it by two. And if that breaks, I have nine 16MHz oscillators, and can bodge in the second half of the 74LS74 to divide by four! Actually it turned out I did have a 4MHz oscillator, but it was in a 1-inch plastic brick, and I'd rather use something I have a lot of and goes in a DIP socket.

I finally got the ACIA serial port working. I bodged in a header for a USB serial adapter like I planned, and was getting data out of that. The baud rate clock confused me because it was half what I expected, but it turns out that the 6840 uses the timer count for both halves of its output, causing another divide-by-two in the math. Because they used an exact 4MHz clock instead of 3.6864, it doesn't have good multiples of standard baud rates beyond 2400 baud.

But by far the biggest thing is that I got SWTBUG working on it, so now I should be able to upload code as S19 data without having to burn a chip every time. It's not the best monitor, but it's good enough for me to build something better.
 
My gut reaction is that it's a pretty backward design for early 90s. Looks more like early 80s, in spite of the chip date codes. There's probably a back story to this somewhere.
 
The copyright date in the software says 1989-1994, so it was probably a model that had been out for a while. The lack of silkscreen makes me think it was a late revision of whatever it was, and they had already ditched silkscreens to save cost.
 
Lately I've been sidetracked by trying to take labels from the 6502 MSBasic source and apply them to a disassembly of the Altair 680b MSBasic, with mostly good results. Hopefully I can get it to run with very minor patches.
 
Lately I've been sidetracked by trying to take labels from the 6502 MSBasic source and apply them to a disassembly of the Altair 680b MSBasic, with mostly good results. Hopefully I can get it to run with very minor patches.
Oh, nice. I was doing a bit of this as well, but got sidetracked back in mid-2022 and it's just been sitting there ever since. Perhaps we could combine efforts? PM me if you're interested.
 
My gut reaction is that it's a pretty backward design for early 90s. Looks more like early 80s, in spite of the chip date codes. There's probably a back story to this somewhere.
Seems like a niche product. Probably some combination of "it works, people still buy it, why change it" and "this thing has all it's certifications (FCC and otherwise) and why would we want to go through that again". Plus, by the 90s it was probably clear to the savvy telemarketer that digital was the future what with the opportunity to speed up dialing, spoof caller ID and such, so this could be the 'legacy' POTS product line.
 
So finally I tried to do something that used the main RAM chip, rather than just the 6802's built-in RAM at $0000-$007F. And then I realized that not only was it not working, but I hadn't even tried to use it yet. The whole thing reads as all zero, and ignores writes. Then I noticed I hadn't yet traced out the RAM CS input.

Turns out it went into that rats nest of resistors and transistors next to the 6802. It seems that's all to do with the supercap "battery" backup. There was a 2N2222 transistor literally gating the RAM CS line from the decode GAL, and a 2N2907 between +5V and the RAM Vcc, separate from the charge circuit. FWIW, those little gray things aren't caps, they're 1N746A 3.3V zener diodes. I unplugged it a couple hours ago so that I could trace out the circuit, and there's still almost 5 volts on the RAM chip's Vcc and CS pins. I guess 1.0 Farad can keep things going for a while.

I'm hoping that maybe I can just shunt across the RAM CS transistor to make it work. I also need to come up with a sensible schematic from that mess. The original reset circuit also comes from there, and I still have just as little clue about how it was ever supposed to work without some capacitance in there.
 
I've finally traced out the "battery power" circuit and it looks like it depends on the "+12V unregulated" power rail (the one that goes back up the power connector), so it may have been designed to ensure that power was good before starting up. It probably also accounts for reset not working. There are also unpopulated positions for another zener+resistor set that goes to an unpopulated chip position halfway across the board. Now I need to start probing around with a scope to find out what it's doing.

If someone wants to look at the circuit, here's a .png of it, at the top of the CPU page. Note that "RAM VCC" is on both parts, and also the RAM chip power.

I'm also uploading a pdf of what I have put into KiCad so far. There's still a lot that I haven't even begun to look at, and stuff that's hidden under stuff, so it's far from complete. Something I want to do soon is to desolder the keypad and put headers on the board to socket it, because it hides a lot of traces, and I might even make a replacement because it's not a very good keypad.

EDIT: looks like I might have the 2N2907 backwards, pin 1 should be the collector
 

Attachments

  • robo-dialer-CPU.png
    robo-dialer-CPU.png
    260.8 KB · Views: 2
  • robo-dialer.pdf
    1.4 MB · Views: 0
Yep, all I had to do was clip around both sides of that transistor, and now I can write to RAM! I had a test program which was just a bunch of repeated writes to memory and I could see the pulses on one side, but not the other, so it was clearly there to write-protect RAM when +12 volts wasn't up.

My plans now are to try to get Altair 680b Basic running, and that Eliza program once someone posts a .bin of it.
 
Back
Top