A GameBoy emulator (GPLv2: gnuboy, ported, tested on K3)

[hawhill]

Hi,

this is something I did for the fun of it: port an ancient version of gnuboy, a GameBoy emulator, to the Kindle. In fact, I only had my eyes on the K3 here, maybe it runs (it should) on the KDX. With some adoption of the key codes, it might work on the K4NT, too. But not as-is.

Caveats:
- e-ink is not an LCD. Although I took geekmaster's idea and implemented a simple 2x2 ordered dither in only black and white to have some amount of predictability regarding update speed. Tetris works almost fine ;-)
- direction keys are direction keys, "Z" (on Kindle) is "A", "X" is "B", "A" is "Select", "S" is "Start", "Home" quits
- no sound (yet)
- no input grabbing: you might want to shut down the framework in order to use it properly.

Sources are attached. Questions welcome. Don't expect me to continue to work on this, this is more of a stupid pet project of mine than anything else. But feel free to hack on it!

The binary "fbgnuboy" (standalone) is in the attached archive as is the source code.

Have fun!

Update 2012 Oct 05: Gave it a try and adopted for 8bpp framebuffers. So give it a try if you own one of the relevant devices.

[geekmaster]

My testing on the K3 eink displays shows that dithered black and white has max speed about 5 FPS for 800x600, but up to 12 FPS for a smaller partial update. For max speed, you could display a full grayscale image of an arcade machine, with a smaller 400x300 (or so) window with only black and white partial updates inside that window.

For a 12 FPS example (which also demonstrates eink driver "deferred write" time-domain artifacts), try my "vidtest" program on the K3. You can download it here:
https://www.mobileread.com/forums/sho....php?p=2012359

The download contains only binary executable. The C source code contains mostly commented-out code for testing out stuff, and is not ready for publishing, but I could provide it anyway by PM on request (if you promise not to complain too loudly)...

[geekmaster]

I just downloaded a tetris ROM and tried this. I see that you did use a smaller window, and the speed for tetris is quite acceptable. For eink, you might even say excellent!

It does show the "deferred write" artifacts, where the drivers are quick to draw black pixels, but can take up to two seconds to draw white pixels when you are updating the display at full 12 FPS speed.

But on this emulator, you have to know what you are looking for to even see it.

Great job here, hawhill! Thanks!

Can we provide a "torrent" link here for the ROM files?

I run it like this:

killall -stop cvm
./fbgnuboy tetris.gb
killall -cont cvm

Those "killall" commands just pause and resume the framework on the K3. No need to do a full shutdown and restart, unless you need to free up the memory used by the framework.

Now all you need to do is create fullscreen artwork of an arcade game console (full grayscale is okay) and position this inside its window area. And you can pause and resume the framework with system() calls in a C program. (You *do* feed your "pets", right?)

EDIT: I like the demo mode, where it auto-plays.

[geekmaster]

I wonder what keys the Super Off Road ROM is looking for. It wants me to do my initials in the onscreen keyboard, but arrow keys not working. Hmm. Does the gameboy have more buttons not emulated here?

Boulderdash actually works pretty good if you can put up with the SEVERE eink driver artifacts caused by every game tile being animated. It has smears in it just like my little vidtest demo. Moving full tiles would probably work better than fractional tile scrolling.

You actually have to DESIGN your animation to compensate for eink artifacts (or write your own eink drivers.)

[hostar]

geekmaster (or anyone): please can you put here link for tetris you run on this?
I tried some random ROMs and it still keep saying:

ERROR: only 4BPP is supported for now

Thanks.

[dave2008]

Originally Posted by hostar

geekmaster (or anyone): please can you put here link for tetris you run on this?
I tried some random ROMs and it still keep saying:

ERROR: only 4BPP is supported for now

Thanks.

K4's screen is 8BPP I guess, you need to hack a little bit to make it work on K4

[paulroberthill]

This is pretty cool!
Action games are a bit too blurry (Contra is painful!) but Zelda isn't too bad.

Sound would be awesome :-)

I wonder what other emulators would be usable? ZX81?

[geekmaster]

Originally Posted by hostar

geekmaster (or anyone): please can you put here link for tetris you run on this?
I tried some random ROMs and it still keep saying:

ERROR: only 4BPP is supported for now

