42bs Posted December 17, 2020 Share Posted December 17, 2020 Bit shift wrong: 145(10) = 10010001(2) 0x48=72(10) = 1001000 Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 Thanks! I also tested a $00 and it resulted in 1. Quote Link to comment Share on other sites More sharing options...
42bs Posted December 17, 2020 Share Posted December 17, 2020 Soooo close But even a bit matters. "You're bit" "Yes" ? 1 Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 17, 2020 Author Share Posted December 17, 2020 (edited) 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 Edited December 17, 2020 by Nop90 Quote Link to comment Share on other sites More sharing options...
+karri Posted December 17, 2020 Share Posted December 17, 2020 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 Quote Link to comment Share on other sites More sharing options...
42bs Posted December 17, 2020 Share Posted December 17, 2020 I think the parameter passing is wrong. Actually, the chip does not have "sectors", so a linear address makes more sense. How does __fastcall__ pass the first parameter and the second? BTW: "jsr E2_put8; rts" => "bra E2_put8" Quote Link to comment Share on other sites More sharing options...
42bs Posted December 17, 2020 Share Posted December 17, 2020 (edited) I'd suggest also to have "lnx_24AAXX_byteReadNext()" to use the auto-increment feature. Instead of "sector" I'd suggest the name "page" as the chip manual uses. Edited December 17, 2020 by 42bs Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 17, 2020 Author Share Posted December 17, 2020 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. Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 17, 2020 Author Share Posted December 17, 2020 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. Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 17, 2020 Author Share Posted December 17, 2020 (edited) 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 December 17, 2020 by Nop90 Made a change to the attached file Quote Link to comment Share on other sites More sharing options...
+karri Posted December 18, 2020 Share Posted December 18, 2020 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 ) 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. 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) 2 Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 18, 2020 Author Share Posted December 18, 2020 (edited) 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 December 18, 2020 by Nop90 Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 19, 2020 Author Share Posted December 19, 2020 @karri while waiting the cart I'm writing an eeprom emulation class for Handy. Is this a problem with your project to release a phisical release of a game of yours using the 64KB EEprom? Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 20, 2020 Author Share Posted December 20, 2020 (edited) 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 December 21, 2020 by Nop90 1 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted December 21, 2020 Share Posted December 21, 2020 Ordered myself also a bunch to play with. Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 21, 2020 Author Share Posted December 21, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted December 21, 2020 Share Posted December 21, 2020 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. Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 21, 2020 Author Share Posted December 21, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 21, 2020 Author Share Posted December 21, 2020 (edited) And here are the files to add the 64kB eeprom support to Handy eeprom.cppeeprom.h and the rom header file with the new values to activate the eeprom emulation (it's a proposal for the moment) lnxhdr.s Edited December 21, 2020 by Nop90 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted December 21, 2020 Share Posted December 21, 2020 A very good proposal. This also allows you to tune the hardware to match the need. Quote Link to comment Share on other sites More sharing options...
+karri Posted December 21, 2020 Share Posted December 21, 2020 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. Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 21, 2020 Author Share Posted December 21, 2020 Added lynx_eereadbytes_24aa512 (char * buf, unsigned int len, unsigned int addr), if you don't like the name you ca change it. Updated driver: eeprom64k.s This is a lynx rom to test if it works fine with a real EEPROM: E2test.lnx and the sources: E2test.zip Quote Link to comment Share on other sites More sharing options...
+karri Posted December 22, 2020 Share Posted December 22, 2020 I just tested the E2test build in a real Lynx: BYTE WRITE OK BYTE R/W DONE DATA CHECK FAILED VALUE 16 SECTOR R/W DONE DATA CHECK FAILED I am a mit puzzled as I was able to read "Hello" after my tests... Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 22, 2020 Author Share Posted December 22, 2020 (edited) 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 December 22, 2020 by Nop90 Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 22, 2020 Author Share Posted December 22, 2020 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.