29 replies to this topic

[RevEng]

batari, on Tue Feb 8, 2011 5:50 PM, said:

cd-w, on Tue Feb 8, 2011 4:46 PM, said:

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!

Edited by RevEng, Tue Feb 8, 2011 6:07 PM.

[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]

stephena, on Wed Feb 9, 2011 9:38 AM, said:

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.

Edited by RevEng, Wed Feb 9, 2011 10:51 AM.

[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.

Edited by RevEng, Wed Feb 9, 2011 12:24 PM.