bB AtariVox Support, Part 1... the AtariVox EEPROM

[RevEng]

 

Have you tested it on real AtariVox hardware and not just in Stella? e1will reported some problems with the optimized i2c driver when he attempted to use it in Duck Attack (possibly timing related).

 

Chris

I couldn't find the post(s) where he reported the problems - do you have a link?

 

I believe it was this thread. The topic is completely different, so it's no wonder you didn't find it. I believe the problem Will reported showed up in stella as well, actually.

 

When I tested the Thomas' driver, I was able to get it working by ignoring the carry flag. (which isn't used as an error flag like it is in Alex's driver)

 

But after the test I reverted back to Alex's driver, just to be on the safe side. It didn't make a huge difference, and since I'm working on the visible screen now, I'm not tight for cycles.

 

Thanks for the heads-up, Chris!

[+batari]

Screen blanking is OK for now but a spinner kernel would be nice as some televisions really hate it when they don't get vertical sync signals (my plasma will actually shut itself off in about 5 seconds.) The kernel could consist of VSYNC, then 120-ish lines of nothing, eight 2LK lines of player graphics (perhaps as a number of frames specified by the programmer?) then 120-ish lines of nothing again. During those lines of nothing, you could either do a fixed number of reads or just check INTIM and service the kernel/VSYNC if below a certain threshold.

[+stephena]

I'm not remembering all the fine details ATM, but at least one version of Thomas' optimized i2c driver actually didn't follow the rules for accessing the device precisely. While this worked on actual hardware, it failed in Stella. The implementation in Stella follows the i2c protocol explicitly, as it's supposed to be done. Thomas released an updated version of his optimized code that fixed this issue. I strongly suggest that you track down this updated code and use it instead. It's better to 'nip this in the bud' now, before too many people start using it, or you integrate it into a kernel, or whatever.

 

As I said, I don't recall the exact details, and I don't think I have the emails any longer. IIRC, it came down to both the SDA and SCL lines being in an invalid state in the i2c protocol. And while it worked on real (current) hardware, there's no guarantee that it will work on future hardware, or that it will keep working on current hardware. It's basically a timing/race issue.

 

So long story short, best not to depend on this behaviour, and track down the i2c code that fixes the problem.

[RevEng]

I'm not remembering all the fine details ATM, but at least one version of Thomas' optimized i2c driver actually didn't follow the rules for accessing the device precisely. While this worked on actual hardware, it failed in Stella. The implementation in Stella follows the i2c protocol explicitly, as it's supposed to be done. Thomas released an updated version of his optimized code that fixed this issue. I strongly suggest that you track down this updated code and use it instead. It's better to 'nip this in the bud' now, before too many people start using it, or you integrate it into a kernel, or whatever.

Thanks. I believe it was his first version, according to his second version post.

 

I was just using Thomas' version for a benchmark test, to see how much I could get done in overscan using the optimized code.

 

The version I'm working with now is Alex's original driver, which I've verified as "working great" with both Stella and real hardware. I prefer the error handling via the carry flag in that version.

[RevEng]

The first post has been updated with my first crack at the filesystem area code and updated static area access code.

 

There was a small bug in the error return code for the Static Area byte reading function, so if anyone is using the previous code they should get the new version.

 

I've tested the Filesystem Area code a fair bit, throwing test cases at it with Stella and a hex editor; I don't believe there are any major bugs.

[+Atarius Maximus]

Here's a slightly updated AtariVox/Save Key Sample Program that uses the static area. I thought it would be useful to bundle RevEng's original sample into a very short, simple game that shows all of the basics that you need to know to integrate it into a bB game, as well as showing how to compare and save high scores.

 

The game starts with a titlescreen that shows the current high score. Press fire to start the demo game.

Push up on joystick to move the arrow sprite up. You will score points as long as it comes in contact with the playfield.

When it scrolls off the top of the screen the 'game' is over and you are taken to an end screen that shows your current score. Press fire again to return to the title screen.

If your new score was higher, it will display the new high score on the title screen. If your new score was lower, it will display the old high score on the title screen.

From the titlescreen, push up on the joystick along with the game select switch (F1 in Stella) and it will clear your current high score.

Of course don't forget to enable the SaveKey in Stella or launch it with 'stella -rc savekey game.bin'.

 

The source code has lots of comments and will hopefully be useful to those trying to figure out how to access the eeprom in their games. I don't have a sample of how to use the file area at this point. For those working on smaller games, Cybearg informed me that he noticed the file area include uses more ROM space (~720bytes as compared to ~300 bytes).

 

Steve

 

EDIT: Richard assigns the static locations in 64 byte areas and saving a single high score in bB uses only 3 bytes. A whole lot of bB games with single highscore saving would fit into a single assigned 64 byte area. As long as he doesn't mind, I'll probably be adding additional games to the same allocation area he already assigned me.

 

I updated the attachments with RevEng's modifications.

SavekeyStaticDemo.bas.bin

SavekeyStaticDemo.txt

[Cybearg]

I'm using the latest version of Stella (3.8.1) and have set the second controller to SaveKey (I had been mistakenly setting it to AtariVox), but it still doesn't save/load values. The score is just solid bars when I load the game, after I hit trigger once the game has ended (and I return to the title screen), and if I restart the game.

 

