Uploading to the bitbox, part II (bootloaders)

Bitbox has now a 2-stage bootloader : here is how it works.
Game programmers shall not worry about this since it's automatically taken care of by standard building scripts.

The principle is the following : a small first bootloader loads a second, more featureful bootloader to RAM and runs it. The second bootloader loads a program and writes it to flash.

Uploading programs to the bitbox, part I (writing the bootloader to chip)

The current note is about uploading programs to the bitbox memory directly. This is not useful if you only plan to use the microSD bootloader. It will be useful to upgrade the first bootloader, or reflash it, or to have complete control and debug the bitbox from a PC.

Devices API design

Revision 1 API

the preceding API for gamepads on rev1 was very simple : in fact it was only a halfword (!), representing the bits of each button on the SNES gamepad. This was simple, convenient and closest to the hardware.

Now with the different class of devices that can be used and the fact the USB HID is used, I think we will need to have a different API.

Blinking Happily

Hi ! Just wanted to share this : the first prototypes of Bitbox rev2 PCBs have arrived (at last !)

So I couldn't resist building one and writing / uploading (using SWD) a very quick test program : it ... blinks ! (meaning I didn't screw up the MCU soldering it :)

Thanks to Marcus for his help on this release !

I'm not dead !

This rev2 will add : 32k colors, stereo sound, USB gamepad connectivity, UEXT expansion ports ...

(edit) Just a small update : VGA gen has been tested OK, SDIO flies at more than 6MB/s on the right conditions, sound is OK (with a small update)  and USB works ! All this needs to be upgraded in a whole new kernel, but independently all reporting OK !

BitBoy : a gameboy emulator for bitbox !

BitBoy is a port from the gnuboy emulator heavily modified to fit in the Bitbox console.

The Gameboy emulator successfully emulates several games and homebrews for this venerable console.

Screenshots

Screenshots of the emulator.

The menu to select the on-chip games


NB :  Emulators are standard SDL games built with all bitbox programs running on the bitbox kernel with no modification of the game source code as the normal build of any game.
Meh, an emulator. But not only, it runs also on the real hardware : 

Available features

• Based on (heavily modified to fit in memory constraints : 1MB incl. games & vga generation+ 192k RAM !) gnuboy emulator, as GNU GPL code available on github
• Working Commercial and homebrew GameBoy titles (public domain homebrews or rightfully licensed games !)
• 4 color palette B&W display, with custom palettes (fixed colors by game) to colorize the games.
• Working on rev1 hardware including gamepad
• Several ROMs can be embedded in on-chip flash (up to 1MB), with a selection menu

Source code

Code (including original very good gnuboy emulator heavily modified) is available here : https://github.com/makapuf/bitboy

Making of 

The adaptation of gnuboy to bitboy consisted of : 

• mapping the inputs to bitboy rev1 gamepad
• rewriting the main loop & main function (from command line to bitbox kernel frame interface), remapping time-relating functions.
• interfacing the sound callbacks of bitbox to gnuboy engine generation.
• removing / disabling all file related functions. Some could be re enabled to save some backup RAM to SDCard by example or load data cart from SD Card.
• rewriting all the display code, not to fit bitbox display model -this adaptation was done quite simply by blitting a virtual framebuffer, but to make it faster and not depend on huge (100k) in-memory precomputed tables. Now only B&W GB has been done, but color could be done.
• writing a blitter for the gnuboy pseudo-vram to Bitbox graphical kernel. Maybe this step (and the 2 VRAM buffers) can be skipped and real Bitbox lines be generated on the fly by the new gnuboy, faking Gnuboy v-syncs from the real Vsync bitbox interrupts.
• modifying the memory mapper to use bitbox flash / Ram & mapping some RAM data (2 VRAM buffers) to ccm ram in order to save place in sram, disabling many functions like rom compression, battery-powered ram.
• making a menu loader of ROMs in Flash, replacing the file loader. This is currently done by embedding roms as C data. Some quick "compression" could be done. (removing zeros or const data at end of pages)
• menu selection of ROM as several ROMs can be placed in flash
• linking ROM to custom palettes : Color games are not supported yet (colorized games using custom palettes are supported however), but given the size of those color games, they often wouldn't be able to be stored on the box anyway.
• cutting color gameboy features to simplify development and lower memory requirements (standard GB has 8k, GBC has 32k of RAM, which could fit in CCM RAM, 16k VRAM vs 8k, and much larger games - often starting at 1MB).

Future work

Many things could be done (contribs welcome ! ) to further development :

• Some graphical glitches on games (or frankly ugly artifacts), yes, they exist.
• Sound has been neglected, ie should work, has worked, but now doesn't.
• Loading ROMs from SDCard to RAM (64k max cartridges) - or even flash programming from uSD ?
• Saving games states as  SDCard files
• HiDef Scale2x type graphical output ?
• Support of GBC seems doable, maybe in a future release, this would include working around memory limitations and reimplementing color GB features in graphical layer, on the fly loading some pages in RAM from SD to handle large ROMs?
• Maybe adapting this emulator or graphical engine for NES ?

New game published : Fire !

Fire game has been published !

It's a simple game described in a series of tutorials.
The engine is very simple and all code is about

The game runs at 640x480, 4096 colors 60fps. Here is a record of the simulator running under linux.

Code, Graphics by makapuf

To compile it you'll need embedded-gcc and python (image to C scripts)
The .bin file is 136k, available on github (as well as the source & graphics) ; upload to bitbox using SWD interface by example.



The game is currently made for bitbox rev1 (but as all games, will be adapted to rev2).

Quick News

Although there hasn't been many news, development has been continuing behind the scene.