Скачать TALK - Program Speacher for PC Speaker

Скачать файл (111,30 Кб)

Here's what I learned:

The most important part of the code is what you labeled DoSpk. Essentially it takes an address where the data begins, and the address where the data ends, and one-by-one sends each bit to the speaker port, 61h. If the bit is 1, it sends 32h. If the bit is 0 then it sends 30h. I traced it's progress as it spoke each phoneme to learn their addresses.

Each phoneme is exactly 023Fh bytes long, and they are arranged in sequence in the data table, in no particular order starting at offset $012C. "I" is a special case which is always translated into the pair "AH-EE". There is also a mystery "blank" phoneme.

So I wrote my own code for doing about the same thing as DoSpk. This is in Talk.ASM. It requires TASM to assemble. It is passed the address in memory where you want to start moving data to the speaker, and the number of bytes you want processed. If you say you want zero bytes, it processes 65536. It uses the value of a global variable SpeedDelay to determine how much to slow down. Altogether, it seems to be somewhat faster than the code used in the original, so perhaps even a 4.77 MHz machine could use a small delay. It is called ** FAR **.

Then I copied the data part of Speech.BIN to a file called TalkData, and converted that to an object file with BINOBJ. You'll have to run "BinObj TalkData.BIN TalkData.OBJ TalkDataLink".

I wrote routines in Pascal for parsing a string of phonemes, and determining what values Talk needs.

TalkPhoneme takes just one phoneme and looks up it's address in the table. The Turbo Pascal Seg and Ofs functions are used to find the data table, and the constant data length, $023F, is hard coded.

procedure Speech parses a string for phonemes. I've allowed any non-alphabetic character to be used as a seperator.

This is great.

Why don't you try it on your machine with different SpeedDelays and see what happens.

For fun, run Talk on any part of memory, your program, the operating system, whatever.

I don't think it can be made fast enough to run in the background, as I had hoped. It would be alright on a 386 perhaps, but not at 4.77 MHz. Hmmm ....

It may be possible to compress the data somewhat. It seems that there are often a lot of high bits in a row, followed by a lot of low bits in a row. I might examine the possibility of storing counts of high and low bits instead.

Have you noticed that NumSpeech's interpretation of "30" sounds a lot like "50"?

We could make some improvements in the sounds themselves. For example, every time there is a "D" sound, it sounds like "Da". Perhaps the Count for this phoneme could be shorter. Replacing the samples, though, would require some sampling device of which I have none.

Are we a team or what?