coolio

Thanks all. I played with the encoding options as suggested. I also tried the different encoding software. I found that I could get the singing bit to sound good (no static or noise) with python_wizard. So, Yay!

OK, I have made progress here. After literally months of trying (not every day, just during "hobby time") I came to the conclusion my problem was the breadboard on which I was building my system (too much noise and capacitance). So, I moved my hardware design to a PCB, and got it working. Yay! The software approach for the speak external command was to send the first 16 bytes, and then poll for the TMS5220 status buffer looking for the buffer low status and sending 8 more. Works perfectly. And the beauty of my hardware design is that I don't have to put the CPU into a wait state while the TMS5220 latches onto the data (as indicated by the READY line). I'll share more on the details of this design later (I plan to make a video about it). Now I have a new problem: what are the best practices for encoding custom audio into LPC bitstream? I am using TMS Express to do the conversion from a WAV file to an LPC bitstream, and that in general works, but frequently the audio from the TMS5220 is just awful, notably during times like inter-word silences. Here is an example: Note that in the second sample (the classic Daisy song) there is a large amount of static in between words and at the "tail" of words. Any advice on the best practices when LPC encoding custom audio would be appreciated! Thanks!

OK, progress here. I moved away from the LM386 audio amp to some computer speakers with their own amplifier and that fixed the audio quality issue. the Parsec sample @JasonACT provided sounds just like it did on my TI 99/4a .... with one exception. The speech synthesis gets about 3/4 through the data and then just halts. What I hear is "Press fire t<bzzzt>". About the time the sound goes south, I the TS (talk status) bit on not he TMS5220 goes to 0. But the thing is I don't get an interrupt prior to this indicting the BUFFER is low on data. The process stops always at the same pointing the data stream, meaning the talking stops before all the data is sent. I am not sure how to debug this. Has anyone experienced anything like this before? I looks at @Asmusr's TMS5220 handling code for some of the games he published the source to. I see in his code instead of waiting on the TMS5220 interrupt pin to send 8 more bytes to the FIFO buffer, he polls the BL (buffer low) status big. I changed my code to do that and get the exact same results (about 3/4 of the data stream is successful, and then talking stops). I also tried restarting the speak external command by when I get a premature TS=0, I reissue the speak external command and pick up with the data transmission where it previously left off. This doesn't help. Any thoughts or ideas on this? Thanks!

Thanks! I used this bit stream and it seemed to work, but the speech still sounds poor. Listen to the the audio here: IMG_6002.MOV I was the Parsec "Press Fire to Begin" sound I assume, but that audio quality is very poor. I wonder if the audio quality is caused by my audio amplifier I am using. It's just a simple LM386 circuit similar to the second one documented here. As a comparison, here is an audio file of my own that I ran through TMS-Express: IMG_6003.MOV Both samples have static noise problems. For clarity, I am using the audio filtering circuit in Thierry Nouspikel's documentation of the TI Speech Synthesizer circuit, specifically the SPEAKER line from the TMS5220 is connected to a 0.22 uF capacitor and 1K8 ohm resistor to ground, and a 1 uF capacitor inline with the audio line. This then feeds the LM386 audio amp, which is driving a 8 ohm, 0.5W speaker. Also, since making the recommended change to use the interrupt line as the cue for more data, the logic analyzer picture looks much better (the /READY line goes high for only 20 uS at a time). So like I said, I wonder how much of this is my audio circuit now. Any pointers would be much appreciated. Thanks!

I thought the speak external command was x110xxxx, which would be 0x60. Isn't 0x40 the "load address" command for an address of 0x0?

Thanks! So I changed the control flow of my set up to this (after sending the speak external command): Set N to 16 Repeat for N bytes or until input buffer is done: Bring /WS low Immediately present the byte to write on the data bus (with D0 being MSB and D7 being LSB) Wait for the /READY line to go high, then continue to hold both /WS low and the data bus value valid When the /READY line returns low, then release /WS (bring it high) and return the data bus to high-Z state. Wait for /INT line to go low. Check the status register on the TMS5220 If status register indicates talking has stopped: If input buffer not done yet, send speak external command and set N to 16. Go to step #2. If input buffer done, set stop frame and got to END If status register indicates buffer is low, set N to 8 and go to step #2 This certainly produces better results, as the rhythm of the noise resembles the speech rhythm of my sound sample I converted to LPC data, but it is still very garble and not intelligible. Which now makes me wonder if I don't have good LPC data. Does anybody have LPC data designed to be sent with the speak external command on the TMS5220?

