Nop90 Posted December 17, 2020 Author Share Posted December 17, 2020 It's something, it gets the ACK after setting the address and gets the ACK after writing (there is no ACK after reading). We are very close to have it working. Please check with the programmer the value written in the first position of the EEPROM: if it's 128 the writing is ok and there is a bug in the reading part. If it's 16, there is a bug in the writing part but the reading is ok. If another value... it means I'm really bad ad coding in ASM. Quote Link to comment Share on other sites More sharing options...
42bs Posted December 17, 2020 Share Posted December 17, 2020 (edited) 1 hour ago, Nop90 said: I was ready to test my fixed code but the flash chip of my modded cart stopped working, and made a really bad work trying to make a new one. So for the moment I'm stuck. @karri ifyou want to test my last build here are the rom and the sources. E2test.lnx 7.9 kB · 2 downloads E2test.zip 10.2 kB · 3 downloads I can't see where y is cleared for the loop. lda #0 sectwriteloop: phy lda (ptr1),y jsr E2_put8 beq sectorWrite_error2 ply iny cpy #0 ;needed? bne sectwriteloop I guess "lda #0" should be "ldy #0", right? And yes, "cpy #0" is not needed. Edited December 17, 2020 by 42bs Quote Link to comment Share on other sites More sharing options...
42bs Posted December 17, 2020 Share Posted December 17, 2020 bne sectwriteloop lda #0 ;return value 0 = OK tax rts => bne sectwriteloop tya ;return value 0 = OK tax rts small improvement Quote Link to comment Share on other sites More sharing options...
42bs Posted December 17, 2020 Share Posted December 17, 2020 (edited) Here my slightly tuned version. sector write does not have a E2_STOP. Not needed? lynx24AAXXX.s Edited December 17, 2020 by 42bs Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 1 hour ago, Nop90 said: It's something, it gets the ACK after setting the address and gets the ACK after writing (there is no ACK after reading). We are very close to have it working. Please check with the programmer the value written in the first position of the EEPROM: if it's 128 the writing is ok and there is a bug in the reading part. If it's 16, there is a bug in the writing part but the reading is ok. If another value... it means I'm really bad ad coding in ASM. I really don't know exactly what is going on... I ran these 42BS changes and the result was the same. 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Perhaps it makes sense to first code the HAT version to reliably read and write the bytes. At least I know that the hardware works after that. Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 17, 2020 Author Share Posted December 17, 2020 @42bs beter fix the single byte read/write first. Meanwhile manage to fix my cart, it works fine without the eeprom, with the eeprom strange things happens to the flash (sometimes works, others not). I'm worried they sold me the wrong component. This is the best pic I could take of the chip Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 5 minutes ago, Nop90 said: @42bs beter fix the single byte read/write first. Meanwhile manage to fix my cart, it works fine without the eeprom, with the eeprom strange things happens to the flash (sometimes works, others not). I'm worried they sold me the wrong component. This is the best pic I could take of the chip Lol. I may have something wrong in my code. I wrote a routine to write the eeprom but reading produce the wron result... Quote Link to comment Share on other sites More sharing options...
42bs Posted December 17, 2020 Share Posted December 17, 2020 Which version are you using? The page size must be checked. As I see the 24AA512 has a page of 128, so writing 256 bytes will only program the last 128 bytes. Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 My programming routine does not change anything. Reading seems to work. (On the HAT programmer) Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 There is something seriously wrong with the design/code. I tried to write "Hello World!" pi@retropie:~/lynx/contrib/blankcart/programmer $ ./writeeeprom64k Write 128 bytes from eeprom.datr to eeprom 48 6c 6c 6f 57 72 6c 64 fe fe ff ff ff fe ff ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff pi@retropie:~/lynx/contrib/blankcart/programmer $ ./readeeprom64k Read 64k eeprom to eeprom.dat 48 ff 30 6d ff ff 56 ff fe 6d ff ff fe ff fe ff ff ff fe ff fe ff ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 17, 2020 Author Share Posted December 17, 2020 8 minutes ago, 42bs said: As I see the 24AA512 has a page of 128, so writing 256 bytes will only program the last 128 bytes correct, only 128 bytes, writing more will make the internal counter go to o and overwrite the previous values stored in the buffer. I'll fix this, bu the priority is the single byte read write. Better remove the block functions from the test program for the moment to avoid confusion. Quote Link to comment Share on other sites More sharing options...
42bs Posted December 17, 2020 Share Posted December 17, 2020 2 minutes ago, karri said: There is something seriously wrong with the design/code. I tried to write "Hello World!" pi@retropie:~/lynx/contrib/blankcart/programmer $ ./writeeeprom64k Write 128 bytes from eeprom.datr to eeprom 48 6c 6c 6f 57 72 6c 64 fe fe ff ff ff fe ff ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff pi@retropie:~/lynx/contrib/blankcart/programmer $ ./readeeprom64k Read 64k eeprom to eeprom.dat 48 ff 30 6d ff ff 56 ff fe 6d ff ff fe ff fe ff ff ff fe ff fe ff ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff I'd add a "sleep" after every byte to be sure the chip has finished writing. Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 The reading appears to give back the same result every time which id good Read 64k eeprom to eeprom.dat 48 ff 30 6d ff 21 56 6f fe 6d ff 21 fe 21 fe 21 ff 21 fe 21 fe 21 ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff pi@retropie:~/lynx/contrib/blankcart/programmer $ mv eeprom.dat oldeeprpm.dat pi@retropie:~/lynx/contrib/blankcart/programmer $ ./readeeprom64k Read 64k eeprom to eeprom.dat 48 ff 30 6d ff 21 56 6f fe 6d ff 21 fe 21 fe 21 ff 21 fe 21 fe 21 ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff pi@retropie:~/lynx/contrib/blankcart/programmer $ Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 17, 2020 Author Share Posted December 17, 2020 22 minutes ago, Nop90 said: I'm worried they sold me the wrong component. Found the 1437 number on the 25AA512 chip. Seems they sent me the SPI version of the chip instead of the I2C. Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 The problem is with the ACK signal received after the write operation. Something strange going on... Write 128 bytes from eeprom.datr to eeprom 48 Error30 6d ff Error56 Errorfe 6d ff Errorfe Errorfe 21 ff 21 fe 21 fe 21 ff ff ff Errorfe ff ff Errorff ff ff Errorff ff ff Errorff ff ff Errorff ff ff Errorff Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 17, 2020 Author Share Posted December 17, 2020 4 minutes ago, 42bs said: I'd add a "sleep" after every byte to be sure the chip has finished writing. If it is still writing it doesn't give the ack. The data sheet says that after a write you have to retry the Start sequence till it gives the ACK Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 17, 2020 Author Share Posted December 17, 2020 2 hours ago, 42bs said: sector write does not have a E2_STOP. Not needed? Yes it's needed or the write won't start Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 The problem I have is that there is no way for me to read the 3rd ACK as zero. It is always a one. So after sending the address Low Byte I cannot send the data because the ACK is one even after a long wait. Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 YES! I got it to work by forcing an extra stop sequence before the write sequence. Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 Well... Almost working... pi@retropie:~/lynx/contrib/blankcart/programmer $ ./writeeeprom64k Write 128 bytes from eeprom.datr to eeprom 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 20 20 20 20 20 20 20 20 pi@retropie:~/lynx/contrib/blankcart/programmer $ pi@retropie:~/lynx/contrib/blankcart/programmer $ ./readeeprom64k Read 64k eeprom to eeprom.dat 48 65 6c 6d 6e 21 56 6f 72 6d 64 21 20 21 20 21 20 21 20 21 Some really strange bit errors here and there... Quote Link to comment Share on other sites More sharing options...
42bs Posted December 17, 2020 Share Posted December 17, 2020 Looks like the last clock is somehow missing. That might be the reason you get no ACK. Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 4 minutes ago, 42bs said: Looks like the last clock is somehow missing. That might be the reason you get no ACK. No. For the last bit I outputted the last bit of the address instead of the last bit of the data. Just a typo. Write 128 bytes from eeprom.datr to eeprom 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 20 20 20 20 20 20 20 20 ead 64k eeprom to eeprom.dat 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 20 20 20 20 20 20 20 20 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 I just pushed my HAT code to the repo lynx/contrib/blankcart/programmer/src/writeeeprom64k.c Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 So now I wrote the eeprom with some content, read it, put the cart in the Lynx to run the test it and read it again. i@retropie:~/lynx/contrib/blankcart/programmer $ ./writeeeprom64k Write 128 bytes from eeprom.datr to eeprom 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 20 20 20 20 20 20 20 20 pi@retropie:~/lynx/contrib/blankcart/programmer $ pi@retropie:~/lynx/contrib/blankcart/programmer $ ./readeeprom64k Read 64k eeprom to eeprom.dat 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 20 20 20 20 20 20 20 20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff pi@retropie:~/lynx/contrib/blankcart/programmer $ ./readeeprom64k Read 64k eeprom to eeprom.dat 00 65 6c 6c 6f 20 57 6f 72 6c 64 21 20 20 20 20 20 20 20 20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff pi@retropie:~/lynx/contrib/blankcart/programmer $ Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 I did compile a new lnx file that just reads one byte. When the data on the cart is letter H (0x48) the Lynx reports it as 145. A (0x41) is reported as 131. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.