So I did compile this
libDLO library and the performance was terrible. 23 FPS for copying a 160x144 RGB16 framebuffer over USB to the device. Turns out the above 40ms for filling the entire screen with one color uses a different code path, a way more efficient one, for crafting the USB packet. Will look into that.
However, it turns out that this library internally converts the given framebuffer to a 24bit RGB framebuffer, pixel-by-pixel, and then tries to send entire rows to the USB device. Also, when
make-ing the library, it compiled it without optimizations!
So I did use
CFLAGS="-O3", inserted the optimized library, and tada.. Game Boy Color emulation at ~90FPS. Internally I set the resolution to 640x480 and use the
dlo_copy_host_bmp() function to copy the smaller framebuffer to the right position of the device's framebuffer.
root@Omega-C465:~# ./gnuboy Pokemon\ Gold\ \(G\)\ [C][!].gbc
test: device info: uid &77B2AC70
test: device info: serial 861145
test: device info: type &F
test: native mode info...
1920x1080 @ 59 Hz 24 bpp base &0
test: mode info...
640x480 @ 60 Hz 24 bpp base &0
DisplayLink Init OK
[-] Skipping data decompression.
FPS: 88.372 delta micros 1357896 for 120 frames
FPS: 87.144 delta micros 1377025 for 120 frames
FPS: 81.944 delta micros 1464420 for 120 frames
Will update the repos soon. So now you can play GameBoy and GameBoy Color on a normal monitor with HDMI/DVI/VGA input and this USB graphics card.
However, this is still way to slow. The to-be-transfered framebuffer was really tiny here and the transfor should have gone even fast than that. The pixel-by-pixel conversion definitely hurts performance. Also I'm completly bypassing the entire Linux by not using the framebuffer device or the DRI/DRM functions, but writing directly to the USB device using
I'll look into the performance of these two other methods once I get them working. Right now writing to
/dev/fb0 doesn't update the screen and only one out of 2 test programs for the DRI/DRM system are working. Maybe has to do something with the kernel-mode-setting (KMS) routines. Another option would be optimizing the libDLO library to omit some sanity checks and use a more efficient frame buffer format that does not require pixel-by-pixel transforms. I'll see.