• Please review our updated Terms and Rules here

Random Errors in BASIC when TRS-80 Voice Synthesizer is Attached to Model I

K

kengr

Member
Joined
Sep 11, 2017
Messages
43
I have a TRS-80 Model I with Level II BASIC (1.0 ROM version), 16K RAM in the keyboard unit, an Expansion Interface (final design) with 32K RAM, a Lotharek HxC floppy emulator (emulating two floppy drives), known-good ribbon cables, and an original TRS-80 Voice Synthesizer (c 1980) attached to the expansion port on the Expansion Interface. From the floppy emulator, I can boot TRSDOS 2.3, NEWDOS/80, LDOS 5.3.1, and others.

Simple two or three word tests of the TRS-80 Voice Synthesizer when attached directly to the keyboard's expansion port or the Expansion Interface's expansion port work just fine. But when I run the official TRS-80 Voice Synthesizer demonstration program, I get random bogus errors happening at different points in the program. The program terminates and reports syntax errors at different lines of code (when there are no syntax errors), illegal subroutine calls (when they are valid), various errors on line numbers that don't exist at all, etc. The error reported is always bogus and changes every time the program is run. In terms of program behavior, it also looks like loop variables are changing spontaneously, baling out of the loops early. The code itself is standard Level II BASIC, and is the official Radio Shack source code you see used in all the Voice Synthesizer demos on YouTube.

It's as if internal tables, parsing stack, etc. might be getting corrupted, but the BASIC source code itself is not getting corrupted. I have verified that the source code itself is not changing at all from one run to the next.

I've done a ton of stuff with this system, unrelated to the Voice Synthesizer, and it's always worked perfectly. No weird random errors. No unexpected reboots. Just rock solid, reliable behavior. Only when I introduce the Voice Synthesizer to the mix, and get it to say more than a few words (by running the official demo) do I run into trouble.

I've run every RAM diagnostic I can get my hands on, and RAM always passes with no problems.

I have carefully cleaned all of the card edges involved, but that had no effect on the behavior at all. (They were already pretty clean, so I'm no surprised.)

Temperatures don't seem to be any higher than when I do non-voice-related work on the system.

The Voice Synthesizer power supply is a brand new 12VAC supply from Jameco, and tests perfectly, with appropriate voltage and amperage. I use an adapter to step down from 3.5mm to 2.5mm at the power connector, but that tests fine as well. Good contact, good power. The Voice Synthesizer operates correctly as long as the program is running...the activity LED and speech output are performing just as expected.

I did examine the board inside the Voice Synthesizer, and visual inspection didn't turn up anything suspicious. The board has all its original parts. Capacitors look fine. (I'm more of a software person than a hardware person, so my test equipment and abilities on that front are limited.)

I've tried booting different operating systems and using the flavors of BASIC that come with those operating systems, and the same behavior persists.

Any ideas on what might be causing this type of "random bogus errors in BASIC" behavior when the Voice Synthesizer is involved, or how I might proceed to diagnose it? Could a failing part in the Voice Synthesizer be putting something on the system bus that causes the random errors, even though the synthesizer behaves normally?
 
Is your "TRS-80 Voice Synthesizer demonstration program" loaded from Cassette tape or from
Floppy (Virtual Floppy) as ASCII or Tokenized Basic?

Try the CMD "T" then cload your basic program and then CMD "R" and save it to Disk.

http://www.trs-80.org/trsdos-model1-basic/

You can save "filename",A and it saves as ASCII versus the tokenized version.
If you don't save it as ,A then it's hard to edit and make changes to fix BUGS
as there will just be tokens versus what you want to edit. But, it will be smaller.


Larry
 
Thanks for your reply.

The demo program is loaded from the emulated floppy (Lotharek HxC). I originally loaded it as ASCII text, from the original source code, then saved it on the TRS-80 as a tokenized BASIC file. I have tried loading the ASCII file and the tokenized file, with the same results. I have visually confirmed that the program is identical to the original source code. When the voice synthesizer is not physically attached to the Expansion Interface port, the program always runs 100% perfectly and continuously (it's designed to loop forever, as a store demo) and never gets any errors. I can run the program continuously for hours and hours overnight, and it works perfectly with no errors reported. But when the voice synthesizer is powered on and talking as characters are sent to its buffer through the memory mapped locations in the video memory, I get the random errors occurring, as described in the original post.

The only difference between running it with the synthesizer disconnected or not is that the characters sent to the memory-mapped window of video memory are detected, captured, buffered, and played by the synthesizer. According to the synthesizer service manual, there is no signaling (busy, etc.) going back to the TRS-80. The unit just watches for characters stored in a specific address range, and loads them into its buffer, and then the buffered characters are sent internally to the proprietary speech section of the unit.

The issue is not a buggy program. It is the original Radio Shack store demo source code. I have confirmed that the program is identical to the original code. All the random errors reported are not real errors in the code: syntax errors on lines that don't exist, syntax errors in perfectly good lines (that haven't changed), invalid calls (that are valid), etc. The errors change every time the program is run, if the synthesizer is attached to the expansion port, whether the synthesizer is powered on or not.

