Thomas Jentzsch Posted September 26, 2019 Author Share Posted September 26, 2019 You can delay the calls, no problem. 1 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted September 29, 2019 Share Posted September 29, 2019 One more dumb question: what is the limit to the number of bytes that may be sent via i2c_txbyte before the write needs to be committed with i2c_stopwrite? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 29, 2019 Author Share Posted September 29, 2019 64 bytes. Here is some doc. For more details, lookup the doc for the 24LC256 chip. E.g. after I2C_stopwrite you have to wait some time, so that the chip can commit the new data. 1 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted September 29, 2019 Share Posted September 29, 2019 Thanks! You mentioned the write time in the comments for your API. I figure I can initiate the write right before the visible screen. Quote Link to comment Share on other sites More sharing options...
Dionoid Posted April 7, 2020 Share Posted April 7, 2020 (edited) I noticed that reading the SaveKey right after startup sometimes fails for me (in about 1 out of 10 cases). Maybe it is a problem of my SaveKey, I'm not sure. Anyway, by waiting a few milliseconds after startup (~80 scan lines), these problems went away. Edited September 18 by Dionoid Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 12, 2020 Author Share Posted April 12, 2020 Never noticed this problem. Also, the TIA/RAM initialization loop already last quite a lot of scanlines (~30). But it could well be a general problem. It may take a while until everything works fine. And the hardware is quite old now. Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 20, 2021 Share Posted February 20, 2021 On 3/6/2016 at 9:25 AM, Thomas Jentzsch said: Hi, I found no easy to use code for loading and storing on a SaveKey or AtariVox. Therefore I am presenting my code here. All it takes are: add the attached include file to your code's directory define the three variables/constants at the beginning of the code call WriteSaveKey for storing your score etc. call ReadSaveKey for reading what you have stored Notes: if you have multiple scores to store (e.g. different game modes), you have to modify the address used in SetupSaveKey. the X register is not used in any i2c subroutine. after calling WriteSaveKey you must wait at least 5ms (~80 scan lines) before accessing the SaveKey again. update i2c v2.3 attached, fixes unwanted noise issues when using an AtariVox skBuffer = <score RAM> ; define the RAM address you want to store SK_BYTES = <n> ; define how many bytes your want to store SAVEKEY_ADR = $xxxx ; ask Albert for a free slot! include "i2c_v2.3.inc" ; a highly optimized (for space) version i2c_subs ; this makes the i2c macros of the include file known to the code ;------------------------------------------------------------------------------- WriteSaveKey SUBROUTINE ; total cycles = 1923 (for 3 bytes) ;------------------------------------------------------------------------------- ; setup SaveKey: jsr SetupSaveKey ; 6+927 bcc .noSKfound ; 2/3 ; write high score: ldx #SK_BYTES-1 ; 2 = 937 .loopWriteSK lda skBuffer,x ; 4 jsr i2c_txbyte ;6+296 transmit to EEPROM dex ; 2 bpl .loopWriteSK ; 2/3=932 ; stop write: jsr i2c_stopwrite ; 6+42=48 terminate write and commit to memory .noSKfound rts ; 6 ;------------------------------------------------------------------------------- ReadSaveKey SUBROUTINE ; total cycles = 2440 (for 3 bytes) ;------------------------------------------------------------------------------- ; setup SaveKey: jsr SetupSaveKey ;6+927 bcc .noSKfound ; 2/3 ; start read: jsr i2c_stopwrite ;6+42 end of "fake" write jsr i2c_startread ;6+284 Start signal and $a1 command byte ; read high score: ldx #SK_BYTES-1 ; 2 = 1275 .loopReadSK jsr i2c_rxbyte ;6+333 read byte from EEPROM cmp #$ff ; 2 EEPROM slot empty? (we are assuming $ff for uninitialized space) bne .skipEmptySK ; 2/3 no, skip clear lda #0 ; 2 clear EEPROM slot .skipEmptySK sta skBuffer,x ; 4 dex ; 2 bpl .loopReadSK ; 2/3=1061 ; stop read: jsr i2c_stopread ;6+92=98 terminate read .noSKfound rts ; 6 ;------------------------------------------------------------------------------ SetupSaveKey SUBROUTINE ; = 927 ;------------------------------------------------------------------------------ ; detect SaveKey: jsr i2c_startwrite ;6+312 bne .exitSK ; 2/3 ; setup address: clv ; 2 lda #>SAVEKEY_ADR ; 2 upper byte of address jsr i2c_txbyte ;6+296 lda #<SAVEKEY_ADR ; 2 lower byte offset jmp i2c_txbyte ;3+296 returns C==1 .exitSK clc rts ; 176 bytes in total (less if you inline the subroutines) I hope this answers all questions. Else let me know. SaveKey & AtariVox memory allocation list i2c_v2.2.inc 5.18 kB · 253 downloads i2c_v2.3.inc 5.35 kB · 247 downloads Hello, do you have example program using this in bB please? How do I actually call the methods? Do I do something like WriteSaveKey $3001 = s? S being the variable? Thank you Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 20, 2021 Author Share Posted February 20, 2021 I don't do bB, sorry. But maybe someone else can help? Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 20, 2021 Share Posted February 20, 2021 6 minutes ago, Thomas Jentzsch said: I don't do bB, sorry. But maybe someone else can help? Thank you, I have bB solution working on stella, just not on hardware, its driving me crazy and ive spent the day on it. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 20, 2021 Author Share Posted February 20, 2021 Stella's emulations is not 100% perfect. Are you maybe writing too much too fast (s. comments above)? 1 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 20, 2021 Share Posted February 20, 2021 I'm doing a drawscreen between each byte, that should be enough time? Or do you think I need to slow down even more? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 20, 2021 Author Share Posted February 20, 2021 That's much longer than 5ms (or 80 scanlines), right? Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 20, 2021 Share Posted February 20, 2021 Yes, I believe so. Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 21, 2021 Share Posted February 21, 2021 Does anyone have an example of exactly how I would, for example... save the bB variable S into position $3001 using this method after including the ASM? Thank you. Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 21, 2021 Share Posted February 21, 2021 17 hours ago, EvoMikeUK said: Hello, do you have example program using this in bB please? There's always this, which isn't TJ's code, but does have an example of how to write to the avox/savekey eeprom from bB. Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 21, 2021 Share Posted February 21, 2021 57 minutes ago, RevEng said: There's always this, which isn't TJ's code, but does have an example of how to write to the avox/savekey eeprom from bB. Yes, this isnt working either, but does on Stella, just like my program, so I think I may have a hardware issue. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 21, 2021 Author Share Posted February 21, 2021 Have you tried some games which support the SaveKey? Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 21, 2021 Share Posted February 21, 2021 Ok update... @Karl G has helped me and we have troubleshooted the problem. My PAL 6-Switcher saves the High-Score in SpaceGame but my NTSC Dev Unit does not, seems it was a hardware issue all along. Thank you for everyone who took the time to hep me out! Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 22, 2021 Share Posted February 22, 2021 Ok, it was dry joints on the controller port! Sorry to bother you all, feel a bit embarrassed now lol 1 Quote Link to comment Share on other sites More sharing options...
+Propane13 Posted September 18 Share Posted September 18 Hello! I know this is an Atari 2600-specific thread, but I wanted to bring something up that's 7800-specific which may also benefit this same code base and Thread. Apparently, there is an Atari 7800 specific version of these SaveKey include files. Here's a post that mentions it: https://forums.atariage.com/topic/200199-get-lost/?do=findComment&comment=5532709 Would it be worth it to try to incorporate these changes into the 2600 one from this Thread? That would make this "SaveKey for Dummies" more portable. I'm not suggesting auto-detect code or anything as that will eat up more ROM and cycles (unless it was deemed worth it), but maybe there could be an "IF 7800" flag to differentiate. This would also ensure that any bugfixes from one fork would be carried to the other line. I'm unsure what the difficulty would be, though. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 18 Author Share Posted September 18 That might work. But I suppose @RevEng would have to be incorporated, because he know his changes (I think I could find out) and I suppose he is able to test results. From looking at the code, he only added some NOPs (and some debug color output) to the original I2C. Probably that would work here too, but my I2C code is optimized, so one has to be careful with the changes. Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 18 Share Posted September 18 I don't personally want to take on the support for it, but If someone wants to unify both consoles in one i2c driver, go for it. Absolutely the 7800 version just adds a few nops to enhance reliability at 7800 clock speeds. The bigger deal about unifying it is testing out any changes on both consoles, or at least advising that any given update in the unified driver hasn't been tested on one of the consoles. 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 18 Author Share Posted September 18 (edited) We would have to share the work. 7800 for you and 2600 for me. The question ist, what would be the benefit? Both codes are tested and working unchanged for long time. And I don't expect any changes to come. Edited September 18 by Thomas Jentzsch 1 1 Quote Link to comment Share on other sites More sharing options...
+Propane13 Posted September 18 Share Posted September 18 Well, I had 3 reasons to bring up the idea: 1) I can't get the 7800 version to compile on dasm. I get weird errors like this: ... char = '{' 123 (-1: 0) char = '}' 125 (-1: 49) src/main.asm (381): error: Not enough args passed to Macro. src/main.asm (381): error: Illegal character '{1}'. ... I'm using version 2.20.14.1, which I believe is still the latest according to the github link I was using. All I'm really doing is swapping my "include file": The following fails for me: include "hdr/savekey/i2c7800.inc" But the following works. include "hdr/savekey/i2c_v2.3.inc" I'm invoking `i2c_subs` further in the file, and that's what I believe causes the failure to compile. 2) I noticed that the Atari 2600 version was last fixed on November 2, 2016, but the 7800 version is listed as being last updated in 2015. So, that implies that the 7800 code probably still is missing the 2016 fix (I'm not sure). The other alternative was to suggest porting the 7800 support to the 2600 version, so that there could be one source of truth. 3) This Thread is one of the top results on atariage when searching for savekey integration assistance. Atari 7800 developers who end up here may not realize that while the implementation in this Thread will compile fine for their 7800 efforts, it may have reliability issues due to timing differences. It's not 1:1. It seemed like it was worth at least bringing up the idea to see if cross-pollination made any sense. From my side of things, my goal is a bit simpler; I just want to figure out how to compile SaveKey code with the appropriate 7800 timing for a project I'm working on, but it would also be nice to have the latest fixes from both projects included if there are any. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 18 Author Share Posted September 18 (edited) 14 minutes ago, Propane13 said: 1) I can't get the 7800 version to compile on dasm. ... I suppose that's a carriage return/linefeed issue. Format the file according to your OS. 14 minutes ago, Propane13 said: 2) I noticed that the Atari 2600 version was last fixed on November 2, 2016, but the 7800 version is listed as being last updated in 2015. So, that implies that the 7800 code probably still is missing the 2016 fix (I'm not sure). The other alternative was to suggest porting the 7800 support to the 2600 version, so that there could be one source of truth. The fix was required due to my optimizing. Probably the 7800 code does not need it. 14 minutes ago, Propane13 said: 3) This Thread is one of the top resuls on atariage when searching for savekey integration assistance. Atari 7800 developers who end up here may not realize that while the implementation in this Thread will compile fine for their 7800 efforts, it may have reliability issues due to timing differences. It's not 1:1. Well, now we have a link in here. And I can add a comment to my 1st post and put the link there too. Edited September 18 by Thomas Jentzsch 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.