USB keyboard also possible
Is that a software stack for bit-banging USB through GPIO?
The description/readmes don’t say much about what it does.
Its a LUFA port
This lufa?
The idea of using Zboy makes me think we could get a lot of games for Pokitto by taking some of existing small C/C++ FOSS games and simply natively porting them, maybe with new graphics etc. Taking full advantage of the free culture 
Just leaving this idea here for anyone who’d like to do it. I will try to do it too when I get my Pokitto.
Look for games e.g. here:
- https://osgameclones.com
- https://github.com/ligurio/awesome-ttygames
- https://libregamewiki.org/Main_Page
EDIT:
Lemme see, I’ll try to make a list of games suitable for this and post it in a new thread.
2 Likes
Before attempting the ZBoy port I had a look at a few of the games in osgameclones. A long, how-much-work-is-this-going-to-be look. Short answer: too much.
For just about any game, the amount of work involved in getting code that was designed for PCs to run on a microcontroller satisfactorily is on-par to, if not greater than, that of simply rewriting the games from scratch, using the opensource implementation as a reference.
ZBoy itself is an example of this; the “ported” code looks very different from the original. The advantage in porting an emulator is that I didn’t have to worry about art. Games designed to fit on a monitor are going to look bad if simply squeezed into 220x176. A proper port would have to manually resize/redraw assets and convert them into more efficient formats. Depending on the game, preparing art can easily amount to half the work.
In all, what might at first look like a simple project might actually be a team effort. Either way, unless it’s a really simple game, porting existing code to the Pokitto is probably harder than writing from scratch.
No need to wait, you can start making things for the Pokitto using the simulator, or either the online or offline Pokitto emulators.
3 Likes
I haven’t programmed for Pokitto yet, so I don’t know how much different it is, but when you say it, you’re probably right most games won’t be worth the effort, I’ve been actually thinking about it too now.
Anyway I think there might be games that could be relatively easy to port - the ones that are small, with minimum graphics, mostly pure C/C++, with clearly separated input/output handling. Like this one maybe? (it’s C, I remember playing it on both Android and PC). (or NetHack port maybe? It’s ASCII-only, but the game logic is sophisticated. Will have to give it a look.)
But now I realize you’ve been talking about exceptions not being supported etc., which would of course complicate things further for C++ games. So yeah
I’ll look into it some more. The truth is I don’t have much experience with porting.
1 Like
“All of these puzzles are written in C, with a porting interface so that the same back-end puzzle code can talk to wildly different graphical front ends.”
How I wish more authors did this. I haven’t looked at the code, but that’s a good sign.
2 Likes
It might be possible to enable them with a compiler switch.
I’m reasonably sure that they’re just disabled by default because most people writing code for MCUs want them disabled by default.
I’m not aware of any reason they couldn’t be enabled, but naturally there would be an overhead.
@FManga & @drummyfish
Arduboy games would be quite easy to port.
Unfortunately most of them don’t work “out of the box”, (mainly because of the stupidity that is the Arduino .ino file) but a large number have open source licences and porting should be fairly easy using Pokitto’s port of the Arduboy2 library.
Thanks. I’m flattered you mention me.
That will be the Tamagotchi Tamago or Tamagotchi Friends (640K/736K ROM, 6502 @ 8MHz iirc). The original 1996 one is much simpler (12K rom 4-bit MCU @ 32KHz iirc)
Can’t agree more. Even though emulating other system is impressive. I don’t really think it’s a good example of Pokitto’s abilities. I do love to see gameboy like games on the Pokitto though.
2 Likes
For a Tamagotchi-like game, we’d need some kind of RTC (I think there is one in the pokitto?) to handle some night/day cycle. Maybe a low power mode? haha
(Actually I’d love to have my own pocket world somehow)
There is indeed.
You can set the time on the loader screen (pressing C when a program starts up).
I would expect there is one, but I’d have no clue how to use it.
I have not written it in PokittoLib yet, but there are sleep and deepsleep modes for the MCU. Audio amp can be disabled and LCD shut down. RTC clock runs even in deep sleep. Of the top of my head I would estimate that Pokitto probably could sleep for a year and then automatically wake up.
6 Likes
I know a lot of people would love to see a tamagotchi clone on a decent hardware like pokitto. As i am in a collectors group in germany for many years now, i know fans do a lot of crazy things to even get their hands on every japanese version. If we had a tamagotchi game with some interesting mechanics such as some character development stages and a few different backgrounds, maybe some die hard fans would buy a pokitto only for this😉
3 Likes
Definitely!
If we can have a “sleep until timestamp is attained” feature that’d do it perfectly. The beast software would then have to calculate some timestamps around where it expects the beast itself to have some needs taken care of. After which it’ll could enable the audio amp, emit some cute sound or anything.
RTC would be great for day/night cycle, + seasons too if needed.
2 Likes
I just made an update to the Gameboy emulator: it now has experimental support for savestates.
I got tired of starting over every time in some of the longer games.
When you drop a ROM into the converter you’ll get a zip with a bin and a blank save file.
Extract both of them to your SD card.
When you want to save, press and hold A then C.
To load, press and hold B then C.
Careful not to mix them up, there’s only one save “slot” per game.
@jonne: I think I found a bug… looks like fileWriteBytes is broken, and it’s not just because of the & that isn’t supposed to be there. I kept getting gibberish until I started writing just one byte at a time.
4 Likes
No, this is in PokittoDisk.cpp:
void fileWriteBytes(uint8_t * b, uint16_t n) {
PFFS::WORD bw;
PFFS::pf_write((const void*)&b, n, &bw);
PFFS::pf_write(0, 0, &bw);
}
Instead of passing a pointer to the data it has to write, it passes a pointer to pointer.
When the &b is changed to b, it correctly writes the first byte in the buffer and the remaining bytes are gibberish.
If there’s only 1 save per game wouldn’t it be simpler to have a auto-load state if a state is found instead of having a button combo to load?
But then how would you chose to not auto-load?
Have a button combo to reset without loading?