I was actually once trying to access the card while it’s been in the laptop, so now I keep checking it’s actually there.
Actually this works – the files get listed. How did you do that? I have noticed my firmware.bin is much larger, which is probably because of -O3… have you turned it off? Could that be the problem?
EDIT:
Without optimizations it doesn’t run 
Gives just a red screen. It needs at least -O1 or -Os (it’s still bigger than your bin).
That last bin doesn’t include a filesystem library at all, that’s why it’s smaller. It’s using the loader’s filesystem API, which is why I asked you to update. I didn’t implement a check, so if you were to install the original loader it would crash.
This rules out issues with your code and shows that there’s a problem with the combination of SDFS and your card. I suspect that if you tried the previous bin (which uses SDFS) on another card it might work.
Yep, another card works.
What can be wrong with the card?
Hard to say without debugging SDFS on it. 
We really need a list of all these broken things so we can start fixing them.
In fact I might put these on the big TODO list later.
This is why I’d eventually like to switch to an object implementation.
Then the destructor can close the directory and nobody has to worry about leaks.
As you can see I am totally lame with hardware and filesystems, so I dunno if I can autonomously debug that, but I can follow your instructions if you want.
Anyway… I think for the purpose of finishing the program I can just switch SD cards and use the one that works for now… it won’t be difficult to rewrite for a different API in the future.
Do you think you could at least identify the maker and speed class of the cards?
(In case those things are useful or relevant.)
NOT WORKS (one that came with Pokitto): Nokia microSD 2GB, avg. write speed: 7.13 MB/s, avg. read speed: 16.95 MB/s, showed no corrupted sectors during read
WORKS: SanDisk microSD 2GB, avg. write speed: 2.37 MB/s, avg. read speed: 19.74 MB/s, showed no corrupted sectors during read
Can’t find the speed class logos, but am testing the speed with some tools.
Here’s some more for the list, then:
Yes, that would be best.
Just make sure you use sdfs->open( "file.txt", O_RDONLY ) instead of fopen("/sd/file.txt", "r").
Okay so I’ve switched the card and it behaves like the emulator now, and I’ve also switched to using the SDFS directly. What I’ve noticed is that when I first list the files (select “open”), a sound is played, almost as if something’s overflowing somewhere 
Anyway it works except for writing files now. FileHandle->write() always returns -1, even though it sometimes does change the content of the card… it looks like it creates new files correctly (with O_CREAT… still returns -1), but overwriting existing files (with O_WRONLY) seems to overwrite all files to the same content (messes up the FAT table or something). Anyway I have to check my code again. Emulator seems to do the same things.
That’s probably a class 6.
That’s probably a class 2.
I really wish manufacturers would remember to stamp the speed class on the card.
To test the speeds I’ve used a thing I found that’s named Fight Flash Fraud – apparently even if they stamp it they often lie
True, this does happen. Some particularly bad ones don’t even have the capacity they advertise.
Worse still, some are designed as a means of spreding viruses or executing MITM attacks.
There’s a very interesting article about trying to reverse engineer and use the microcontrollers embedded in SD cards for other purposes:
https://www.bunniestudios.com/blog/?p=3554
Oh god it seems to somehow be working, though that scary sound is making me nervous and emulator breaks on saving (according to above this should be a known bug). So let’s implement undo and this should be done.
Yup, known issue. Haven’t had a chance to get to it yet.
I think this is
FIRST
EVER
PROGRAM
to be completely written and “compiled” and run exclusively using only Pokitto 
It’s a small step for man…
Now you just need to pair it with this:
Nice!
In order to make this “IDE” I reworked the text editor so that it’s more forkable and you can make it into whatever you want. I’d like to ship this small LIL IDE along with it as an example.
I have it nicely in place now, it shows syntax errors in a popup window and sets the cursor on the position of the error. However I’m seeing a weird behavior of the LIL environment with one critical function (expr) and think it’s a bug, as on my PC the code works well. Rather than digging for the bug we might plug in a different language, such as LUA Lua.
I have to finish the undo system as well, so I may put this aside until then, but for the curious the code is always live here.
Lua isn’t an acronym.
Lua (/ˈluːə/ LOO-ə; from Portuguese: lua [ˈlu.(w)ɐ] meaning moon)
It has an interesting history.
I intend to get round to trying Pawn sometime soon.
It’s not as flexable as the other languages that have been proposed, but it’s smaller from what I hear.
It is now, it means Lua Unforeseen Acronym
Never heard of it, but smaller sound better – considering it has to live along the editor. If you want, try to replace the LIL in my repo with it. I’d be glad if someone took care of it before I finish the PokiPad.