e1will

Thanks for testing that. Yeah, that's what I was afraid of... I'll have to play around with the playfield drawing some more, it seems. As for Lady Bug, the fact that JohnnyWC was able to pull it off so brilliantly for the 2600 is my main encouragement for thing Super Pac-Man might be possible too. But as you point out, getting colors that blend the way they need to is going to be mighty tricky. --Will

Thanks. Good idea on the playfield... I may do that once I get the kernel straightened out. That may also enable a way to patch together up and down sprites with the ball sprite using an alternate frame/venetian blind approach for the left and right halves. --Will

Hello, I'm toying with the idea of writing a Super Pac-Man conversion for the 2600. Can someone with a Harmony cartridge or similar setup give this a test on real hardware and tell me how bad the flicker is? It looks OK in Stella if the phosphor effect is enabled (Alt-P) but it looks horrible if it isn't. Also, I'm doing some funky things with HMOVE timings to cut down on the HMOVE bars so I'm curious if that breaks anything on a real 2600. Here's what it SHOULD look like... --Will SUPERPAC.BIN

You may be able to get it to do that in bB (I don't know very much about bB) but you can definitely do it in assembly, with some flicker. If you write Player 1's score and line count on the left in frame 1, then Player 2's score and line count on the right in frame 2, you could get something like this. --Will

Yes... but if you want to stick with bBasic you could just show them on alternate frames. Show one for a few seconds, then the other, color-coded to help indicate what's what. --Will

Oops, I should have mentioned you'll need to set NUSIZn appropriately before calling that: LDA #$01 STA NUSIZ0 STA NUSIZ1 --Will

I haven't gone through the .asm you posted, but here's how I do it in the game I'm working on: WriteLives STA WSYNC NOP3 WriteLives_loop LDA graphicPtr,Y DEY BPL KeepOnWriting RTS KeepOnWriting STA.w GRP0 STA GRP1 REPEAT 8 STA RESP0 STA RESP1 REPEND STA RESP0 STX GRP1 STX GRP0 JMP WriteLives_loop It's a little clunky, but it works. Give that a try in Stella... works fine with 2.8.x and 3.0. Hope this helps. --Will

Thank you very much!

I don't have any info on the driving controllers (I'd be curious to see some of those answers myself), but regarding "sticking" them in driving controller mode, you could always snap back to joystick mode if you saw a 10nn or 01nn pattern, meaning they'd pushed the joystick left or right. Should be a quick test you can run every few frames as a sanity check... chances are if there was a noise issue where the game thought it was a DC but they had a joystick, the player would probably wiggle it in various directions to get a response. --Will

Thanks!

Hello everyone! Here's the latest version: v0.11. This has a new feature for AtariVox and SaveKey users (and Stella users too): You can save your game and return to it later. This is handy if you've reached level 14 or so and don't want to lose your place, but need to go do something else. (Like play Juno First for a few hours.) You can load your game exactly where you left off when you return. To save your game, go to the egg shelf room (screenshot attached) and press the Fire button on the joystick. If the program was able to save the game successfully, it will move you to the score room. If it was unsuccessful, it will move you to the credits room. It will be unsuccessful if you don't have an AtariVox or SaveKey attached (or if you're running in an emulator and don't have the game properties configured to use an AtariVox or SaveKey as the P1 controller.) To load your game, start a new game, go to the egg shelf room and press Reset on the console. If the program was able to load the game successfully, it will move you to the score room; if not, to the credits room. Special thanks to stephena and especially cd-w for the help in getting the AtariVox interface working correctly. There is a known issue where the screen will roll while it's reading from or writing to the save file. That's on the to-fix list. I've got some more neat stuff on the way for the next version, so stay tuned... --Will

No, I never do documentation. Unfortunately I am pretty busy over the next weeks, so most likely I won't have time to look at the code again. Maybe someone else can help? Oh, no problem. I've got it working with the original code, so I'm using that. (Actually, I'm trying my own optimizations at that, which I'll post if they work.) --Will

The optimized code was tested to work, so I suppose that it is mainly a documentation flaw. Probably a return value is different from what you expect. Is there additional documentation available for the optimized code? I was just going by the code example from AtariVox.rtf (revision date 2004-NOV-16), perhaps that doc is out of date? --Will

Thanks! My problem now is that the 107-byte optimized code gave me just enough room to get the save/load features in... I had to temporarily comment some stuff out to get the 169-byte original to fit, so I'm going to be in code-squish mode for a while. 32k seemed so roomy when I started! --Will

Swapping in the original i2c.inc fixed the issue! I'm able to write to the .dat without problems now. I'm using the same example code, the only change is including i2c.inc instead of i2c_v2_2.inc. Thanks for the debugging help; I really appreciate it. --Will

Well, if I comment out the BCS (and the ROR I just added) and just let the example code plow on through with its jsr i2c_txbytes, the .dat file is not updated (contents all $FF, Windows modification date unchanged.) I assume you're not using Thomas's optimized version in Juno First? Would I be better served to just use Alex's original version? Or are there known bugs with it? --Will buffer = $80 jsr i2c_startwrite ; Start signal and $a0 command byte ; ROR ; bcs eeprom_error ; exit if command byte not acknowledged lda #$01 ; upper byte of address jsr i2c_txbyte lda #$40 ; lower byte of address jsr i2c_txbyte ldx #$00 write_loop lda buffer,x ; get byte from RAM jsr i2c_txbyte ; transmit to EEPROM inx cpx #$08 ; 8 bytes sent? bne write_loop jsr i2c_stopwrite ; terminate write and commit to memory clc rts eeprom_error jsr i2c_stopwrite ; terminate write and commit to memory sec rts

