Jump to content
IGNORED

EEPROM library


Songbird

Recommended Posts

I'm looking for an assembly version of the EEPROM library for the 93c46 serial EEPROM chip. I found some really old code from @42bs called eeprom.m65 which supports basic read, write, and erase functions. Is this the best/simplest one to use? Any issues or caveats I should know about?

 

Edited by Songbird
Link to comment
Share on other sites

  • 2 weeks later...

Carl, there is something that I don't fully understand. You cannot call the eeprom routine as a first thing in startup. What I have done is to call it once the first frames have been displayed. It could be something related to the eeprom needing time to power up or something related to the signals during setup of registers that is different at startup.

Link to comment
Share on other sites

Carl, "patched handy 0.95" from sage's handy-fork repo emulates 93c46 eeprom. I can provide you a compiled version later today if you want. Also check the lynxdir topic I created yesterday, i posted a compiled version of latest lynxdir to create a rom that will enable eeprom support for Handy.

Edited by LordKraken
Link to comment
Share on other sites

Sure, please send the compiled version.

 

Karri, have you observed that issue even when the boot screen is displayed before game code is loaded? This is an old ROM using the Atari format, so the first ROM directory points to the boot screen, then the game code loads after 2-3 seconds. Should be plenty of power up time.

Link to comment
Share on other sites

Well, I think I have it working now... but strangely, on power up I have to do a dummy read of one word before trying to read any real data. If I do that first, then the rest of the reads seem to work correctly.

 

The sequence I was doing was this:

  • Read the first EEPROM word looking for a unique game ID pattern
    • If bytes don't match, write the game ID, set all saved data to default values
    • If bytes do match, read some saved data instead of defaults
  • Boot the game

The problem I was seeing is that the values in A and X after the first read were always $FF and $3F, respectively. If I immediately perform another read of the same word, then I get the proper values back and other reads work after first try. So it's just the very first EEPROM read that seems to have a problem. I tried moving this first read to various spots in the code, sometimes before the title menu is displayed, other times much later after several screens have been displayed. Even stranger, I see the same behavior in the new Handy 0.98 executable with EEPROM support.

 

Is this expected? Is there some kind of init command or "always do a dummy read first" sequence that gets the EEPROM into a good state? Otherwise I wonder if there is a bug / race condition in lynx_eeprom_read which causes it to misbehave only on the first read...

Link to comment
Share on other sites

I guess it is related to the IODAT/AUDIN setup.

 

BLL sets IODIR = $1a, IODAT = $0b. Maybe cc65 init code does it differently.

 

Try writing $b to $FD8B and before the first read.

Edited by 42bs
  • Like 1
Link to comment
Share on other sites

I had the same behavior in my game version of Karri's template (that supports both EEPROM and SD saves) after there was the update to the SD code with the request of always call the SD init code.

 

As @42bs pointed out it's related to the state of IODIR and IODAT because both the EEPROM and SD code use (and init) them.

Link to comment
Share on other sites

The problem seems to be in by bootloader.

;                  ; 4. set AUDIN to output
; A9 1A            lda #$1a        ; audin = out, rest = out,
;                                  ; noexp = in, cart addr = out, ext pwd = in
; 8D 8A FD         sta IODIR
;
;                  ; 5. set AUDIN to LOW
; A9 08            lda #$08        ; Set AUDIN low
;                                  ; Set cart addr low for pwr to cart rom
; 85 1A            sta $1a         ; Save local copy to ZP
; 8D 8B FD         sta IODAT


FD8B = lODAT.Mikey Parallel Data(sort of a R/W)
8 bits of general purpose I/O data

B7 = NC
B6 = NC
B5 = NC
B4 = audin input
B3 = rest output
B2 = noexp input
B1 = Cart Address Data output (0 turns cart power on)
B0 = External Power input

(note, R0M sets it to output, you must set it to input)

 

The LSB B0 should not matter. It is an input. Why should B1 be set to turn the cart off?

 

Plus the comment is wrong. I seem to set AUDIN HIGH at startup - not low.

Link to comment
Share on other sites

The problem is the block counter:

grafik.thumb.png.998baf7b06ff7185cba0d7179dbc273c.png

 

IODAT.B1 is connected to 74HC164-B which must be high to enable output of the block address.

 

But, why it affects the EEPROM is not clear to me yet as it uses A7 for CS and A1 for CLK.

 

BTW: No one ever did wonder why A1 and not A0.  Simply because A0 did not work back in time and I did not have the stamina to search why ?

Edited by 42bs
  • Haha 1
Link to comment
Share on other sites

29 minutes ago, 42bs said:

The problem is the block counter:

grafik.thumb.png.998baf7b06ff7185cba0d7179dbc273c.png

 

IODAT.B1 is connected to 74HC164-B which must be high to enable output of the block address.

 

But, why it affects the EEPROM is not clear to me yet as it uses A7 for CS and A1 for CLK.

 

BTW: No one ever did wonder why A1 and not A0.  Simply because A0 did not work back in time and I did not have the stamina to search why ?

Thanks! It is amazing that the code you wrote in "created : 11.05.95" still is in active use 25 years later ;) 

 

I will change my bootloader to set the IODAT to $0B. This should not have any bad effects. Just take away problems.

  • Thanks 1
Link to comment
Share on other sites

It is even more amazing the code from 25 years ago is still in use and we have such quick technical feedback from the author... :)

 

I tried writing $b to IODAT before the first read, however it is the same behavior where the first read is bad. I can also see now in lynx_eeprom_read that IODAT is being used without being set, so in theory this should have cleaned things up. But since the dummy read seems to work reliably, I at least have that as a work-around.

 

For reference, here is the source to lynx_eeprom_read I am using. My code must set "cell" prior to calling it, so the code knows which EEPROM word to read. But if, on the first EEPROM read, I simply perform two reads back-to-back, then I always get the correct result.

lynx_eeprom_read:
	lda	cell
        and     #$3f
        ora     #EE_C_READ
        jsr     EE_Send9Bit

        lda     #$a
        sta     IODIR            ; set AUDIN to Input

        clc
        stz     ptr1
        stz     ptr1+1          ; Clear result
        ldy     #15              ; Initialize bit counter
@L1:
; CLK = 1
        stz     RCART0
        stz     RCART0
; CLK = 0
        stz     RCART0
        stz     RCART0

        lda     IODAT
        and     #$10             ; mask bit
        adc     #$f0             ; C=1 if A=$10
        rol     ptr1
        rol     ptr1+1           ; shifts 0 to Carry
        dey
        bpl     @L1

        ldx     #$1a
        stx     IODIR            ; set AUDIN for output
;EE_SET_CS_LOW

        ldx     #3
        stx     SYSCTL1
        dex
        stx     SYSCTL1

        lda     ptr1
        ldx     ptr1+1          ; Load result

        rts

 

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...