Thanks.

The tetris that I tested was in here:
http://www.fulldls.com/download-othe...oWn%5D.torrent

(Don't forget to turn on PeerBlock or Mobloquer.)

[geekmaster]

Originally Posted by dave2008

K4's screen is 8BPP I guess, you need to hack a little bit to make it work on K4

The 4bpp screens are emulated in software using dithered pure black and pure white pixels. It would actually be quite easy to get those 1-bit black and white pixels onto a K4 or Touch screen (one pixel per byte).

Hawhill used 4bpp games to prevent complexity and loss of image quality by needing to downsample the content. It is better to use content already designed for 4bpp.

On eink, the way its device drivers are designed in the kindle, there are real limitations to how fast you can update the display. If you go faster than 12 FPS, it totally breaks down by using deferred writes that completely destroy the image until the drivers "catch up". Faster than about 1 image every two seconds causes some smearing but the image is still recognizable (with more smearing but still recognizable up to about 12 FPS). It is best to keep changing content limited to a small area of the screen for maximum animation quality. You can have an animated object moving around the screen reasonable well, but it will still smear because although black pixels are drawn quickly, the device drivers can take up to two seconds before they get around to drawing white pixels (faster if you do not overload them with too many pixels to change). These numbers are based on my own eink testing on a K3 using my own custom test code written in C. I did a LOT of testing...

[geekmaster]

Originally Posted by paulroberthill

This is pretty cool!
Action games are a bit too blurry (Contra is painful!) but Zelda isn't too bad.

Sound would be awesome :-)

I wonder what other emulators would be usable? ZX81?

Games with Moving objects are fine, but side-scrollers change too many pixels between updates, causing the eink device drivers to smear the display by using deferred erases. The "multiple-exposure" blurring effect is a software artifact caused by the drivers being optimized for fast page turns on ebooks, and not for video game animation.

Games with a fixed background and not too many moving objects should work fine (breakout, bubble-bobble, and many board games). Some games also have problems with buttons not working in this gameboy emulator. This program may need a little extra work in button support, but we have the source code so we can fix that ourselves.

Technically, now that we can load a custom linux kernel with kexec (see other thread), we *could* use a custom kernel with eink device drivers tuned for video games instead of ebooks. We just need our game loader to launch the custom kernel.

And remember, the kindles consume most of their battery energy while updating the display, so video animation that updates the display multiple times per second will consume your battery charge faster than reading ebooks that only update the display for page turns.

[geekmaster]

Originally Posted by dave2008

hi geekmaster,

I saw your reply for gnuboy-kindle and I am interested in how you measured those FPS. Could you please give me some hints?

Kind Regards,
dave

In the gnuboy thread I have a link to a page with a vidtest program that I wrote. It is binary only. My source code is full of commented out code and not ready to publish.

I actually use a timer and control when I do a "frame update" command. If I do updates faster than 12 FPS, the screen gets all messed up because of the eink device drivers using a "deferred update" mode that make parts of the screen not get updated until you slow down how fast it is being changed.

And the 12 FPS is only for a partial screen update (about 400x300). Full screen updates can only go about 5 FPS (again by viewing the visible results while controlling the speed of updates). Faster updates makes the screen quality too low to use.

These speeds are for changing only pure-black and pure-white pixels. Grey pixels are MUCH slower to change because they go through a "black->white->grey" cycle (sort of a localized full flash update).

And the drivers treat writing black pixels with higher priority than white pixels.

The big deal is that sending an update command makes the drivers NOT FINISH the update already in progress, and they try to combine parts of screens to figure out what the FINAL image will look like and do that when things are changing fast. This really messes up any animation. You can avoid that by slowing things down...

What I do for onscreen image rotating and resizing is to convert grayscale images to dithered black-and-white when two fingers touch the screen, then do rotations and resizes with finger rotate, pinch and stretch motions. I also do those operations to the hidden full grayscale image and then display that on finger release.

I am currently having issues with the kindle touch reporting wrong finger coordinates after they cross a common vertical or horizontal line white rotating. Trying to sort that out before I publish anything significant in this area...

