Hello folks, I am the author of zBoy and I found this extremely interesting thread last night. I am very happy to see that zBoy lives on on this “Pokitto” platform. Never heard of “Pokitto” before, but it looks like a truly amazing piece of hardware!
@Fmanga - I’d have a few questions, if you don’t mind…
where can I see the source code of your port?
I understand you performed some optimizations or other improvements along the way, is there any chance these could be integrated upstream?
I see that Pokitto uses custom color palettes - is it relying on the original zBoy custom palette feature? Is there a single place where I may find all your palettes, so I could add them to zBoy?
Last question - why did you select zBoy for this project? I mean, I am very happy you did, but I guess there are some other (better) gameboy emulators out there?
I am Jonne, the originator of Pokitto. I am honoured to have you here.
I chose zBoy and made the first very slow port. The reason why I chose it was because out of all the available Gameboy emulators, your source code was best suited for the modifications (memory mapping) that needed to be done to get the emulator working on a device that had <64kB of RAM
The source to the port is in the repo @Pharap linked, the source to the converter is in the gh-pages branch of the same repo.
A lot of the optimizations I made are very specific to the Pokitto. Unless you’re trying to get the code to run on another 48mhz ARM device with 36kB of RAM, they don’t make much sense. As an example, video.c contains thumb2 assembly code. Also, since the Pokitto only has 256kb of flash, I didn’t have to take into consideration games that take up more than 128kb of space, so large games are probably broken.
Some optimizations can be sent upstream, but it won’t be a simple process.
As for palettes, it does use the original feature. They are “injected” into the compiled binary by the converter in javascript.
Going with zBoy was @Jonne’s decision, and I agree. Other emulators would be harder to get running within the constraints.
Hi Jonne, congrats on this project! Should I be 20 years younger, I’d probably be batshit crazy about it.
It’s nice to know that there is something I did right with zBoy, I guess it helped that I designed it with the intention of being able to run some GB games in DOS (which is a quite constrained environment, although of course nowhere near as much as Pokitto).
Indeed, looking now at the code it is pretty obvious this is highly custom code, crafted specifically for Pokitto. Not super useable for me, although I will browse the repo, perhaps will I spot some bits that I could port back into zBoy, you never know. In any case, well done, I’m impressed!
Thanks again, it’s all clear now - I know where to look for the palettes. I will test your palettes, and perhaps I will push a few of them upstream, from the screenshots I see some of the games look really neat with your palettes.
You might be interested in the implementation of the MMU and MBC0/MBC1 (avoids the use of branching when looking up memory regions). Also the use of function pointers in cpu-z80 for instructions might be useful in other contexts.
I don’t think the code for that would fit in flash right now, but it might once I switch to the loader’s filesystem API. It shouldn’t be too hard to get at least one of the channels to work.
I committed r137 to the svn trunk today. This version includes a sound emulation prototype that I worked on during few past days.
It is clumsy, buggy and sounds awful. It also supports only 2 channels (out of 4). But it it’s a start. I’m confident I will be able to improve it a lot with some work.
I don’t know if this can help you guys enable sound in the Pokitto thingy, but who knows. I would say that sound support requires around +20% of CPU power compared to the no-sound version, so if you are already tight on cycles, it might be hard to squeeze sound in… (esp. since sound requires full-rate emulation).
Without looking at the code, is it possible to skip gfx frames, but emulate audio still for each frame? That would save cpu cycles. I have used that technique in the Frodo C64 emulator which I once ported for Nokia Symbian phones.
This is something I was thinking about when I had the unpleasant surprise to discover that host audio frequency and cpu cycles never want to match exactly (because of rounding, and because perfect oscillators do not exist, and because emulation speed may vary by a few microseconds here and there). Ultimately I dropped the idea, and instead of dropping frames I implemented an automatic frequency-adjusting mechanism that slightly changes zBoy’s output sampling rate so it’s able to lock in exactly with the host audio frequency. The current version is really awesome BTW, will post a video soon - progress is huge compared to r137.
Anyway, all this to say that your idea is valid, and should be easy to implement in FManga’s port. There is one drawback however: I already experimented with frame skipping in zBoy many years ago, and I noticed that it is very easy to break a game, visually. For example the on-screen character moves on the screen, but doesn’t appear to move his legs any more. Or fires bullets that are… invisible (because they are drawn every odd frame or so). GB games heavily rely on an accurate frame rate for playability, so before even thinking about skip-frame stuff I’d rather see how much performance is missing. Perhaps after the many (Pokitto-specific) optimizations @FManga did already, sound will be a breeze to support. Or perhaps it will be simpler to drop a sound channel instead - most games sound very good already with only the two square channels emulated, the wave and noise channels are rather used for minor musical effects.
A huge saver would be also to limit the frequency of zBoy’s output - simply moving from 44.1 kHz stereo to 16 kHz mono would make things many times faster (at the cost of audio quality, of course).
These are some good examples of why it’s a bad idea to tie the timing of a game to the frame rate,
and why most modern computer games rely on looking at an actual timer and/or do delta timing instead of depending on the framerate.
…and here is r181. I implemented all four channels, and all games that I tested sound very good. I do not expect to do any changes now until the formal (v0.70) release, which should happen soon.
Can I just say its so cool that you came to hang around with us!
Your Pokitto is on its way - I have been busy due to a very positive problem - we’re getting lots of orders for some reason I do not know, even though I have done zero marketing past month
