Working on it.

Is this list up to date?

Grizzards (64k) Interworldly Adventuring LLC / Bruce-Robert Pocock & Zephyr Salz AtariVox Features: (retail) speech; (download/PlusCart) speech & save game data Original thread: https://forums.atariage.com/topic/322957-grizzards-—-turn-based-rpg-completed/ Available for purchase: AtariAge (2022) https://www.atariage.com/store/index.php?l=product_detail&p=1273 Latest ROMs: https://Grizzards.com/ The retail cartridge has save-to-cart tech with 8 save game slots, but still uses AtariVox for speech; the download version requires an AtariVox (or SaveKey, MemCard) for the save-game slots as well. There's also a 32kiB "NoSave" demo which does not require any memory device, but is limited to the first area as a result.

Much obliged! I'll work on it in the coming month. Hopefully others will be able to fill me in on any I might have missed. I think it's important to have one central listing of all such games, including for the Vectrex. I think we should market this list to the homebrew devs for all three systems, so that when someone makes a new game that supports the AtariVox they create a post on here, so that it can later be added to this list. That way, this also becomes a marketing tool for them for letting AtariVox owners/enthusiasts know that there is a new game they might be extra interested in. Folks who follow this topic will get an email whenever a new game is added.

If you'd like to create the necessary updates in a reply (following the format of the first post, I'd be glad to add them. I just haven't had the chance to keep up with the releases, and any help would be greatly appreciated.

I noticed Grizzards isn't added to the list yet. There have been some other games that have come out in the last few years since this was last updated. I could take a first stab at providing info to be added. No reason this should all fall on one person's shoulders.

Apparently, based on a post I read on AA, there are 2 versions of the Rev. 2 AtariVox+. The person in that post was calling the newer version Rev. 3, but I think it's still called Rev. 2, because it is likely functionally the same. The difference they noticed is that it uses SMDs. Those SMDs could very well be using less power than the DIPs used in the original Rev. 2. I'm guessing that the SMD changeover *might* line up with the newer label with the diamond instead of the dot between "Vectrex" and "Enhanced".

Does anyone happen to know what both nominal and peak power consumption are for a Rev. 2 AtariVox+? I've got a small circuit I'm incorporating one into and it would be handy to know these numbers if they're available. FWIW, I don't believe that it'll draw over 100mA, but I've been wrong before

Sorry to hear that you're having issues. But at the same time, glad to hear that it is not because of Stella ?

Well... this doesn't have anything to do with Windows, but it may be related. When testing Gorf over the last few days, my AtariVox (using Stella) was clipping off long phrases - mashing the last several words together. We'd run into this issue months ago, and the issue happened on both of my AtariVoxes, both consoles I tested them with, and in Stella. John couldn't find the exact cause, but backpedaling to an earlier build fixed the problem. It's been fine since, up until a few days ago. The problem started happening in Stella, and I thought, "Here we go again". But when I tested it on my 2600 with another AtariVox, it was fine. When I moved my 2600's AtariVox over to Stella, it was still fine. And when I put my original AtariVox back on Stella... it was fine. The problem was gone. (And I should also note - there were three builds having this issue. All behaved the same.) I had unplugged the serial adapter when changing the AtariVoxes, and I *think* MacOS re-loads the FTDI driver when it sees a device needing it. So that (or maybe the AtariVox being unplugged?) fixed the issue. So this wasn't the same problem as before. This was something weird that had nothing to do with Gorf. But what caused the issue? Speakalator. RevEng's Mac/Unix version of Phrase-a-lator. SpeakALator is... well... buggy. It almost never plays complete phrases without glitching. And I was using it right before testing the Gorf build where phrases started getting truncated. So what seems to have happened, is SpeakALator caused an issue with either the FTDI driver or the AtariVox itself, that held over to when Stella was trying to use it. Not sure if there's a memory buffer in the AtariVox, or a data cache somewhere, or what exactly happened. But I know that the next time I use SpeakALator - I'm unplugging my AtariVox and USB interface afterwards.

I wonder if Stella can't access the port because Phrase-a-lator is somehow still tying it up? We used to have issues with video playback hardware like that, where if one app didn't exit cleanly, it wouldn't release the hardware so other apps would still think of it as being busy.

Thanks Nathan, this is what I downloaded before but couldn't remember. Unfortunately though, I did install them and confirmed they're being used for the serial port but it's still not working (still working though Phrase-a-lator). I'll try to reboot to see if that fixes the issue. The FTDI stuff would be helpful for sure! Thanks! Thanks TJ, I tried that as well but it didn't help. If I figure it out, I'll post my findings here. Thanks! John

