Jump to content
IGNORED

Storing variables on 93C46 EEPROM


Ninjabba

Recommended Posts

I'm using Lynxman's flashcard to develop my demo here together with the latest cc65 compiler, and I been told that its possible to store some data on the 93C46 EEPROM. But I have no idea how this should work? And is it possible to store one or more 2d arrays with some short values on there?

Link to comment
Share on other sites

I would like to store some inventory-items and some general information. I have them defined in the following arrays:

 

unsigned short int InvItems[10] = {1, 0, 2, 0, 3, 0, 4, 0, 5, 0};
unsigned short int Magic[10] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
unsigned short int Weapons[5] = {1, 0, 0, 0, 9};
unsigned short int Shields[5] = {1, 0, 2, 0, 9};
unsigned short int Armors[5]  = {1, 4, 0, 2, 9};
unsigned short int Helmets[5] = {1, 0, 1, 0, 9};
unsigned short int Amulets[5] = {1, 1, 0, 4, 9};
int General[5] = {1, 4, 3, 2, 12447};

Link to comment
Share on other sites

The ranges for the first 7 arrays are from 0 to 10, the 8th array could be also of type "short int", but then the last value needs to be stored separately. It represents "money", so its range should be big.

 

The number of times to save the data... I'm not sure. If its possible, maybe provide the player with a save button, or save at every area-transition.

Edited by Ninjabba
Link to comment
Share on other sites

The ranges for the first 7 arrays are from 0 to 10, the 8th array could be also of type "short int", but then the last value needs to be stored separately. It represents "money", so its range should be big.

 

I'd convert them where possible to be "unsigned char" personally. You'll generate less 6502 code to handle them.

 

If that is the only data you want to save then I don't think you need to compress them at the moment.

 

As a general rule stick to 8 bit types whenever possible in CC65.

Link to comment
Share on other sites

The ranges for the first 7 arrays are from 0 to 10, the 8th array could be also of type "short int", but then the last value needs to be stored separately. It represents "money", so its range should be big.

 

I'd convert them where possible to be "unsigned char" personally. You'll generate less 6502 code to handle them.

 

If that is the only data you want to save then I don't think you need to compress them at the moment.

 

As a general rule stick to 8 bit types whenever possible in CC65.

 

Thanks for pointing out. I should really use unsigned chars all over my project. Still, how do I read/write to the EEPROM? I haven't been able to find out some good resources to work with.

Link to comment
Share on other sites

The ranges for the first 7 arrays are from 0 to 10, the 8th array could be also of type "short int", but then the last value needs to be stored separately. It represents "money", so its range should be big.

 

I'd convert them where possible to be "unsigned char" personally. You'll generate less 6502 code to handle them.

 

If that is the only data you want to save then I don't think you need to compress them at the moment.

 

As a general rule stick to 8 bit types whenever possible in CC65.

 

Thanks for pointing out. I should really use unsigned chars all over my project. Still, how do I read/write to the EEPROM? I haven't been able to find out some good resources to work with.

 

Its very easy to write and read eeprom,

i use nearly all bits of the 1024bits (64 words) in Lynxopoly.

you can have every code snibble you need.

 

First question, do you have the read and the write code?

i have attached it. so you can include it in your project.

 

You should only write to eeprom if the value in the cell has changed - cause of lifetime of the eeproms.

 

you can do it the way

 

write_ee(cell,newvalue)

char cell;

uint newvalue;

{

if (EE_Read(cell)!=newvalue) EE_Write(cell,newvalue);

}

 

for the small values use char or unsigned char.

than you have for example 0-10 that are four bits you can pack it the way

newvalue=0;

newvalue=firstbyte;//write the first byte

newvalue<<=4;//the next byte uses four bits, so shift it 4 bits to right

newvalue=newvalue+secondbyte;//add the byte

newvalue<<=2;//the next byte uses two bits, so shift it 2 bits to right

....etc

write_ee(0,newvalue);

 

i made a excelsheet where i planed where i write what byte/bit or word to use the space perfectly.

 

for money maybe you should use the complete word with an unsigned int (0...65535)

 

read it back with collecting the bits out of the words...

 

 

Regards

Matthias

eeprom.zip

Link to comment
Share on other sites

Thanks a lot! This should help me out. Does the Handy emulator also emulates this? It would be painful to test and debug on the flashcard indeed.

 

no Handy cannot emulate the 93C46

 

If you would test it, you may use the flashcard.

 

with the hterm you can also read out the flashcards 93C46.

So you can check with it the value when it is written on the chip.

But its very easy to implement it.

 

 

Regards

Matthias

Link to comment
Share on other sites

  • 1 month later...

Finally reached the state in which I want to implement the save feature. Assembly being my 'only weakness' ;), I'm struggling getting it included in my project. The main problem I think is that the file Matthias provide me is not compatible with the latest cc65 build. After a first compile it gave me the error of ':' missing at certain lines. After adding them, those errors disappeared. But then there are these two errors I get:

 

../save/eeprom.s(46): Error: `:' expected

../save/eeprom.s(46): Error: Unexpected trailing garbage characters

../save/eeprom.s(52): Error: `:' expected

../save/eeprom.s(52): Error: Unexpected trailing garbage characters

 

looking in the code, I have

 

I2Cword       ds 2

               .global _EE_Read
               .global _EE_Write
               .global _EE_Erase
			
xref popax,tstax

 

with I2Cword at line 46 and xref at line 52. Adding colons here doesn't fix it though... any ideas?

 

Edit: just found some files in Karri's Solitaire sources that might help me out.. gonna try that now

Edited by Ninjabba
Link to comment
Share on other sites

Just want to mention that there is _now_ code for the 93c66 and 93c86 (which have more memory). But they are only for the newcc65 (BLL times). As this is available as source code it might also be adoptable to Karris cc65 version.

 

Again: newcc65 code and Karris cc65 code are _not_ compatible. Code has to be modified to work on the other compiler. This seems to be the problem you have with Matthias code.

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...