Adding SRAM to USB dev cart

[cafe-alpha]

Hello and happy new year

I am currently trying to add and use 128KB SRAM chip to a modified USB dev cart.

(The reason to add SRAM is to use it in order to store temporary data for another module on the cartridge, not described here.)

I use a Cypress 128KB, 16 bits SRAM chip.

You can find the cartridge schematics here.

As suggested in the schematics, the SRAM chip is mapped to A-bus CS0 space, from offset 700000h.

I can nearly use the SRAM data, but got problem when writing char (1 byte sized) data to the chip, as described in the test results below.

Notes:

- All data are in hexadecimal representation and start address used for testing is 02700000 (= top of SRAM data).

- I had similar test results for 2 Saturn units (modchipped white Saturn and gray Saturn, both japanese model), so the problem should not be due to a defective Saturn unit.

Test #1 : long data write.

Write of 01234567 89abcdef to SRAM

Before : 5A49C04A 125601E5

After : 01234567 89ABCDEF (no problem)

Test #2 : char/word/long bytes data read

// (*(volatile unsigned char *)(0x02700000)) = 0x01;

// (*(volatile unsigned short *)(0x02700000)) = 0x0123;

// (*(volatile unsigned long *)(0x02700000)) = 0x01234567;

-> no problem

Test #3 : short data write.

Write of 9876 5432 10fe dcba to SRAM

Before : 0123 4567 89AB CDEF

After : 9876 5432 10FE DCBA (no problem)

Test #4 : char data write.

Write of 78 9a bc de f0 12 34 56 to SRAM

Before : 98 76 54 32 10 FE DC BA

After : FF 9A FF DE 12 12 FF 56 (problem on even address)

It seems that writing data to even address doesn't modify anything, and that writing data to odd address sets previous byte to FF or same value as data at odd address.

It think the culprit is SCU, who is messing up when writing 8 bit data to 16 bit bus, but I can't find details about this problem, and ... don't know what should I do in order to fix it.

Does anyone got an idea of the origin of the problem, and any hardware countermeasure to it ? (It is OK to modify the schematics, SRAM chip type, etc.)

 

[Chilly Willy]

The "problem" is obvious - you tie /BLE and /BHE to ground, so it ALWAYS writes a word, even for byte writes. I would guess that AWR0 is one write strobe, and AWR1 is the other. You're only using AWR0, so you only get one byte valid and overwrite the other byte when you do so as you write a word at a time as mentioned.

 

[cafe-alpha]

The "problem" is obvious - you tie /BLE and /BHE to ground, so it ALWAYS writes a word, even for byte writes. I would guess that AWR0 is one write strobe, and AWR1 is the other. You're only using AWR0, so you only get one byte valid and overwrite the other byte when you do so as you write a word at a time as mentioned.

Thank you Chilly Willy !

It wasn't that obvious for me, but thanks to you, I now understand a little more how to write byte on SRAM.

Until I read your post, I though that as data bus is 16bits wide, I just needed to tie data lines together and don't care about anything when data was shorter than bus width .....

A fixed -but untested- schematics should be something like this.

I will let you know if it works or not with a modified PCB, but I may not be able to test before until one month or two.

 

[cafe-alpha]

(Bump) I finally had enough time to get it working 🙂
Here is the vhdl code to get this SRAM chip working.

sram_oe  <= rd;
sram_we  <= wr0 and wr1;
sram_bhe <= rd and wr1;
sram_ble <= rd and wr0;

Because of SRAM high price and limited memory size (USD 5 / 128KB), I personally have no plan to fix/build/etc such a cartridge.
However, please let me know if you are interested in such a cartridge :
- 1MB flash area for cartridge boot
- USB module (same way of working as USB dev cart)
- 128KB SRAM
- USB dev cart price (USD 42) + USD 5 for SRAM chip.