You could try to swap the Stelladaptor ports in Stella (Ctrl+1).

You may need to download and reinstall the FTDI driver: https://ftdichip.com/drivers/ I had an issue (admittedly on the Mac) where I had to reload the drivers (by restarting the computer) every time I wanted Stella to recognize the AtariVox. This is no longer the case, but I don't recall if an OS update fixed it, or a driver update did. I suppose I should really update the info here to include something about using USB-serial interfaces.

Hello all, I'm trying to configure Stella to work with my AtariVox plugged into my Windows 10 PC (Using Richard H.'s AtariVox serial/USB adapter). I got this working before but my system crashed and I had to reinstall everything from scratch. ? Anyway, when I hook up the Avox to the serial adapter and then my computer, it's identified as USB Serial Converter under USB controllers and COM11 under Ports (COM & LPT). Using Phrase-a-lator, I am able to play phrases through the AtariVox without issue (it's configured for COM11, 19200 baud). I made sure my game is using Atarivox on port B and that the AtariVox port is COM11. The device is detected on game startup (Wizard of Wor Arcade and Gorf Arcade) but no speech is played. ? Am I missing a step? I seem to recall there was some Windows serial driver update, but I may be wrong about that. It seems if it works through Phrase-a-lator then the USB serial adapter is working fine and the Avox itself, so that leaves Stella, but the only setting is the COM port, and the only option is COM11 (which makes sense since that is the only COM port on the PC). Any suggestions or assistance is appreciated! Thanks, John

64 bytes, according to the manual.

Thanks, I figured it would have something to do with the READY pin. I wouldn't want actual speech playing the detection phase so I assume I could fill in the buffer with a bunch of control commands (ie. loop setting the PITCH over and over and see if RDY ever drops to 1). Do you know how big the buffer?

What about sending some long enough speech data and check if the READY pin (pin 2 of the controller port, that is SWCHA bit 1/bit 5 for the right/left port respectively) ever reads as 0, indicating that the Speakerjet buffer is full? On a SaveKey that pin should be unused (floating) and always read as 1.

Hi there! As I finish up Gorf Arcade, I was looking into updating my SaveKey detection routine so that it can also determine if there is an AtariVox connected vs. just a SaveKey. I already know how to detect a SaveKey, but was was wondering how or if other programmers detect if the SaveKey is actually an AtariVox? I'm stepping through the Speakjet code through Stella to see if there is any difference (ie. carry flag set/reset if you attempt to write to the Speakjet and it's not there, etc.) between configuring a SaveKey vs. and AtariVox but figured I'd see if there is already a tried-and-true method available. Any help is greatly appreciated! Thanks, John

I didn't notice this list until djpowerplayer's comment brought it up to the top … Grizzards also uses AtariVox both for saving and prattling on quite a lot. (All signposts, all NPC dialog, and combat narration, among other bits.) I've lately noticed that the allocation list got rolled back to an earlier version that omits us (messaged Albert about it) The Demo uses Scratchpad space, but the full game uses dedicated blocks.

It would be nice if someone added AtariVox support for Centipede and Millipede.

Yeah, but it needs to be clear for the first byte that is read only (the state it will be in after i2c_startwrite). Subsequent bytes will need overflow to be set, not clear (i2c_rxbyte sets overflow). I think this is a rare corner case that few people see, because in most cases, loading is done all at once at the beginning, and not spread out over several frames with other processing in-between. Also, it won't be an issue if you re-initialize every time you read more bytes. I wrote a small test program just to make sure what I understood about the behavior was correct, and that there was nothing different about how the normal right port driver performs compared to the left. This loads a block of data at $3000 at startup (the numbers 63 to 0 descending), then loads them into RAM two bytes per frame. It displays the contents of that block of RAM on the screen as colors. Fire button: Reload data Left Difficulty=B: Save and restore processor status to preserve the overflow flag. Left Difficulty=A: Do not restore processor status (overflow is cleared before the load function). testread.zip

No, I don't think it is the left driver. Have you tried to simply clear the V-flag instead of restoring it?

You are thinking that this issue is something particular to the changes made to the left driver, then? It looks like the driver sends an acknowledge bit if overflow is set when doing an i2c_rxbyte, and then sets overflow explicitly, presumably for the next byte. Maybe I can do a simple test program to read a couple of bytes each frame using only the right driver, and seeing if clearing the overflow between reads stops the reads from working as I am seeing in my utility. That would confirm or eliminate the modified left driver as a factor.

Yes, the V-flag is used by the i2c include file (not that it is cleared in SetupSaveKey). But usually you do not have to care for it. Probably you have modified the code so that it becomes important.