Idea: Atarivox Enhancer Cable

[supercat]

The AtariVox is a really cool piece of hardware, but unfortunately, its 9600-baud communication rate means that it takes 15 scan lines to output a byte. In many cases, this will limit games to 1 byte/frame of data, thus limiting the use of the AtariVox for things like background music, etc.

 

My idea would be for an enhancement cable which would consist of a DB9 male, DB9 female, and a PIC12C508. The PIC would be programmed so that normal AVox communication would be passed through unaltered, but a programmer could, if desired, output up to 12 bytes per frame at hyper-speed (about 1.5 scan lines/byte) and the Enhancer would pass them on to the AVox at 9600 baud.

 

I would think this would greatly enhance performance and versatility of the AtariVox unit. My one concern would be leaving out in the cold people who have the Avox but not the enhancer. I'd be more than happy to share the 12C508 code with the AVox designers if they want to produce an Avox with the enhancer built-in; since a 12C508 is very cheap it shouldn't add much to the cost.

 

Anyone have any feelings pro or con?

[Richard H.]

its 9600-baud communication rate

 

The AtariVox operates at 19200 baud

[supercat]

its 9600-baud communication rate

 

The AtariVox operates at 19200 baud

897085[/snapback]

 

Why'd I think it topped out at 9600? Oh well... an 6-fold speedup in communications might still be useful. And building such a thing into cable that could double as the PC interface might not be a bad idea. Just a thought.

[Bryan]

The SpeakJet IC operates at whatever rate it's programmed for. I believe it's set for 19.2 in the AtariVOX.

 

-Bry

[supercat]

The SpeakJet IC operates at whatever rate it's programmed for. I believe it's set for 19.2 in the AtariVOX.

897237[/snapback]

 

True. Unfortunately, since the Atari can't really do much while transmitting data, 19200 really isn't the ideal speed. A higher speed like 38,400 or 57,600 would be better since that Atari could output its data and then get back to what it was doing as quickly as possible.

 

The idea with the enhancer cable would be to allow the Atari to sent up to 12 (or maybe 16) bytes very quickly, so that it could get back to doing other things while the data was forwarded more slowly to the Atarivox. This would allow much more data to be sent per frame in most applications, thus allowing complex multivoice music and other such effects.

[Richard H.]

The SpeakJet IC operates at whatever rate it's programmed for

 

The Speakjet can do 2400, 4800, 9600 and 19200

 

As it's really just a PIC and operating from an internal oscillator, I would imagine 19200 was the highest reliable baud rate that could be achieved.

Edited July 24, 2005 by Richard H.

[Richard H.]

The idea with the enhancer cable would be to allow the Atari to sent up to 12 (or maybe 16) bytes very quickly

 

The Speakjet already has a 64 byte buffer, the state of this buffer is detected through pin 2 on the joystick port.

[supercat]

As it's really just a PIC and operating from an internal oscillator, I would imagine 19200 was the highest reliable baud rate that could be achieved.

897434[/snapback]

 

I've run 14-bit PICs at 115,200 without problem (using a 7.37MHz resonator) without problem. But I don't know whether the Speakjet uses the internal UART; its pinout seemed a little strange.

 

I recognize that the SpeakJet has a buffer; my main concern is that if a game can't spare much time in vblank it won't be able to transmit more than a byte or two per frame. If the game could send data into a buffering chip at a rate of 100,000 bits/second, it could use less time transmitting its data and have more time available for other computations.

 

Otherwise, what conventions should games obey in writing to the Speakjet's EEPROM? I assume you'd like them to leave the "Atarivox" chime alone, but what portions of EEPROM are available?

[Richard H.]

I recognize that the SpeakJet has a buffer; my main concern is that if a game can't spare much time in vblank it won't be able to transmit more than a byte or two per frame. If the game could send data into a buffering chip at a rate of 100,000 bits/second, it could use less time transmitting its data and have more time available for other computations.