With the synthesizer physically removed from the system (not just powered off, but physically detached from the expansion port), the program will run/loop perfectly all night long without any problems. No errors, no weirdness, just rock-solid stability.

I have not tried monkeying with the program on cassette at all. I am aware of the CMD"T" business for doing tape I/O, but didn't want to deal with any of that, since I already have a good version of the program on the floppy image.
 
kengr said:
and an original TRS-80 Voice Synthesizer (c 1980) attached to the expansion port on the Expansion Interface.
Click to expand...

That is interesting. I thought the TRS Voice Synth was incompatabile with the EI. I don't have one / never saw one "in person", but AFAIK the WR RAM signals (required for the display memory snooping) are not being passed through by the EI Expansion Port Interface? So it will only work if directly connected to the Model 1 Expansion Port. AFAIK. But I may be wrong.
 
Thanks for your reply.

No, the TRS-80 Voice Synthesizer (Catalog Number 26-1180) has always been compatible with the Expansion Interface. The original 1979 manual shows and describes this configuration:

2020-05-12_9-11-05.png

Back in the day (c 1980), I had one of these synthesizers attached to my Expansion Interface, and it worked like a charm. That whole system is long gone, but I have been pulling together the components to recreate that system (almost, with a few newer components instead of originals), getting them piecemeal from various sources.

There are many memory-mapped devices (ancient and modern) that can and do work with the expansion port on the EI. The Screen Printer is one such device. In fact, the expansion port on the EI was sometimes referred to in early documentation as the Screen Printer port. This is how it was referred to in the Voice Synthesizer manual, because I suspect that was the only official peripheral for that port in 1979. The Expansion Interface manual says about the expansion port : "This card edge duplicates the card edge on the TRS-80 Computer." and I have confirmed from the EI service manual that the WR signal is documented as working on that card edge. If WR didn't work, the synthesizer would be silent. But it's not silent. It sees the bytes written within the memory-mapped address range, and speaks perfectly all phonemes sent to it, as long as the program continues to run.

So, the synthesizer functions perfectly, in terms of speaking all phonemes sent to it, and flashing the LED during transfer of bytes from the bus. It just stops speaking when the program dies a random/bogus death. But restarting the program will cause the synthesizer to speak again, until the next random/bogus program death. The synthesizer remains in a working, usable state, even though its connection to the system seems to be causing random weirdness in BASIC's working memory.
 
Wow - you are right.
It seems I got this piece of misinformation from the book "Hardware Interfacing with the TRS-80" from Uffenbeck.
Or there is something else I don't understand. This book states, for example, in Experiment 6 "Memory-Mapped I/O using the 8255":

"This experiment cannot be done on a Model III.... The experiment also cannot be done using the expansion interface and a Model 1 computer. This is because the RD and WR control signals are not enabled on the expansion interface bus (you may want to disconnect the expansion interface temporarily for this experiment)".

Based on this piece of information, I have added the expansion port passthrough to my Talker/80 speech synth. And I *thought* I had also confirmed with the logic probe that indeed WR and RD were silent on the EI!

But now, out of curiosity, I just connected Talker/80 to the "Screen Printer Port" (usually, the FreHD hangs there), and it worked!! The TRS Voice Synth emulation of Talker/80 works on the EI. That was totally unexpected.

And it does not have the issue you describe... (but of course, it is a modern "emulation").

Wish I had the original, but yes, I can see your main point - it should work! Unless something is failing somehwere in the hardware.
 
LambdaMikel said:
This book states, for example, in Experiment 6 "Memory-Mapped I/O using the 8255":

"This experiment cannot be done on a Model III.... The experiment also cannot be done using the expansion interface and a Model 1 computer. This is because the RD and WR control signals are not enabled on the expansion interface bus (you may want to disconnect the expansion interface temporarily for this experiment)".
Click to expand...

