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.

Okay, so I did decide to go back and figure this out even though I have a working utility now because I wanted to understand what was going on. TL;DR I think the issue was that you need to preserve the overflow flag if you run other code between reads without reinitializing the read everytime. I was getting indeterminate results because I was running my subsequent reads with the overflow flag in an indeterminate state after running other code. If I reinitialized the read every time I read some bytes, and ran the i2c_rxbyte calls back to back afterwards, then this wouldn't be an issue. The overflow flag being set or clear determines whether or not the code sends an acknowledge bit to the device. Now before I call the routine to continue my read, I have this code to restore the state of the overflow flag: lda ProcessorStatus pha plp And after I run my routine, I have this code to save the state of the overflow flag: php pla sta ProcessorStatus @Thomas Jentzsch @RevEng, or anyone else who is highly familiar with the savekey driver code, does my reasoning seem sound here? Here's my current source/ROM with drivers: copyvox2.zip

Whelp ... I put aside trying to find the cause of this, and went ahead and finished the utility. After all of the changes I made, I can't reproduce the original problem. So ... I guess accidentally fixed by code redesign? It kind of bugs me not knowing what was going on, but perhaps not enough to spend a lot of time debugging something that works now. Anyway, here is the latest version. I'll probably make a topic in the 2600 Programming forum as well. Usage: After launching the utility, plug the source AtariVox/SaveKey into the left port, and the destination AV/SK into the right port, then press Reset. The utility will then attempt to detect the devices, and report the results. If both are detected, you can hit Reset again to begin the copy. The default mode is "No Overwrite", where the utility will not overwrite any blocks on the destination device that are not blank (all $FF value). Hitting Select before starting the copy changes the mode to "Overwrite", which will replace non-empty blocks on the destination device with the contents of the source device. In both modes, to save time and writes, blank blocks from the source device are not written to the destination device. I have tested this in Stella and on hardware successfully, but use with caution as there may still be some bugs that I haven't seen. copyvox.bin

I had thought that you were sending the start address on every call to LoadSaveKey and maybe the EEPROM could get confused between the address writes. I see now on a closer read that you're only doing the address write every 64 bytes, so that's probably not a concern really. (I do do random reads more-or-less back-to-back without a wait-for-ack.) One thing that's probably completely irrelevant is that the data sheet (p.13, § 8.3) says > Following the final byte transmitted to the master [the console], the master will NOT [emph. orig.] generate an Acknowledge, but will generate a Stop condition. … but the driver code does always send an ack in your i2c_rxbyte[l] routines. My code (which is closely based on the same original) does the same thing, though, without issues. Sorry to not be more helpful. I'll have to look that up now (now that it's “too late for me” I suppose, but I am curious.)

Another update. apparently my reads stop working after I run my ProgressBar sub during the visible screen. When I comment it out, everything works fine. I definitely don't see anything in there that could cause this, however, so I'll work on figuring out that part next.

I'm the one who altered the driver to work on the left port (with extensive help from @Thomas Jentzsch), and I didn't update cycle counts in comments when I did so. The issue I'm having in on a read. As for writes, I do wait for the better part of a frame after doing a stopwrite before doing any other operation. Come to think of it, I shouldn't even have to do that since the writes are to the right SaveKey, and the next operation is a read from the left SaveKey. Yes, I'm reading 2 bytes per pass, but 2 times per frame: vertical blank, the unused portion of the visible screen, and overscan. I don't do an i2c_stopreadl until I'm done with the entire block, though. This was copied from @Thomas Jentzsch's code in the SaveKey for Dummies topic for the address initialization portion of the SaveKey setup.

LoL. I was just about to offer to test on hardware but you beat me to it. I did see that the comments in the “left” source seem to be incorrect w.r.t. the longer procedures. eg: if I2C_TXBITL takes 30 cycles rather than 22, then i2c_startreadl is really more like 38/39 cycles. I ran into a problem when trying to do back-to-back writes, and had to inject something to wait for ACK. Looking at the offending code (around ll. 516-539) briefly it looks like you're reading two bytes per operation, (per frame, I think?) and maybe the write of the new start address on each pass is not registering because there's no wait-for-ack after the last stop reading? That seems like a real stretch, though, if that's really a whole frame apart. I'm also a little curious about the `clv` at line 517, as I don't recall ever having to do that.

Update: I decided to take the plunge and run it on hardware, after all. I saw the same results as under Stella: only the first two bytes are read correctly, and the rest are read as $FF, as if I had run i2c_stopwritel prematurely. As far as I can tell, the only difference between the first two bytes read and all the others is the passage of time. Anyway, I can at least rule out Stella's AtariVox/SaveKey emulation from the left port as a cause.