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.
Oooh sorry, I overlooked that.
You know what, I scratch undo. I’d like to focus on the IDE, would be too many things to juggle.
EDIT:
I’ve fixed the LIL bug.
It’s looking good now, except flickering because no double buffer.
bin if you wanna try this out
firmware.bin (180.4 KB)
LIL functions for Pokitto:
p_write what [x] [y] [color] write value to screen
p_read waits for pokitto button press and returns
its value (ABCURDL = 0123456)
p_clear [color] clear screen with given color
p_wait n wait (sleep) for n frames
p_rect x y w h color [filled] draw a rectangle
p_circle x y r color [filled] draw a circle
p_line x1 y1 x2 y2 color draw a line
general LIL cheatsheet (find more in lil's readme.txt)
case-sensitive
separate with ; or newlines
## comment
[...] execute what's inside square brackets and substitute the result, e.g.: print [expr 1 + 1]
if ["not"] val then [else] branching, e.g.: if 1 {print one} {print noone}
while ["not"] val code while loop
for init expr step code for loop
foreach [name] l code executes code for each list item (its value will be in "name"), returns list of evaluations,
e.g.: foreach i [list a b c] {print $i}
return [val] returns from function with optional value
set var val set given variable to given value
$var get variable value (same as set with only one argument)
expr a b c ... combines arguments into one math epression, evaluates and returns the result
func fname args body define a new function, e.g.: func myfunc {a b} {print $a $b}
list a b c ... returns a new list with arguments as items
count l returns number of items in a LIL list
index l i returns ith item in a LIL list (0-based)
indexof l v returns index of first occurence of value in a LIL list, or empty string
append l v appends a value to a LIL list
slice l i1 [i2] returns a slice of a LIL list
eval a b c ... combines argument into a single string and evaluates as LIL code
char n converts int to char (one-character string)
rand returns a random number between 0.0 and 1.0
inc name [val] increment variable (or add given value)
EDIT:
I was confused about how the display worked, it actually has kind of a double buffering. Now it’s fixed:
Am I understanding it right it works like this?
You can write pixel to the hardware LCD, and the screen then keeps showing these pixels until the next refresh? So it needs no extra memory to just hold a picture. So the direct drawing methods write it directly to the LCD where it stays until a refresh. The undirect methods write to the screen buffer – which depends on the screen mode – and the buffer is directly written to the screen on a each Pokitto::Display::update (which is the double buffering – one is the screen itself, and the RAM screen buffer is the back buffer).
So theoretically we can work without a screen buffer and save a lot of RAM on the display buffer?
EDIT:
Adding LIL examples:
You got it correct. Direct is a bit slower than the buffered modes though, as more commands need to be sent more often.