Jump to content

The Southsider

  • entries
    81
  • comments
    767
  • views
    138,547

cd-w

4,588 views

When I first heard about the AtariVox I wasn't too impressed with the sound quality, and decided not to bother getting one. However, I changed my mind after seeing a demo of Man Goes Down at the vgXpo a few years ago. I realised that the sound quality was a perfect match for the Atari, being broadly equivalent to the quality of speech chips back in the day. I now think it would sound "wrong" if the Atari were to produce high-quality speech, just as it would sound unnatural if Stephen Hawking were to upgrade his speech unit.

 

I bought an AtariVox when they became available again (in the new casing), but didn't actually use it until today. The main reason being that my Atari gear has been in storage since I last moved, and I'm about to move again. I was able to use the AtariVox now due to the acquisition of the handy AtariVox USB adapter, pictured below:

 

blogentry-6563-1205249581_thumb.jpg

 

The USB adapter enables the AtariVox to be used from a normal PC, without the need for an Atari console. This might seem rather pointless, but the main reason for using this adaptor is that it makes AtariVox development much easier. Since the AtariVox is not (yet) supported by any of the emulators, it was previously necessary to write a test program and then upload it to the Atari, e.g. using the Krokodile cart. With the USB adapter, the AtariVox can be programmed directly from the PC. Incidentally, I was grateful for Nathan's review of the AtariVox, since my unit was indeed set to maximum volume. Using the USB adapter is simple - just plug it into the PC, and Windows recognises it as a serial USB device (Mac and Linux users will not be so lucky). The AtariVox can then be programmed using the hacked PhraseALator software or VoxPlay.

 

It turns out that the AtariVox is not particularly easy to program. It is capable of making a wide range of sounds, but assembling these sounds into recognisable speech can take a lot of trial and error. Fortunately the PhraseALator software has a reasonably large dictionary that can be used in many cases. I also found that I got rapidly better at figuring out the necessary sounds after a bit of practise. Here is a reasonable approximation to "Juno First":

 

\JH \UW \NO \OWWW \P1 \FF \AXRR \SE \TT

 

I now think that the AtariVox is quite a cool bit of hardware, and the USB interface makes it much easier to develop for. I'm planning to use it in my future software projects, though I'm not sure I will be able to use it in Juno First, since it requires rather a lot of cycles - perhaps just a few bits of speech during the title screen. Now, if only it was as easy to develop for the Savekey ...

 

Chris

30 Comments


Recommended Comments



Still todo is OSX support, which is proving to be more difficult since the VCP drivers don't seem to recognize the AVox USB adaptor.

Check with Nathan, he got it recognized on his. Hopefully he can send you the specific driver he used.

I figured it out. It seems OSX doesn't detect this device as plug-and-play; you have to reboot with the device already plugged in. So I'm confident I can add support for OSX sometime tomorrow.

 

OK, I now have support in OSX as well, thanks to Spiceware's serial port code. Now on to the EEPROM emulation ...

Link to comment
Also todo before the next release is the EEPROM emulation. This will be to a file (perhaps named 'atarivox_eeprom.dat') and not directly to the AVox device. But that will still be very useful for testing and debugging, and will save wear and tear on the actual EEPROM.

 

It will also probably allow smoother emulation. For the most part, it doesn't really matter how long it takes for serial data generated by the 6507 to make it out to the AtariVox, nor how long it takes for the handshake signal to return. The PC can easily provide some buffering to deal with those things. By contrast, whenever the 6507 does anything with the I2C, it needs to see what the I2C is doing in response. Even a reasonably-optimized I2C/usb peripheral would take 2ms to handle each byte of data. If Strat-O-Gems were run using such a device, it would need to spend (if I recall correctly) 12ms per frame to handle I2C stuff. It would thus be necessary to do everything else in the frame in 4.6ms. Might be doable on a fast enough CPU, but the CPU would have to be four times as fast as would otherwise be necessary--and I was being reasonably 'nice' in my assumptions about the I2C/USB hardware.

Related to this, I have some questions about your EEPROM emulation code. I'll send you a PM on it.

Link to comment
Note that this support won't be in the next release, which I hope to do in the next 2-3 weeks.

Will this release fix the graphic glitches I reported a while ago?

Just thought I'd add that the Swoops! graphical glitch will be fixed for the next release (as will similar bugs for Mission Survive and Solaris). Note that these were fixed by 'cheating', and not by actually fixing the TIA core. That's still meant for a future release, where we hope to have a cycle-exact TIA emulation that doesn't have any hacks at all.

Link to comment
OK, I now have support in OSX as well, thanks to Spiceware's serial port code. Now on to the EEPROM emulation ...

Sweet! Glad I was able to help.

Link to comment

As of OSX 10.8 onward, Apple has its own driver for FTDI USB devices.

DO NOT INSTALL ANY DRIVERS!

 

After 4 years of wondering why this didn't work on my Mac, but worked on other people's Macs, I found removing the driver kext extension and pkg receipts makes this hardware work.

Link to comment

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...