Driver for 24AAXXX EEPPROM mounted on karri's carts

[Nop90]

This morning wrote a first (and incomplete) version of a driver to read and write values on a 24AAXXX EEPPROM on @karri 's carts. The XXX in the chip name can be indifferently 16,32,64,128, 256 or 512 and indicates the numbers of Kbit available in EEPROM.

 

I can't test the driver because I don't have a cart with this EEPROM chip ready to use and emulators (or the existing SD carts) yet don't support this kind of EEPROM emulation AFAIK.

 

Since I'm not so skilled at ASM coding, and it's the first time i use macros with ASM, probably it's buggy, so for the moment I'm asking to the other devs to check the code for big errors (at least it compiles).

 

I only wrote the functions to write and read a single byte. I have to add the functions to read and write all the 256 values of a sector, and another function to read in a buffers any desired number of consequet bytes up to the entire EEPROM size. Adding them is easy, but it's better to check if the communication protocol works fine first.

 

Any feedback or help to improve the code is welcome. The help of @karri for testing on a real cart would be greatly apreciated.

 

lynx24AAXXX.s

[+karri]

It took me a while to find them. The chips are a bit small. It turned out that I have a whole tube of 2AA512SN chips. So these should be 64k. I am now preparing for some cart surgery to remove a 93C46 chip and install a brand new 2AA512SN next to the 93C46 footprint. Finers crossed that it works...

 

ARRRGHH... My bad. I bought these for the large cart with the PLCC chip. Well I have these carts also somewhere. The footprint is SOT-8 instead of TSOP-8 on these chips. Silly me.

 

But now it is soldered to the old blankcart design.

[+karri]

Ok. I compiled a small program that increments a counter. After 10 seconds it reads a byte from the cart. And the program hangs...

 

#include <lynx.h>
#include <joystick.h>
#include <tgi.h>
#include <6502.h>
#include <time.h>
#include <stdlib.h>
#include <string.h>

unsigned __fastcall__ lnx_24AAXXX_byteRead (unsigned char cell, unsigned char sector);
void __fastcall__ lnx_24AAXXX_byteWrite (unsigned char data, unsigned char cell, unsigned char sector);

void main(void) {
    unsigned char byte_read = 0;
    unsigned char data = 0;
    char content[32];
    tgi_install(&tgi_static_stddrv);
    tgi_init();
    joy_install(&joy_static_stddrv);
    CLI();
    memset(content, 0, sizeof(content));
    content[0] = 'A';

   content[1] = 0;

  while (1) {
    clock_t now;
    clock_t hours, minutes, seconds;
    char buf[32];
    while (tgi_busy())
      ;
    tgi_clear();
    tgi_setcolor(COLOR_GREEN);
    now = clock();
    hours = now / (3600 * 75);
    now -= hours * 3600 * 75;
    minutes = now / (60 * 75);
    now -= minutes * 60 * 75;
    seconds = now / 75;
    now -= seconds * 75;
    memset(buf, 0, sizeof(buf));
    ultoa(hours, strchr(buf, 0), 10);
    buf[strlen(buf)] = ':';
    ultoa(minutes, strchr(buf, 0), 10);
    buf[strlen(buf)] = ':';
    ultoa(seconds, strchr(buf, 0), 10);
    buf[strlen(buf)] = ':';
    ultoa(now, strchr(buf, 0), 10);
    tgi_outtextxy(0, 0, buf);
    if (seconds == 10) {
        if (byte_read == 0) {
            content[0] = lnx_24AAXXX_byteRead (0, 0);
            byte_read = 1;
        }
    }
    //tgi_outtextxy(0, 40, content);
    tgi_updatedisplay();
  }
}

In Mednafen the program stops at 0:0:9:74 but on the real Lynx the program stops at 0:0:9:74 and less than a second after that the screen goes blank. This does not happen on the emulator.

[Nop90]

Does mednafen has support for this eeprom? I wrote 75% of the code to add support for it to Handy.

 