And yes, there are temporal screen artifacts during updates. Another way to see them is using gnuboy to run the "Boulder Dash" game ROM. During parts of the game when only the main character is moving it is fine, but when it is smooth-scrolling the entire screen things start to "smear" badly. The smears are not hardware, but rather the eink drivers updating black pixels quickly but taking many screen updates before they get around to drawing white pixels. They could catch up more quickly if the game did not use all those changing animated game tiles.

You need to adapt your visual content to work around the eink device driver behavior (designed for quick ebook page turns), or you need to write your own eink device drivers (designed for pixel animation).

(Regarding my announced "vacation" -- I am getting a LOT of family pressure to "get on with it"... So do not be surprised if I stop posting here for long periods of time). But it is SO MUCH FUN to continue to feed my Kindle addiction...

[paulroberthill]

Originally Posted by geekmaster

The tetris that I tested was in here:
http://www.fulldls.com/download-othe...oWn%5D.torrent

(Don't forget to turn on PeerBlock or Mobloquer.)

I really don't think it's necessary to link to torrents. I found some GB roms with a simple Google seach, hosted on http so I could use wget to download directly to the Kindle!

BTW, anyone have an idea why I can't launch fbgnuboy from a Kite script? The same script runs just fine from a ssh shell:

#!/bin/sh
/usr/bin/killall -stop cvm
/mnt/us/fbgnuboy/fbgnuboy /mnt/us/fbgnuboy/tetris.gb
/usr/bin/killall -cont cvm

[hostar]

Originally Posted by paulroberthill

BTW, anyone have an idea why I can't launch fbgnuboy from a Kite script? The same script runs just fine from a ssh shell:

#!/bin/sh
/usr/bin/killall -stop cvm
/mnt/us/fbgnuboy/fbgnuboy /mnt/us/fbgnuboy/tetris.gb
/usr/bin/killall -cont cvm

Have you made your script executable?

How to do it:
Lets say, name of your script is

launch-gnuboy.sh

You have to first run following command over SSH or if you are in Linux on PC, maybe run it in local terminal will be enough:

chmod +x launch-gnuboy.sh

[geekmaster]

Originally Posted by paulroberthill

I really don't think it's necessary to link to torrents. I found some GB roms with a simple Google seach, hosted on http so I could use wget to download directly to the Kindle!
...

I would normally NOT post a torrent link, but the request was for the specific version of tetris that I tested, and the parent webpage for that torrent redirects to an advertising site. So, to satisfy that specific request, I made an exception and provided a direct link to the torrent file that I used.

I agree that we do not want the excessively aggressive negative attention that megaupload got, so unless needed to answer a specific request as I did, we should not post direct links to torrents.

Which begs the question: If you think it was not necessary for ME to post the torrent link, then why did YOU publish the torrent link AGAIN inside the quote in YOUR post? Even if I remove the link from my post, your link to the torrent will remain and I cannot edit your post to remove it.

You did not say WHY you are against posting torrent links, but you did point out that with a direct URL you can use wget to download gnuboy ROMs directly to the kindle. If your anti-torrent comment is because you cannot download gnuboy ROMs directly to the kindle with a torrent link, then you may not be aware that there is a torrent client that works on the kindle (in the optware repository).

[geekmaster]

Originally Posted by paulroberthill

BTW, anyone have an idea why I can't launch fbgnuboy from a Kite script? The same script runs just fine from a ssh shell:

#!/bin/sh
/usr/bin/killall -stop cvm
/mnt/us/fbgnuboy/fbgnuboy /mnt/us/fbgnuboy/tetris.gb
/usr/bin/killall -cont cvm

You did not provide enough details for an accurate reply. It would help to see the command that kite uses to launch your script. Does kite launch your script in the background (with '&' appended)? Some scripts do not run correctly when launched in the background (showing "Stopped (tty output)" error messages). Perhaps you need to remove a trailing '&' from the command line.

Also, you can simplify your script commands a bit with a "cd" (some programs may even require this):

#!/bin/sh
killall -stop cvm
cd /mnt/us/fbgnuboy
./fbgnuboy tetris.gb
killall -cont cvm

Originally Posted by hostar

Have you made your script executable?

Scripts on the USB drive (/mnt/us) are ALWAYS executable because vfat partitions do not have an execute attribute. If you do "ls -al /mnt/us" you will see that ALL files are "+x" even after trying a "chmod -x" on any of them.