Have you seen MGD ?, the game does'nt slow down or blank the screen at all while the speech is playing.

 

 

I assume you'd like them to leave the "Atarivox" chime alone

I don't mind, in fact I would be pleased if guys came up with alternative intro's. I did the default one in just a few minutes.

[vdub_bobby]

A faster speed for the speech would be nice, I guess, but at ~8 scanlines per frame (for 1 byte) that's not too bad.

 

It's writing/reading from the EEPROM that's a killer, since you rarely want to write/read just one byte - to do any kind of reading/writing to the EEPROM you pretty much have to blank the screen for at least one frame.

[Richard H.]

It's writing/reading from the EEPROM that's a killer

It's the actual speed of the chip, serial EEPROM's are very slow compared with stuff like SRAM.

[supercat]

Have you seen MGD ?, the game does'nt slow down or blank the screen at all while the speech is playing.

 

True, but that particular game isn't exactly CPU intensive. Further, even with MGD, there is a noticeable lag on some of the sound effects, most notably the burp. I would guess that this lag is a result of having to send multiple bytes of data to set up the speech for the burp before it actually starts playing; if that guess is correct, the lag could be reduced by allowing the game to send 16 bytes of data per frame instead of one or two.

 

Although a 100ms lag may not be particularly objectionable in a game like MGD where Atarivox sounds are relatively sparse, it would seem like it would be annoying in games with denser sounds (bearing in mind that the Avox is usable for more than just speech).

 

I assume you'd like them to leave the "Atarivox" chime alone

I don't mind, in fact I would be pleased if guys came up with alternative intro's. I did the default one in just a few minutes.

898199[/snapback]

Right, but if the Avox power-up sound varied depending upon what game was last used that could be somewhat confusing for users, so it would seem like a good idea to leave it alone.

[Richard H.]

there is a noticeable lag on some of the sound effects, most notably the burp

I've not noticed that

 

if the Avox power-up sound varied depending upon what game was last used that could be somewhat confusing for users

Yes, you're probably right

 

BTW I'm building a TTS add-on for it, based on a PIC programmed with the original SPO256-AL2 algorithm, expanded to accommodate the SpeakJet's extended allophone set.

 

The TTS chip is produced by Ken Lemieux of www.speechchips.com

 

You'll be able to send strings of words directly from the Atari (etc), with buffering taking place in both units.

[pissant]

BTW I'm building a TTS add-on for it, based on a PIC programmed with the original SPO256-AL2 algorithm, expanded to accommodate the SpeakJet's extended allophone set.

 

Is the AL2 algorithm freely available? I've been searching for some sample TTS code, but haven't turned up much beyond things like Festival (which is much too heavy for an embedded system).

 

Thanks,

Aaron

[supercat]

Is the AL2 algorithm freely available? I've been searching for some sample TTS code, but haven't turned up much beyond things like Festival (which is much too heavy for an embedded system).

899123[/snapback]

 