Tommorrow I'll check again the driver code.

[+karri]

It does not have a problem with E2_START.

So it does get the ACK signal.

 

E2_setAddr crashes the Lynx.

 

If you just comment out the "beq" command in E2_START the Lynx will also stop functioning in Mednafen.

[Nop90]

Wow, if E2_START works it's a good news.

 

In E2_setAddr i made a terrible mistake. Now read andwrite work  in handy (i.e. don't crash) commenting the ACK check in E2_START.

 

I'm checking if there are other errors.

 

 

lynx24AAXXX.s

Edited November 17, 2020 by Nop90

[+karri]

Thank you for the fix. I will try this on the hardware tonight.

 

When this works it might be a good idea to get a batch of carts with both eeproms soldered on. There could be a simple solder bridge that activates the 128 byte eeprom by default and if you cut a trace and solder in a tiny blob you get the 64k eeprom. The cost increse is just about 1€. The difference in manufacturing 2 different boards vs one board is much more expensive.

 

A 64k eeprom could also be used in-game for saving scenery that gets destroyed. Like in Worms.

 

Plus handling inventory and item locations in a RPG game. I tried to do this in "MegaPak I" where I had the easter egg "Pirate Adventure by Scott Adams". I did get the permission from Scott to port it. If you play it you may see that I also added graphics to the game when you leave London. The inventory and object map took every byte of the 128 byte eeprom.

 

Perhaps you could even create some building games like Settlers, Minecraft.

 

Of course you would need to colour code the carts somehow. Perhaps ordinary carts could be black and the 64k carts white?

 

PS. @Nop90 Once we get this working I will send you a card with a 64k eeprom.

 

[Nop90]

A 64K eeprom opens a lot of possibilities.

 

About the two chip cart, I don't like the idea to cut traces. Maybe the two chips can be selected with a new design of the pbc and one more chip select line.

[+karri]

2 hours ago, Nop90 said:

A 64K eeprom opens a lot of possibilities.

 

About the two chip cart, I don't like the idea to cut traces. Maybe the two chips can be selected with a new design of the pbc and one more chip select line.

We could use a block select address line for choosing the chip. Thanks for the idea.

 

Edit:

I could add a small set-reset flip flop to the design.

Any read-operation from the flash ROM would set the flip-flop and select the 128 byte eeprom.

A write-operation to the flash would reset the flip-flop and select the 64k eeprom until then next read from the flash.

This should make the cart compatible with all the games (except Alpine Games style games that use two ROM banks).

 

Edit2:

So I only need a miniature chip with 2 NAND gates. Like 74LVC2G00 for €0.19

But you need to add a command to read from the second CART port $FCB3 before operating on the 64k eeprom.

 

Edit3:

I also realized that I need a separate 2 AND gates to keep AUDIN from reaching the wrong chip. But it should fit on the board.

 

I just figured out that the data does not stay in the chip forever  
"Data Retention > 200 years"
The flash chip is just
"Greater than 100 years Data Retention"

 

In reality storing the cart in a sauna without power for a long time may corrupt the content 10 times faster than keeping it cool.

 

[Nop90]

Fixed the sector read and write functions and modified your test code to perform a write->read test for the single byte and whole sector cases.

 

The code doesn't crash, but don't know if in the sector function I set the pointer address bytes in the correct order, so I'm really curious to see what happens on a real cart.

lynx24AAXXX.s E2test.zip

[+karri]

Unfortunately...

Edited November 17, 2020 by karri

[Nop90]

But better that previous time ?

 

Have to check if the test program is correct. If it is, I'll check if I correctly implementeded the protocol described in the data sheet.

 

If you have time please add at the test program an output with the value read in the the single byte test.

[+karri]

15 minutes ago, Nop90 said:

But better that previous time ?

 

Have to check if the test program is correct. If it is, I'll check if I correctly implementeded the protocol described in the data sheet.

 

If you have time please add at the test program an output with the value read in the the single byte test.

The value of "content" is 0

[+karri]

It does not matter what I write. The read value is always 0.

[Nop90]

EDIT: have to study better the ACK signal. There is something I don't understand

Edited November 17, 2020 by Nop90

[+karri]

Could it be that the sector needs an erase command and write can only turn '1' to '0'

 

[Nop90]

There is no erase command, data is stored in an internal bufffer of 256 bytes and after the ACK signal the buffer overwrtes the selected sector (if you write more data that the buffer size, the internal counter resets to the buffer start and you over write previously stored data). The ACK polling after the START command is needed to check if a previous write process completed.

 

The problem is I misunderstood the ACK signal level, from a signal diagram I thought it was pulled high on ACK, but it's pulled down. Now I'm correcting the code.

 

This is good because this way the START command doesn't block the code if there is no EEPROM(or it is run on an emulator wit no EEPROM emulation).

 

But there are other things to take in account: the data channel have to be released on the HI-LO clock transition to allow the eeprom to send the ACK, I can only release the channel (changing the IODIR value) and then change the clock. If changing the AUDIN dierction in IODIR doesen't mantain the AUDIN signal level to low to the end of the clock HIGH state, the START command is not recognized and the EEPROM will never work.

 

Since the EEPROM can work up to 400KHz, it's a long time from releasing the channel and changing the clock, so the data level can be probably undefined, so I hope that with a bit of luck it cold be read as LOW at 50% of times and the ACK sooner or later will be received.

 

The other option is to release the channel after the clock transition, but in this case there will be the Lynx pulling the signal low and the EEPROM pulling the signal  high ?

 

 

[+karri]

The EEPROM can not pull the signal high. It is Open Collector. It can only pull the signal low. There is a resistor R? 51 that is connected to +5V at the bottom of the schematics.

 

Edit:

I was thinking of adding a S-R flip flop that could gate the A1 clock to both chips. Then the AUDIN could go directly to the chips but only one chip at a time receives the clock.

 

The down side of this is that you can not read from the flash using OE* at the same time you read/write to the 64k EEPROM. This could affect streaming PCM audio using interrupts. But it is just a small inconvenience imho. So don't stream audio from the cart at the same time you are using the EEPROM. You can play music and stream audio from RAM though.

 

Reading or writing a byte using CE0* signal will choose 93C46 EEPROM.
Reading or writing a byte using CE1* signal will choose the 24AA512 EEPROM.

 

This means that all current games will select 93C46 as soon as the game boots.

 

PS. Once we get this to work I still have a few of these old-style carts left. So if you want to experiment with the 64k storage drop me a PM. It will take months before I plan to get a batch of the new design carts.

[Nop90]

I already ordered some ic to solder onthe carts I have, but it will take some time to arrive.

 

Meanwhile I'll complete the Handy patch to handle this eeprom.

 

I rewrote a big part of the driver code and I'm going to trace it's execution on handy dev in the week end. If it runs correctly I'll send you anoher test rom.  

[+karri]

Thanks.

 

After spending some time thinking about alternatives I am slowly starting to realize that the best option is to order a set of carts with either 93c46 or 22AA512. There is really not much sense in trying to do both on a single cart. You just end up having unnecessary problems. Besides it just takes a few minutes to remove one chip and insert a new one.

[Nop90]

@karri the attached rom is not completly tested, but if you have time please check if at least the ACK check works with the new code I wrote. It will not work on an emulator.

 

Thanks.

 

 

E2test.lnx

[Nop90]

It's better to test this version (traced and debugged the single byte R/W).

E2test.lnx

[+karri]

I will try to get some time to test it after work today.

[+karri]

I wonder if I have some errors on the board. The test shows "Press a key" and nothing happens after that...

[Nop90]

This means that the ACK fails. Don't know what to do at this point. For me the protocol is ok.

 

EDIT: attached the last sources if someone wants to check the code

 

E2test.zip

Edited November 20, 2020 by Nop90