Thanks. Yes, I have studied Thierry Nouspikel's TI Tech Pages very closely over the years. My question gets into a bit more detail. For context, I am trying to operate the TMS5220 from my custom hombrewed breadboard CPU (learn more about that here). The only thing I am trying to do is enable the Speak External command and so there is no integration with a Speech ROM. When I try to write external LPC speech data to the TMS5220, sound is produced, but it is very garbled. If I vary the OSC input between the 8 KHz and 10 KHz sampling speeds, I can just make ut some of the words I would expect, but it's too static and garbled. In order to satisfy the timing requirements of the "Write Cycle for External Speech Data" identified in the TMS5220 data sheet, I have built circuity that does the following when I want to write data to the common register or FIFO buffer: Bring /WS low Immediately present the byte to write on the data bus (with D0 being MSB and D7 being LSB) Wait for the /READY line to go high, then continue to hold both /WS low and the data bus value valid When the /READY line returns low, then release /WS (bring it high) and return the data bus to high-Z state. Rinse and repeat I have verified with a logic analyzer that my circuit is in fact doing that, so that's not the question here - unless this sequence is wrong, then that's the answer ;-). However, I am noting peculiar behavior with the /READY line that I don't readily understand. First, I note in Thierry Nouspikel's notes not he TMS5220 that the /READY line can be used as a sort of flow control. That is, after writing the first 16 bytes into the FIFO buffer, when I write the 17th, the /READY line will be held high until the FIFO buffer has consumed some data and can make room for more. I in fact see this happening in the logic analyzer. The first 16 bytes get written with the /READY line is held high for about 20 uS each time, which is in line with the data sheet on t_w(R), and then on the 17th byte the /READY line is held higher about 9.5 mS, and then the /READY line returns low, and my circuitry releases /WS and the data bus. During that time, the talking begins (the sound is not intelligible, but I can't tell if it is the first 16 bytes that is causing the problem). This leads to my first question: When the /READY line is held high for so long on that 17th byte, is the external data that I was trying to write accepted (just before) when the /READY line is returned low, or in this scenario did that external write attempt fail and when the /READY line is returned low I need to try again with that 17th byte that I was trying to write? Then, after that 17th byte, the byte writing never returns to t_w(R) (/READY line pulse width) being less than 23 uS as indicated in the data sheet. All subsequent byte writing cycles experiences the /READY line being held high for 200us each for a few bytes, then a long pause of 10-20 mS. Basically it looks like it the speech data is consumed a few bytes at a time (3-8 bytes at a time, it varies) and each byte takes about 200 uS to consume, and then that packet causes a longer pause measured in 10s of milliseconds, during which I assume speech sound is being generated. My question then is whether this timing pattern sounds about right? Finally, I have sample LPC speech data that is about 300 bytes long. The /INT line is held high (inactive) until about halfway through that data, at which point it gets brought low periodically. I am taking this as a sign that something is not going as I expect because this would indicate that either the talking has stopped or the FIFO buffer is low or empty. But the first time /INT asserts, the /READY line is still being held high. So I am a bit confused by this. I suspect this means my data writing process above and the dependences on the /READY line for flow control might not be right, but I cannot find what might be wrong per the data sheet and Thierry Nouspikel's tech page. Any advice here would be much appreciated.

I am trying to create a project that interfaces with a TMS5220 speech synthesize chip at the hardware level, and I am not having much success. I am able to generate a lot of noise, just not the expected speech-like sounds. I need some help figuring out what I might be doing wrong with the circuit interfacing with the TMS5220 or even the software. I know this isn't strictly a TI 99/4a question, but I honestly don't know where else to ask. Before I dump my questions here, I just want to double check if this would be a good place to ask. Thanks!

Thanks! I have ordered 1 page of 11 ZQX-ONE cartridge stickers from Sticker You. Obviously I only need 1. If anybody else wants one of the others, PM me to get and address to send a SASE to.

Oh, great, thanks! Do you happen to know the proper size for the label when printing with StickerYou?

I have a silly question ... how does one get the cartridge labels printed? I am pretty sure my ink jet printer won't produce the quality that I see on other homebrew cartridges. Thanks!

I just wanted to say: after 40 years of that TI-PEB firehose and elephant foot connector, I didn’t realize how much I would love the 838-IO. So simple, yet, makes things so much better. Thank you.

Hmmm ... good point. I will try that.

I am trying to get the Nouspikel IDE card working with StarTech IDE2CF adapter, however, I need to provide power to the adapter card with a SP4 power connector. Does anyone have any advice on where I can tap into power in the PE box to provide this? I assuming someone has solved this problem before and I am simply trying to not reinvent a solution. Thanks!

I was cleaning out some old things and came across this TI 99/4a catalog from 1984. Just thought I'd share in case anybody is interested in checking out the prices unisource-electronics-1984.pdf