Nop90

I could add a delay after the write commands, but why waste time that could be sed for other things? The delay should be added in the calling code if the program has nothing else to do meanwhile.

Ok, so we only need to add a delay. The error in the page read is because there isn't a delay after the page write. The last block read reads the same data of the previous call, so if it went ok, the data is there. I'll modify the driver to return the no ACK when reading, so the code can get it and retry. With this last change we should have what we need to start experimenting with the new eepprom. The driver code is not optimized (I made things easy to debug), I will optimize it to be a lot faster when I have the cart to test the new code. I also have to check if my eeprom emulator maintains internally the correct address after every funcion call, and to do this I have to compare the behaviour with a real eeprom.

Before changing the driver, better test if the problem is the delay. Added a delay of 1 second (an extremely looong time for such a device) betwen write and read. E2test.lnx

Strange, I dind't change the read part. Maybe it needs some delay after a write. The write function check for the ACK but doesn't return an error if it fails. Probably I should change this adding a return value set read byte in a buffer passed as argument.

Added lynx_eereadbytes_24aa512 (char * buf, unsigned int len, unsigned int addr), if you don't like the name you ca change it. Updated driver: eeprom64k.s This is a lynx rom to test if it works fine with a real EEPROM: E2test.lnx and the sources: E2test.zip

And here are the files to add the 64kB eeprom support to Handy eeprom.cppeeprom.h and the rom header file with the new values to activate the eeprom emulation (it's a proposal for the moment) lnxhdr.s

Remember that you can only use the read function for big chunks of data. Writing you have to deal with pages. But this can be handled.

pageread and pagewrite are now working (at least on Handy) eeprom64k.s pay attention that the parameter of these functions is a page number and not an address. The starting address is page<<7. This is because writing a page, if you cross the page boundaries the eeprom wraps to the beginning of the page instead of passing to the next page. Reading this doesn't happen, but better have a pageread function that works like pagewrite. Now I have to write a function that reads an arbitrary number of bytes starting from an arbitrary address.

My eeprom emulation for Handy is working (have only a problem saving the eeprom state to file, but this isn't related to the eeprom emulation, there must be a stupid bug somewhere). With this mod I could debug the driver and now the writebyte and readnextbyte functions work. eeprom64k.s The format of the driver functions is the one defined by @karri. In the next days I should be able to fix the page read and the page write functions. NOTE: the way parameters are passed to the asm functions is different from what described on the CC65 manual. Probably this is one of the differences from the latest version of CC65 and the one we are using (that maintained by Karri) When completly working I'll post the eeprom64K emulation file for Handy.

Already done ?

@karri while waiting the cart I'm writing an eeprom emulation class for Handy. Is this a problem with your project to release a phisical release of a game of yours using the 64KB EEprom?

Not exactly true. Writing 1 byte refreshes th whole 128 bytes page, but 1 Milion of erase/write cycles ensures a long life for the eeprom if not abused

More than 1 Million Erase/Write Cycles Data Retention > 200 year Is it enough?

If setting the address works, sngle byte write should work too. I added the byteReadNext(void) function in my code, but at this point better wait to have the cart to test the code before making other changes. EDIT: this is the byteReadNext() function ; ------------------------------------------------------------------------ ; unsigned char __fastcall__ _lnx_24AAXXX_byteReadNext (void); ; ------------------------------------------------------------------------ ; /* Read one byte */ ; _lnx_24AAXXX_byteReadNext: E2_INIT E2_START lda #1 ;only 1 byte to read, so not mantaining the transmission active jsr E2_get8 ldx #0 E2_STOP rts

The 64kB eeprom opens new game possibilities for the Lynx. Can't wait to see your game.

I changed the C function definitions as suggested. unsigned char __fastcall__ lnx_24AAXXX_byteRead (unsigned int addr); unsigned char __fastcall__ lnx_24AAXXX_byteWrite (unsigned char data, unsigned int addr); unsigned char __fastcall__ lnx_24AAXXX_pageRead (char * buf, unsigned int addr); unsigned char __fastcall__ lnx_24AAXXX_pageWrite (char * buf, unsigned int addr); Don't know if I'm setting in the correct order the bytes of the buffer for the pageWrite and pageRead functions. Tomorrow I'll check with Handybug. I'm sorry I can't help testing, I have to order new eeprom chips (meanwhile asked a refund for the wrong type I received) lynx24AAXXX.s

One problem in the code is that I use the "popa" subroutine to take the third byte parameter from the C stack, but it's in sreg zp pseudo register , not on the C stack. I'm going to fix it. But this affecst byte_Write, not byte_Read, so it doesn't help to find the cause of the wrong reads.

Yes, better pass the whole addr as unsigned int. from CC65 manual It seems correct to me how I handle the parameters. Passing the whole address as unsigned int, the code have to be changed to send to the EEPROM X first, than A.

the bug should be the bpl E2_G8loop because 0 value doesn't set the Z flag, so the code reads 9 values instead of 8. "bne E2_G8loop" should fix. EDIT: the write loop already uses bne lynx24AAXXX.s

Yes it's needed or the write won't start

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

Found the 1437 number on the 25AA512 chip. Seems they sent me the SPI version of the chip instead of the I2C.

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.

@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

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.