Hmm. When you ran it, what did i2c_startwrite return in the accumulator? It's returning $01 when I run it, I assume that indicates failure? Or does bit 0 set mean success? --Will

Ah! I'll give that a try, then. Thanks! --Will

I'm having a bit of trouble finding the AtariVox calls in your code. Can you let me know when they are called in the game, and which bank/address they are at. Ideally, if you could separate the AVox stuff from your main code and post the source, or post a symbol file for the Stella debugger? Chris Sure, symbol file attached. --Will EDIT: The jsr i2c_startwrite call is the only call in the game that pushes the stack pointer down to F3, so if you have trouble locating that call you can just add a breakif {sp==F3} and it will catch there. Starting a game, move the robot to the right door and into the light blue room, then pressing the fire button is what triggers the AtariVox call. DUCKNTSC.zip

If I understand correctly, the problem is the very first "jsr i2c_startwrite" command, before any AtariVox or SaveKey programming is performed. I suggest that e1will posts the binary containing the problem so that we can debug it and see why this is happening. Chris Correct, the first jsr i2c_startwrite is failing (setting the carry flag.) The binary is posted above (post #18), the first jsr i2c_startwrite is at $B9C3. Either stepping through it in the debugger or letting it run at normal speed seems to produce the same results. --Will

Yep, definitely restarting Stella each time. What's interesting is when I recompile the ROM, Stella will "forget" that I've specified AtariVox for the P1 controller (perhaps it uses a checksum or modification date rather than simply the filepath of the ROM?) and reverts it to Joystick, but regardless I do change the controller setting outside of the game (and then confirm it's still set correctly by looking at the config after starting the game.) --Will EDIT: Tried it with the commandline argument, still can't access the EEPROM: Stella.exe -fullscreen -1 -rc atarivox DUCKNTSC.BIN

Setting the P1 controller to SaveKey gives the same results. Juno First is working fine saving and retrieving its high scores, so Stella is able to read and write to the .dat file. The stack pointer is at $F7 when the SaveAndLoad_Main function (which contains the example code) is called, and drops to $F5 when the jsr i2c_startwrite is called; the temp variable is at $DD, so there shouldn't be a conflict there. Here's how I'm calling it: the main game loop calls a joystick input function (PlayerMove, at $F374 in bank 7), which checks if the fire button is being pressed in the egg shelf room. If it is, it JSRs to the SaveGame function, which JSRs to the SaveAndLoad_Main function ($B9C3 in bank 3) which contains the example code. The first thing that function does is call jsr i2c_startwrite, which on return has the carry flag set. (And viewing the contents of the .dat file confirm nothing has been changed from all $FF's.) When SaveAndLoad_Main returns, it puts the player in either the score room (if the carry flag is clear, meaning success) or the credits room (if the carry flag is set, meaning failure), and so far it has always done the latter. --Will DUCKNTSC.BIN

Well, I'm brand new to programming for the AtariVox, and I must be making a rookie mistake, although I don't know what it is. I'm including Thomas's i2c_v2_2.inc, I'm using the example code from AtariVox.rtf EXACTLY as it's written, and I've got my ROM configured in Stella to look for the AtariVox in the right port (screenshot attached). But when the example code runs, the first jsr i2c_startwrite always returns with the carry flag set, which from the documentation means it was unable to communicate with the port. buffer = $80 jsr i2c_startwrite ; Start signal and $a0 command byte bcs eeprom_error ; exit if command byte not acknowledged lda #$01 ; upper byte of address jsr i2c_txbyte lda #$40 ; lower byte of address jsr i2c_txbyte ldx #$00 write_loop lda buffer,x ; get byte from RAM jsr i2c_txbyte ; transmit to EEPROM inx cpx #$08 ; 8 bytes sent? bne write_loop eeprom_error jsr i2c_stopwrite ; terminate write and commit to memory rts Is there some initialization that I'm missing? Or a Stella configuration option I've missed? --Will

I've tried specifying different locations for EEPROM path, including these: ~\Application Data\Stella\ C:\Stella\ ...and I get the same results each time. I know it's not a Windows permissions issue, since Stella has no problem with the "Save ROM" feature in the debugger with ROMs in the same directory as what's specified in the EEPROM path. This behavior is consistent with other games I've tried that have AtariVox functionality (e.g. Juno First says "SAVEKEY CARD NOT FOUND!" when I start it in the emulator.) Anything else I might try? Am I correct in understanding that Stella should create C:\Stella\atarivox_eeprom.dat if stella.ini shows "eepromdir = C:\Stella\" and I start a game like Juno First? --Will EDIT: Nevermind! The problem was the P1 controller type. Apparently it had reverted to Joystick somehow. Changing it back to AtariVox fixed the problem. Thanks for the reminder to check that setting.

Is Stella 3.0 handling the AtariVox EEPROM emulation differently than 2.8.x did? I can't seem to get 3.0 to either read the existing atarivox_eeprom.dat file or create a new one, and running games that worked fine under 2.8.4 (e.g. Man Goes Down) no longer save or load under 3.0. --Will