Jump to content
IGNORED

Driver for 24AAXXX EEPPROM mounted on karri's carts


Nop90

Recommended Posts

54 minutes ago, Nop90 said:

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 6.85 kB · 2 downloads

There is something wrong with the address.

 

This code:

        tbuf[0] = lnx_24AAXXX_byteRead (0, 0);
        tbuf[1] = lnx_24AAXXX_byteRead (1, 0);
        tbuf[2] = lnx_24AAXXX_byteRead (2, 0);
        tbuf[3] = lnx_24AAXXX_byteRead (3, 0);
        tbuf[4] = lnx_24AAXXX_byteRead (4, 0);
        tbuf[5] = 0;
        tgi_outtextxy(10, 50, tbuf);
 

Produce HHHHH instead of Hello

Link to comment
Share on other sites

11 minutes ago, 42bs said:

so a linear address makes more sense.

Yes, better pass the whole addr as unsigned int.

 

12 minutes ago, 42bs said:

How does __fastcall__ pass the first parameter and the second?

from CC65 manual

Quote

If the function is declared as fastcall, the rightmost argument will be loaded into the A/X/sreg registers:

 

  • A - 8-bit parameter, or low byte of larger types
  • X - 16-bit high byte, or second byte of 32-bits
  • sreg - Zeropage pseudo-register including high 2 bytes of 32-bit parameter

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.

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Edited by Nop90
Made a change to the attached file
Link to comment
Share on other sites

16 hours ago, Nop90 said:

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)

 

No problem. I soldered two carts yesterday. One for you to the address I have for you in Roma and one for @42bs to his address in Dottingen. I believe this is the easiest way to get the drivers tested. (Both carts already posted. I hope you have not moved ;) )

20201218_092149.thumb.jpg.0a88884880caa1d273daf5644251d7df.jpg

 

There will be a few extras. As you see here on my HOT plate. If somebody else would like to have a prototype with 64k eeprom + 512k flash PM me (€15 + postage). You can read/write both the flash chip and the eeprom with the programmer HAT and a Pi. Obviously the Lynx can read/write things in the eeprom making new kind of games possible. Minecraft comes to mind...

 

And the new driver WORKS!!! Well, at least you can read  bytes. There is still some write tests that needs to be done as well. Plus the new page access tests.

20201218_093000.thumb.jpg.0b8c6e5cf4070bb558c1954a5ea31934.jpg

 

PS. I did change the naming of the routines a  bit and included the driver in the cc65 libsrc/lynx driectory. So you can activate the drivers by just using the entry points in your code in the same way as the other eeproms. (eeprom64k.s)

  • Like 2
Link to comment
Share on other sites

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

 

Edited by Nop90
Link to comment
Share on other sites

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.

Edited by Nop90
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

37 minutes ago, Nop90 said:

Now I have to write a function that reads an arbitrary number of bytes starting from an arbitrary address.

Yes. I believe that this is what a programmer really wants.

 

The way I was thinking to use the eeprom is to save structs. This means that the size is arbitrary, unfortunately.

 

A typical struct may be an object with "memory". It has a reference to a sprite for appearance and most likely scripts that get triggered when you interact with the object. The object may change appearance or content during gameplay. In a game you may also drag these objects with you or perhaps they get dynamically assigned at the start of the level.

 

So perhaps something along the lines:

name      Elf
property  1,0,0,0
attribute 9,9,2,2,2,2,6,6,4,4
inventory 0,0,0,0,0,0,0,0,0,0
picture   3,2,2,1,1,0
scriptvar 1,0,0,0,0,0
scripttxt The Elf has died...
scripttxt -

name      Walk Script
property  12,0,0,0
attribute 0,0,0,0,0,0,0,0,0,0
inventory 0,0,0,0,0,0,0,0,0,0
picture   55,2,2,1,1,0
scriptvar 24,0,0,14,16,5
scripttxt More orcs! They opened a trap door!
scripttxt -

name      Desk
property  10,0,0,0
attribute 0,0,0,0,0,0,0,0,0,0
inventory 0,0,0,0,0,0,0,0,0,0
picture   29,-18,4,2,3,0
scriptvar 2,0,0,3,2,14
scripttxt You find a health potion! Life +2
scripttxt -

I want to discard the objects from RAM when they are not visible and then load them when they are needed from the eeprom. So this is more like a cache.

 

So the kind of function you talk about would be highly appreciated.

Link to comment
Share on other sites

13 minutes ago, karri said:

Yes. I believe that this is what a programmer really wants.

 

The way I was thinking to use the eeprom is to save structs. This means that the size is arbitrary, unfortunately.

 

A typical struct may be an object with "memory". It has a reference to a sprite for appearance and most likely scripts that get triggered when you interact with the object. The object may change appearance or content during gameplay. In a game you may also drag these objects with you or perhaps they get dynamically assigned at the start of the level.

 

So perhaps something along the lines:


name      Elf
property  1,0,0,0
attribute 9,9,2,2,2,2,6,6,4,4
inventory 0,0,0,0,0,0,0,0,0,0
picture   3,2,2,1,1,0
scriptvar 1,0,0,0,0,0
scripttxt The Elf has died...
scripttxt -

name      Walk Script
property  12,0,0,0
attribute 0,0,0,0,0,0,0,0,0,0
inventory 0,0,0,0,0,0,0,0,0,0
picture   55,2,2,1,1,0
scriptvar 24,0,0,14,16,5
scripttxt More orcs! They opened a trap door!
scripttxt -

name      Desk
property  10,0,0,0
attribute 0,0,0,0,0,0,0,0,0,0
inventory 0,0,0,0,0,0,0,0,0,0
picture   29,-18,4,2,3,0
scriptvar 2,0,0,3,2,14
scripttxt You find a health potion! Life +2
scripttxt -

I want to discard the objects from RAM when they are not visible and then load them when they are needed from the eeprom. So this is more like a cache.

 

So the kind of function you talk about would be highly appreciated.

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.

  • Like 1
Link to comment
Share on other sites

54 minutes ago, Nop90 said:

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.

That is not really a problem since writes are very rare during gameplay. I don't expect to write anything while the action is on. After the level I can have a separate write-function. So I can easily make a continuous copy in RAM and write the data as blocks.

 

That is the same way I deal with the smaller eeproms also.

Link to comment
Share on other sites

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.

Edited by Nop90
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...