Driver for 24AAXXX EEPPROM mounted on karri's carts

[+karri]

32 minutes ago, Nop90 said:

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 9.31 kB · 1 download

BYTE WRITE OK

BYTE R/W DONE

DATA CHECK PASSED

VALUE 128

 

SECTOR R/W DONE

DATA CHECK FAILED

BLOCK READ CHECK OK

 

[Nop90]

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.

 

 

[+karri]

Sounds great! I have already started on my holodeck-code and will be running eeprom stuff from the start.

[+karri]

Perhaps it needs a few idle clock cycles between operations?

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

 

[Nop90]

I propose these changes:

 

unsigned char __fastcall__ lynx_eeread_24aa512(unsigned char *val, unsigned int addr);
unsigned char __fastcall__ lynx_eereadnext_24aa512 (unsigned char *val, );

this way all the functions return the same error code (0 = OK, 1 = KO). After a write it's possible to use a while loop for the next EEPROM access (read or write) to wait the EEPPROM ACK:

 

while(lynx_eeread_24aa512 (&content,0));

This is exactly the process proposed in the datasheet.

 

The only thing to remind is that whitout a 24AA eeprom this while loop is blocking, so it should not be used with the first read to the eeprom.

 

The updated driver code is:

eeprom64k.s

 

and the new test rom (with sources) using these while loop instead of the delay:

 

E2test.lnx  E2test.zip

 

@karri if you like the last changes we can consider the driver interface final.

 

Note: my emulator eeprom code doesn't have any writing delay after a write, so writing to the eeprom and then reading from it without a delay can be used to detect the emulator (with a real EEPROM the read will fail). It's a trivial thing to fix in the emulator code, but I bet no one will ever do it ?

 

 

 

[+karri]

8 hours ago, Nop90 said:

I propose these changes:

 

unsigned char __fastcall__ lynx_eeread_24aa512(unsigned char *val, unsigned int addr);
unsigned char __fastcall__ lynx_eereadnext_24aa512 (unsigned char *val, );

this way all the functions return the same error code (0 = OK, 1 = KO). After a write it's possible to use a while loop for the next EEPROM access (read or write) to wait the EEPPROM ACK:

 

while(lynx_eeread_24aa512 (&content,0));

This is exactly the process proposed in the datasheet.

 

The only thing to remind is that whitout a 24AA eeprom this while loop is blocking, so it should not be used with the first read to the eeprom.

 

The updated driver code is:

eeprom64k.s 9.8 kB · 1 download

 

and the new test rom (with sources) using these while loop instead of the delay:

 

E2test.lnx 9.37 kB · 1 download   E2test.zip 31.57 kB · 1 download

 

@karri if you like the last changes we can consider the driver interface final.

 

Note: my emulator eeprom code doesn't have any writing delay after a write, so writing to the eeprom and then reading from it without a delay can be used to detect the emulator (with a real EEPROM the read will fail). It's a trivial thing to fix in the emulator code, but I bet no one will ever do it ?

 

 

 

Wonderful! Thanks!

[Nop90]

This EEPROM has a I2C interface, and with "almost" the same code we can control every device with a I2C communication protocol. Up to 8 can cohesist setting different addresses on the same bus (this eeprom uses address 0).

 

I had some crazy ideas:

  - hardmod the lynx with a capacitive 4.5 inch touchscreen

  - add a keyboard like this . Could be connected to a special cart with a back connector, and on the cart a Basic interpreter that can store programs on the 64kB eeprom

  - add an accelerometer chip like this (can be on the cart) to make a game controlled moving the lynx 

 

 

[Fadest]

8 hours ago, Nop90 said:

 - add an accelerometer chip like this (can be on the cart) to make a game controlled moving the lynx 

This is probable what  @vince did with his Ouragan cartridge prototype, a 3D Tempest clone played via an accelerometer on cartridge. 

@vince, how did you interface it ?

[Nop90]

On 5/2/2012 at 8:13 AM, vince said:

The accelerometer is on the cartridge, in order to access it the communication is made with SPI protocol. This protocol is also used for the eeprom access.

Found a 2012 post about it: different protocol but same idea

 

 

[+karri]

The cart I sent you also has some extra pins on the back side for connecting to strange stuff. Like my prototype to blink a 3-colour LED in blue/white in "Shaken, not stirred" while you are driving. And flash red when are shot. The silly idea was to use the LED for ambient lighting to get a better gaming experience.

[Nop90]

I read on @Igor twitter page that he is using a cart with a 3 wires 1KB eeprom chip instead of the usual 128B one. Does it use the same driver of the 128B eeprom or a modified one?

[Igor]

The driver is different, but the driver is in CC65 already

[+karri]

sage wrote a whole bunch of drivers for 93cXX eeproms. But they are only up to 2k if I remember correctly.

[42bs]

Any reason for using A1 instead of A0 for the CLK?

[42bs]

Again, "cylce counting"
 

   iny
    cpy    #128
    bne    pagewriteloop

=>

   iny
   bpl    pagewriteloop

 

[42bs]

Ok, put my hands on the cc65 code but cannot test it since I have no working setup. I hope I just improved it and did not build in bugs.

Note: Logic of last-byte-flag changed from != 0 to == 0 !!

eeprom64k.s

[+karri]

35 minutes ago, 42bs said:

Any reason for using A1 instead of A0 for the CLK?

The only reason was that the 93c46 eeprom used A1. So I just used the same.

[42bs]

8 minutes ago, karri said:

The only reason was that the 93c46 eeprom used A1. So I just used the same.

? like the old A20 gate. And I used A1 because for an unknown reason A0 did not work.

[Nop90]

2 hours ago, 42bs said:

Ok, put my hands on the cc65 code but cannot test it since I have no working setup. I hope I just improved it and did not build in bugs.

Note: Logic of last-byte-flag changed from != 0 to == 0 !!

eeprom64k.s 9.47 kB · 3 downloads

Thank you for the improvements. I didn't spend time optiizing the code an Iìm a novice with 6502 ASM. Later I'll test it with handy.

 

The driver can run faster with protocol improvements, i.e. theoretically there is no need to set the IODIR byte for output and the AUDIN value to 1 because leaving IODIR as input the line should go to 1 for the pull-up resistor. Using this extensively we can save a lot of instructions. But I want to have a real eeprom to test it, @karri already spent a lot of time testing my bugs.

[42bs]

I first had to add a BLL loader to the card. I will now try to write a BLL driver based on your work and see if it can be further optimized. And sure will try A0 instead of A1 later.
The question will be later: Speed or size.

[+karri]

32 minutes ago, 42bs said:

I first had to add a BLL loader to the card. I will now try to write a BLL driver based on your work and see if it can be further optimized. And sure will try A0 instead of A1 later.
The question will be later: Speed or size.

It may be a good idea to try out the A0 for clock on the 64k eeprom and modify the pcb.

[42bs]

3 minutes ago, karri said:

It may be a good idea to try out the A0 for clock on the 64k eeprom and modify the pcb.

I have some spare PCBs from T-Tris and five 24aaxxx, so after I got the routine work with your card, I will give it a try.

[42bs]

Added driver and test program to new_bll. And here (again) an improved version for cc65.
https://github.com/42Bastian/new_bll/blob/master/includes/24aaxxx.inc
https://github.com/42Bastian/new_bll/blob/master/demos/check_24aaxxx.asm
 

I chose ee24aaxxx_ prefix for common functions and ee24aa512_ for those only for the 128 page version.

 

 

eeprom64k.s

Edited December 30, 2020 by 42bs

[42bs]

On 12/29/2020 at 5:57 PM, 42bs said:

I have some spare PCBs from T-Tris and five 24aaxxx, so after I got the routine work with your card, I will give it a try.

Ok, just checked that using A0 for clock works.

 

Reading page wise all 64K takes ~6.2s with A0 clock and 7.8s with A1 clock.

Edited December 30, 2020 by 42bs