Is this just me?

[Cybearg]

I've been trying to implement SaveKey functionality into one of my games, but while it apparently was successful at writing to memory (the code that detects whether a write to the scratchpad was successful or not returned a value that confirmed it was working), it either doesn't write the correct values or it just doesn't read them correctly, because even with Atarius' save key demo, I always get blank or garbled returns when I try to save and load a score to the SaveKey.

 

Any idea what's wrong? I've tried deleting Stella's atarivox/savekey files to make sure there's no corruption there and I've tried plugging in both AtariVox and SaveKey into port 2 in Stella.

[+Atarius Maximus]

I generally launch from the command line. I tried it the other way just now with launching Stella first, selecting the game, then changing the controller port options. It didn't work when I selected the savekey for port 2, but worked fine when I selected the savekey for both port 1 and port 2 together. I'm not sure what the correct way to do it is, but that worked for me.

[Cybearg]

I've tried the command line and just now tried putting savekey in both ports. Still nothing for me, even while using your demo. :/

 

EDIT: I've continued to fiddle around, checking out the documentation, and I still can't get it to work.

 

What SHOULD I be seeing when I run your static demo? I open the game, see the score displayed as a solid line, then press fire and the score turns to zeroes. When I move up and onto the playfield, I start gaining points. I then move off the playfield and through the gate at the top of the screen and the playfield goes grey with my total score displayed at the bottom. I press fire and I'm back on the title screen, again with the score being a solid bar. Et cetera.

 

Should it be returning my results to the main score on the title screen instead of the solid bar? I can see that my eeprom file is being created by Stella, but it's not being modified, even though I have AtariVox plugged into the right controller port (that's correct, right?).

Edited March 22, 2013 by Cybearg

[+stephena]

Some notes:

1. The SaveKeyStaticdemo ROM doesn't work for me in Linux or Windows.
   
2. From the POV of saving data, both the AtariVox and the Savekey do exactly the same thing (they use the same code in Stella, just save to a different file).
   
3. Atarivox and Savekey only work when attached to the right port. If you specify to use the left port, the setting is ignored (maybe this needs to be updated, but it has nothing to do with the problem at hand).
   
4. Changing ROM properties (such as the controller type) within the UI required a reload of the ROM. This is clearly indicated at the bottom of the properties window.
   

There seems again to be initialization issues. When loading this ROM with an already existing EEPROM file, some numbers came up in the game (I believe, 21.7 or something). But after erasing the EEPROM file, it always comes up as a solid bar, both in Linux and Windows. Seeing that your previous ROM works, and all the AtariVox/SaveKey ROMs I have still work, I think it must be something in your code.

[RevEng]

Small bug - the test to check if the score was "$ff" (and thus needing initialization) was prior to reading the score in from eeprom.

 

[the fixed version was updated in Atarius Maximus' original post]

[+Atarius Maximus]

Thanks Mike. I have no idea why it was working fine for me in emulation in my testing. I'll update my post a little later.

[Cybearg]

RevEng's original example works for me as well, or at least so I assume since it displays the same numbers in score and score+2. I can't get my own code or Atarius' to work, though, even after the above changes. :<

Edited March 22, 2013 by Cybearg

[RevEng]

Does my update binary work for you? (the game doesn't save until you press the firebutton to restart)

[+stephena]

Does my update binary work for you? (the game doesn't save until you press the firebutton to restart)

 

Works for me (in Stella).

[Cybearg]

Does my update binary work for you? (the game doesn't save until you press the firebutton to restart)

I tried the static demo (just re-downloaded it before I made my post above there) and I wasn't really sure what to do with it. Hitting the fire button doesn't seem to do anything. I get a number in the high and low part of the score, such as: 030003 but it doesn't bring the number back if I quit and restart Stella (Atarivox is hooked up to right port for the game and I restarted to make sure it was saved before trying the game again). I don't get garbled text, though, so I assumed the meant it worked.

[+Atarius Maximus]

Works for me (in Stella).

It's always worked for me using the 'stella -rc savekey game.bin' command line option. My original posted code and Mike's update both work fine (using Stella 3.8.1). I have no idea why I had difficulty earlier today when I selected the savekey in port 2 only in the GUI and it didn't work. I tend to stay away from GUI's as much as possible, my daily work has me working on Unix systems all the time and I'm very biased.. I like using a CLI.

[+Atarius Maximus]

I updated my original post with the demo with RevEng's updated version.

[+Philsan]

Now that AtariVox is back in AtariAge store this topic is useful!

[+Karl G]

This driver has worked out very well for me! Just a couple of notes in case they are useful to anyone else:

 

• If you use pfheights, be sure to set your heights before attempting any AtariVOX operations.
• If you are calling this from the Titlescreen Kernel, you will want to do a "gosub titledrawscreen" between each byte read or written instead of a "drawscreen".

[+Karl G]

A couple of notes for bankswitched projects:

 

• The AVoxReadByte and AVoxWriteByte functions must be called from the same bank the driver is loaded.
• If you are using the "inline" statement, the driver needs to be renamed to a name without hyphens.