Modifying the loader

[Sorunome]

Oh, um, rodot, to which arduino board do you have the gamebuino set to? I might have that one wrong...

EDIT: uuuh, i had to install that thing to hardware/gamebuino/gamebuino/<all the files>

But now it gives me
Selected board depends on 'arduino' core (not installed).

EDIT2: nevermind I had to use the beta branch, i'm still getting the same bug on writing with tinyFAT, though

EDIT3: could you maybe please try out to compile my version of the loader? https://github.com/Sorunome/Gamebuino/t ... ies/Loader

It should in theory already worked, everything is tested except of saving the SAV files which is where it is glitching out, but that code didn't change after all.

The changes being that if you hit a SAV file it'll search for a HEX file and open that one instead, and also better EEPROM cleaning as I noticed you just wrote as much as you could of the SAV to the EEPROM but didn't clean anything in the EEPROM afterwards.

[Sorunome]

[...]

About the loader, I wanted to show only hex files, all others are not usable anyway. From there, there is no need to show the file extension anymore. The file size is not very important neither. I also added a small text (to be replaced by a floppy icon) to mark games that have saved data. In the end, it makes a really clean HUI to choose your game, without

Somehow like this?


Also, I suck at pixel art.

EDIT: the saving eeprom bug is still there, but I am positive if someone else will compile it'll work. I'm just not happy with the slow readings of the ICOs off of the SD card :/
the file.openFile() takes like forever

EDIT2: Maybe somebody have an idea on how to speed it up? what is slow is here: https://github.com/Sorunome/Gamebuino/b ... t.ino#L105 especially line 105

EDIT3: I speeded up the drawing a lot now, I had to make one additional object in the file object public, though.

[milk]

Nice ! Really nice !

[Sorunome]

Nice ! Really nice !

Thank you!


So, I need somebody who can build the loader without the saving glitch, for example rodot or someone else who noticed that they could do that, to build the loader for me. https://github.com/Sorunome/Gamebuino/t ... ies/Loader
Everything is tested, I didn't modify the actual saving to eeprom code so I don't see how that should fail if a said person compiles it.
Keep in mind that I had the modify the tinyFAT library a tad, only making one of its private variables public. So only the tinyFAT.h changed ( https://github.com/Sorunome/Gamebuino/b ... /tinyFAT.h )

What I changed:

• When loading a EEPROM it also wipes the rest overflow, or if the file is empty it also gets wiped
• The loader only displays .HEX files and doesn't display itself
• Icon images can be loaded from a file, they have to have the same filename as the HEX file and as extension ICO. Such a file can be created here: http://www.sorunome.de/makeGamebuinoICO

Also if this reaches the main branch I guess i can upload the (crappy) ICOs I already made

[erico]

Here some criticism.

Letters are too big, maybe use smaller ones or none at all?
I find letters+icons to be a redundant thing, best keep only one of them maybe?
It is tough call, tech people prefer letters, standard users/gamers may prefer icons only.

I´m thinking about it, we already have an intro image, maybe call coders to have an icon for such?

Anyways, it looks pretty good and it is a great idea! Well done!

[Sorunome]

Here some criticism.

Hehe

Letters are too big, maybe use smaller ones or none at all?

I don't like the 3x3 font, and besides it was more a struggle concerning width than height, so they wouldn't actually "gain" anything concerning width, and i think I managed to squeez it in quite well.

I find letters+icons to be a redundant thing, best keep only one of them maybe?
It is tough call, tech people prefer letters, standard users/gamers may prefer icons only.

I'd use both for the following reasons:

• Some games may have similar icons
• IMO a name still belongs to an icon, such as a username belonging to an avatar in a forum
• Icons on a desktop also have both
• That way, if there is no icon, you don't just get a blank space or something

I´m thinking about it, we already have an intro image, maybe call coders to have an icon for such?

What do you mean by this?

Anyways, it looks pretty good and it is a great idea! Well done!

Thank you!

[jonnection]

Hi Sorunome (and Rodot, and Milk)

I got interested in your problem (saving the EEPROM) so I took a short look. I might be wrong but two things come to my attention.

In your loader.ino main program:

Code: Select all

SPI.setClockDivider(SPI_CLOCK_DIV128); //lower the SPI speed for better compatibility
  initres=file.initFAT();

Are you aware that unless a speed is specified in file.initFAT(...here is supposed to be the speed parameter ...); the TinyFAT library defaults to maximum SPI speed ? In TinyFAT.h there is:

Code: Select all

initFAT(byte speed=SPISPEED_HIGH);

... which means that if initFAT is called without a parameter, speed is given the value SPISPEED_HIGH.

This means that there is a possibility of a conflict between you setting the SPI_CLOCK_DIV128 and what the initFAT function does next. We have already found out, that the Gamebuino SD's do not like fast SPI speeds and can crap out at high speeds.

Second point, BINARY DATA vs TEXT FILE

TinyFAT only has a writeLn function that is intended for TEXT FILES ONLY. Now, I have not checked what the EEPROM data actually is, but for example if the EEPROM data is a 0x00, what it actually means to the writeLn function (which takes a char* pointer as a parameter) is THE END OF STRING. Therefore, string length will be 0 and 0 bytes will be written. In order to write binary data using tinyFAT you would first have to change all your data into printable characters, so only values between 0x20 and 0x7E are allowed. Therefore, for example, the binary value 5 can not be written by writeLn(5) it has to be writeLn(5+0x30); ... ie. "5".

However, the fact that you get crap out even when you do file.writeLn("asdasfd") is saying to me that for some reason the structure "file" is somehow malformed and it is not pointing to the correct offset in the mmc structure, but is pointing into the FAT table instead. Therefore, the writeLn function writes to the wrong address in the MMC (not in the data sectors but in the FAT table).

People are using the SdFat library to write binary data to SD cards. To my knowledge, writing binary data files with TinyFAT is not supported, and Henning Karlsen has said is not going to support it. In fact, if you open a file in FILE_BINARY mode, writeLn will return with a wrong file type error.

This makes me wonder that perhaps the saveEEPROM function has NEVER worked correctly on the Gamebuino ... but I might be wrong because I do not have a Gamebuino and I have never used that function myself.

[Sorunome]

Unfortunately lowering the clock speed did not do the trick, it still created the same malformed data.

About the text only: That is why the following trick is done:

Code: Select all

        byte b = EEPROM.read((i*BUFFER_SIZE+j)/2);
        buffer[j] = 0x0F | b;
        buffer[j+1] = 0xF0 | b;


That way we don't end up with 0x00 if we have 0 in the EEPROM but actually with 0x0FF0

[jonnection]

Unfortunately lowering the clock speed did not do the trick, it still created the same malformed data.

About the text only: That is why the following trick is done:

Code: Select all

        byte b = EEPROM.read((i*BUFFER_SIZE+j)/2);
        buffer[j] = 0x0F | b;
        buffer[j+1] = 0xF0 | b;


That way we don't end up with 0x00 if we have 0 in the EEPROM but actually with 0x0FF0

Yep. You are correct there. And mmc.writesector doesn't care a toot if it is an ascii character or not. So that can't be an issue.

What I am wondering now is how it has worked in the first place. TinyFAT library as far as I know hasn't changed for a while.

[Sorunome]

well rodot seems to have no issues writing with the tinyFAT library.