I'm guessing the author may have been confused with the Expansion Board connector (the internal one to which the RS-232 board connects)?
 
Well, whatever happens with my issue here, I'm glad this discussion was able to open up a whole new set of users for the Talker/80 board...assuming they don't already have something connected to their EI expansion port, or they have a dual connector for it.

Back in the day, I breadboarded and hooked a variety of simple things to that that port (e.g., bunches of LEDs to monitor the signals, static RAMs, etc.). I had never heard that there was anything different between the expansion card edge on the back of the keyboard/CPU unit and the left side expansion card edge on the EI.
 
kengr said:
Well, whatever happens with my issue here, I'm glad this discussion was able to open up a whole new set of users for the Talker/80 board...assuming they don't already have something connected to their EI expansion port, or they have a dual connector for it.
Click to expand...

Sorry, I didn't mean to derail the discussion. Wish I could help, but I don't have the original. I guess something must be jamming the databus somehow, as you said. If there is something wrong with its tristate logic, then.... looking at the schematics, I find it weird how they interfaced to the databus. Why all the 5v pullup resistors and ALL that? Maybe one of the pullup resistors is bad? Or one of the inputs in one of the glue logic chips that connect to the databus is bad?

Bildschirminhalt erfassen-1.jpg
Bildschirminhalt erfassen-3.jpg
 
I really wasn't being sarcastic earlier...I was actually sincere when I said that more users could use the Talker/80. In fact, if I can't get the original to work reliably, I might become a customer myself.

I'll take a peek at the resistors. Sorry for the simple hardware question, but if I use my meter in Ohms mode, can I safely put the meter on the contacts of each resistor to measure resistance, or could that damage anything else in the circuit? Do I need to de-solder a resistor to test it?
 
kengr said:
I really wasn't being sarcastic earlier...I was actually sincere when I said that more users could use the Talker/80. In fact, if I can't get the original to work reliably, I might become a customer myself.

I'll take a peek at the resistors. Sorry for the simple hardware question, but if I use my meter in Ohms mode, can I safely put the meter on the contacts of each resistor to measure resistance, or could that damage anything else in the circuit? Do I need to de-solder a resistor to test it?
Click to expand...

You don't need to de-solder them. But make sure everything is powered down. It is unlikely that they went bad, but I had a case where a ceramics resistor somehow broke because of tension over time.

Next, I would probably try replacing / socketing the glue support chips. Not sure how difficult that is. IC4,5,7,10 make up the FIFO. IC1 is an inverter for the WR signal, etc. These chips should all still be available.
 
The resistor packs on the synthesizer board test okay...right resistance, within tolerance. I also have checked the edge connector for shorts between pins, but didn't turn up anything.

The fact that the problem occurs even when no power is applied to the synthesizer is a bit confusing to me. I can reproduce the problem as long as the synthesizer connector is attached to the system, even if the synthesizer is completely powered down. If I physically detach the synthesizer, the system works flawlessly. But as soon as the system is running with the synthesizer cable attached, I get the apparent random changes to RAM, typically manifesting as nonsensical errors reported in the BASIC program (even though the program source code hasn't changed), and sometimes as single-character changes to the contents of displayed strings. A new symptom I have seen recently is a spontaneous reboot, but I suspect that randomly writing to just the right locations could trigger that behavior. I have again thoroughly cleaned all the contacts, and have ordered some gold-plug-like edge card parts, just to cover all the bases.

I'm going to start looking at socketing/replacing other chips as time permits. Other priorities have gotten in the way of doing that.
 
Maybe it is really the Model 1... you could try with another Model 1 (or ask someone from here to hook it up to their system). Just an idea.

I got random changes to the RAM when my 5V voltage was too low. Have you checked that? Connecting the Voice Synthesizer might result in enough voltage drop (somewhere) to have the RAM voltage too low? Is your PSU good?
 
Thanks for the tip.

I only have one Model I computer, but I do have four different original power supplies, and have tried them all with the same results (using two at a time, in different combinations, for powering the keyboard unit and the expansion interface).

I seem to recall seeing a video some time back showing exactly where to test the voltages on the motherboard in the keyboard unit, and a way to slightly adjust the voltages if they're not quite correct. I'll hunt that down, if possible, crack open the keyboard unit case, and see what's happening voltage-wise.
 
You must log in or register to reply here.
Back
Top