With our own plugin, yes.
Even with hardware the Cortex plugin isn’t as seamless as I’d like.
I might have another solution for this problem soonish, I hope. I just moved to Portugal so this week has been really crazy. Hopefully I’ll be able to get back to coding soon. On the good side, I’m now on a similar timezone to you guys.
Wait, you sent more? It’s alright, the address I gave you is my dad’s. He’ll tell me when they arrive.
I got the first package, kept one Pokitto and made a friend earn her Christmas present (told her to make a game for it, she wrote a Pong clone… eh, good enough.)
Out of curiosity, how possible would an Android port of the pokitto emulator be? OR would it be considered too risky to emulate a handheld on a handheld when hardware sales might be effected?
I guess it wouldn’t be hard. Would have to set up the Android SDK+NDK, make a project, maybe some minor changes, and add on-screen controls.
It probably wouldn’t affect hardware sales negatively.
For those of you who don’t mind building the emulator from source, the version on github now supports joysticks, does not have the debug pixel in the corner, and should be more accurate speedwise.
Gah, sorry, I wasn’t sure if I had implemented eeprom support already or not and made a mental-note to check… then I lost the note somewhere.
There’s code in there for reading/writing to the eeprom. If your code works on hardware but it doesn’t work in the emulator, maybe you’ve found a bug.
For those compiling the emulator from source, there is now:
Initial joyhat support (mapped to right joystick on an xbox controller)
Initial RTC support (reads system time, can't be set yet)
Fixed pause and continue execution from GDB (using Control-C or in an IDE)
Timers upgraded to 64 bit
Ah, right… I suspect that’s not the emulator’s fault either. It just gets the OS-provided number of seconds since the epoch and puts that in the RTC_COUNT register. I guess I could add a fixed offset if the problem really is on my end.