Under what cases would one want to run the TTS algorithms within the embedded system? Unless the game has either (1) a huge amount of text which needs to be handled as both text and as speech [e.g. if one wanted to add speech to Dark Mage], or (2) allows the user to input text which should be pronounced as words rather than separately enunciated letters [as in the arcade game Thayer's Quest] I really don't see why one would want to store the material to be spoken as text rather than phonetics.

 

I certainly agree that a text-to-allophone convertor would be helpful, but I would think it would be just as useful to run it on a PC before compiling the game as to run it in a target system. Indeed, the former would have the advantage that enunciation, intonation, and prosody could all be tweaked to achieve the desired effect. One of the things that makes the MGD speech so nice is that it's clearly been tweaked. There's a huge difference between "AWEsome DOOOOD" and "awe-some dude".

[Richard H.]

Is the AL2 algorithm freely available?

 

Yes (see attachment)

t2a.zip

[pissant]

Yes (see attachment)

899491[/snapback]

 

Fantastic. Thanks alot.

 

Ever since I played with SAM on my c64 I've always had a desire to play with this stuff.

 

As SuperCat above points out, it is generally better to generate the voices on a PC using more sophicated algorithms than simple text to phoneme. On the other hand, these older systems have such a beautiful robot quality to them that I just can't resist.

 

Aaron

[supercat]

Looking through the SpeakJet manual, the fastest way I can see to abort something that's being said and trigger a new message is to send "\0RX" followed by the start of the new message. At sixty bytes/second, this will represent a delay of 1/12 second before the earliest possible utterance. For some games this may be fine, but for others it could be annoying. Is there any faster way to force the Avox to abort the current message and start saying a new one?

[Richard H.]

Is there any faster way to force the Avox to abort the current message and start saying a new one?

 

Not that I know of.

 

 

BTW what do you think to the synth part ?

[supercat]

BTW what do you think to the synth part ?

900153[/snapback]

 

Haven't tried programming it yet, but it seems like it would be cool IF enough data could be loaded fast enough. One byte/frame isn't going to cut it, though, which is part of why I was thinking an accellerator would be nice. Even at 16 bytes/frame, the transmission speed would still be a limitting factor but it would be more reasonable. Going to a 12C509 would allow the amount of data to be increased to about 28 bytes/frame (the PIC wouldn't do simultaneous RX/TX, so the theoretically-possible 32 bytes/60Hz frame would not be workable in practice).

 

Too bad that AFAICT there's no way to code music macros (except singing ones). Also, BTW, how much EEPROM to do you use for the jingle and do you start at the beginning?

[Alex H]

there is a noticeable lag on some of the sound effects, most notably the burp

I've not noticed that

That's deliberate. I put a pause in the data so he burps a moment after eating the food. I also tend to put short pauses at the start of other speech strings in case one bit of speech interrupts another. (Not that that happens much in MGD.) I made a habbit of doing that after coding the Verzerk speech hack (Vectrex) where speech strings get interrupted more often. Just sounds better that way.

[supercat]

That's deliberate.  I put a pause in the data so he burps a moment after eating the food.  I also tend to put short pauses at the start of other speech strings in case one bit of speech interrupts another.  (Not that that happens much in MGD.)

900519[/snapback]

 

I can see that it could at times be advantageous, but it would seem that when communicating at 60 bytes/sec, latency would be hard to avoid whether you wanted it or not.

 

BTW, any idea when you'll have a real cart ready for sale?

[Alex H]

I can see that it could at times be advantageous, but it would seem that when communicating at 60 bytes/sec, latency would be hard to avoid whether you wanted it or not.

50/60 bytes/sec is fine for speech, not so good for the synth. I output the speech during overscan which has little else in it apart from sound. At one point I was testing the timer after sending a byte and if there's enough time, repeat. (Usually fitting in 3 bytes per frame.) But I couldn't hear the difference. With the longer speech strings it was filling the SpeakJet buffer anyway at a single byte per frame, so there seemed little advantage.

 

The latency is pretty tiny unless there's a whole heap of control codes. The way I look at it, latency isn't a problem if the user can't/doesn't notice it. But I must admit, I haven't done much with the SpeakJet synth functions.

 

BTW, any idea when you'll have a real cart ready for sale?

I've only just started work on it again after being unwell recently. But I'm hoping to have a finished version (or nearly finished) for CGEUK on 13th Aug. So hopefully not too long after then.

[Richard H.]

BTW, how much EEPROM to do you use for the jingle and do you start at the beginning?

 

37 bytes out of 256

 

The AVox startup is just replacing the normal SpeakJet's default power-up and reset - 'ready'

 

 

Have you seen the original PhraseALator ?

 

(I stripped some stuff out of the original for the utility)

[philipj]

I know it's been a year since anyone has responded to this topic... Has anyone had any success making music using the "Atarivox"???