Recent commits : a month in bitbox

Hi all !

Here are some news about the recent commits of the bitbox engines, kernels and other bits since last month. You can look at the git history to find them

New Game : Boulder Dash clone

Why, yes a clone of boulder dash was one of the simple games I wanted to implement.

It's not completely finished (missing new sounds, levels, and ennemies), but the main elements are here in their 640x480 glory, inc. sound&music, basic gameplay, intro screen

Here is the repository (including a binary release for eager testers :)

Everything in the game is tile-based, and the whole game data is in fact just a uint8_t[] array of tile references, with its small finite state machine. The main and only .c file is 380 lines- not that I am so proud of it, it grew quite organically, but eh : now is better than never.

Demo (click on it to see fullscreen)

Presenting bitbox at "le capitole du libre" in Toulouse

I was kindly invited to present the bitbox as part of the "Capitole du libre" meeting, where I presented the hardware and software conception during a nealy one hour talk with many interesting questions after. The project has found a few very welcome new enthusiasts !

It really was a pleasure to discuss with everyone there, working on free / opensource games, awesome operating systems or nice little games that beg to be implemented on the bitbox ...

That, and many interesting more general conferences about opensource or blender (yay). The slides are in french, but I plan to include them

The big problem is that it entails so many new ideas and directions that my sleep deprivation will not be much better for another year I guess ...

Simple modes

Some have expressed the interest for simple modes for the Bitbox. An recent commit is providing such mode , on top of the standard kernel.

The so-called simple modes are called like this because they provide a frame buffer interface, so the application programmer will only have to write bits and bytes to the video memory - much like it's done on PC. So the interface is a vram buch of memory and a color palette (because the tradeoff is a reduced palette or resolution)

There are two examples in the bitbox SDK (one of them below), but generally you'll need to define a simple makefile variable VGA_SIMPLE_MODE=X with the given mode and include the bitbox.mk standard makefile.

(Yes it's currently defined at compile time - if your program needs to switch between two modes at runtime, it might be time to switch to a standard kernel / engine - it's not difficult !)

New kernel modes (including 800x600@56Hz !)

Since a recent commit, developers now have a better way to set modes.

The kconf.h kernel configuration file allows now several modes, selectable through your project Makefile config options.

Current defined timings include  :

- 640x480, 60Hz @ 168MHz clock (default one), 7 clocks per pixel
- 320x480, 60Hz @ 168MHz clock (repeat each line twice to use as 320x240 display)
- 640x480, 60Hz, overclocked at 192 MHZ,  7 clocks per pixel (longer vsync time)
- 800x600, 56Hz ! overclocked a bit at 180MHz. Yes the bitbox can do 800x600, 56fps.
You only have 5 clocks per pixels here however, so you'd better optimize that blit loop.

other modes can be created by adding config lines to the kconf.h file, all timing computation is based on number of pixels for Porch begin/end/sync and display sizes in pixels ; however be sure to get the right clock ratios to run USB/SDIO clocks at 48MHz !

yes, testkernel can work at 800x600 (sorry bad pic)

Beat Blocks beats hit Bitbox !

New program ! A Beat Box project on the Bitbox. Used to make rhythms with drums samples, you know.

It sports 8 tracks with two possible instruments on each of them (16 different instruments max), looped on a 16 beats track.

It is controlled by a USB gamepad or a keyboard, and can be used live (ie changing patterns or editing them)

It works by playing and modifying patterns on a mod file on the SD card (samples can be bigger than the bitbox memory), so you can create drumkits quite easily with a Tracker and play/modify it on the bitbox.

Of course, it's free and open sourced ! See sources and graphics on GitHub

"I love playing. The keyboard is my journal."

Well, now we can join Pharrell Williams and play the Bitbox with an USB Keyboard since commit 3a983ff

The USB code can now read USB keyboard and produce events, and a small function has been added to emulate the gamepad with a keyboard, so to get basic keyboard support you need to add one line in games. Or just check for the events yourself.

Keyboard can be read from an application by using the event_get() function , which returns a (possibly empty) event, check for e.type = evt_keyboard_press or evt_keyboard_release events, and then get the modifiers (Control, Shift...) state in e.kbd.mod and the keyboard code e.kbd.key bytes.

The code themselves are position-dependent, not letter-dependant (by example on a QWERTY keyboard the Q letter has the same code than the AZERTY 'A' letter, thanks to the USB norm for that), so if you want to type some text, use the appropriate translating tables. (there are two key maps available on the kernel for now, QWERTY and AZERTY).

All key codes ("Usages") can be found on the HID Usage Tables, Usage Page 7.

All of it is defined in the bitbox.h file.

The bootloader 2 has been upgraded with it, by additionally displaying the last key pressed or released on screen. Also, the examples now include keyboard usage.

developing for bitbox under windows

Even if I'm personally working under linux, it is quite possible to develop for bitbox under windows.

The following article / page is a reference for it, and will be updated accordingly. Also, if there is any part missing, please tell it !

A very thorough reference can be found by example there : http://www.jann.cc/2013/10/10/embedded_development_with_open_source_tools_on_windows.html#install-the-gcc-arm-embedded-toolchain

Most of the current guide is taken from there.

It targets development on a cortex-m4 chip so it's quite similar and adds a ton of optional software which can be very useful. The proposed method is quite barebones (or light), because, well I tend to prefer lighter solutions, but integration with eclipse could be done I'm sure.

Alternatively, DIYDSP has an page with instructions to setup a linux virtual machine suitable for stm32 development, as well as various other tips.

Bitboy gameboy emulator ported on rev2 hw

Hi, just to tell you that the Bitboy gameboy emulator - based on gnuboy - has been ported on the rev2 bitbox ! Download available through the bitboy github page

Works with USB gamepads and can be loaded by the bootloader of course, sound works OK with the emulator and the real thing.

Bitbox Mod player !

A MOD file (tracker files for those remembering them) player is available and can be used for streaming mods from the SD card (with minimal impact on RAM & Flash)

Of course it is integrated to the bitbox kernel (latest one), so that games will be able to make use of it ; it can be loaded with the bootloader - and the bootloader is available when you press reset+userbutton.

See the video for the demo hereafter (sound has been taken by my phone from the speakers so it's better in reality)

Demo of the bootloader

Just a simple demo of the current bitbox bootloader, selecting a flash image with VGA and the game controller, and running the simple engine demo available on github.

rev2 Bitboxes available ! (how to get your gamepad supported)

I dunno if you've seen it, but the Bitbox is now available to buy (look at "get Bitbox" on the blog top banner).

Since people have already ordered a Bitbox, they will need their USB game pad to work. Here is how your device can be supported on the Bitbox. As I cannot buy every gamepad on earth, I will rely on you to provide information to me so that I can add the various gamepads to the firmware.

The process is the following :

• you open a ticket case on the github account, stating a "nice to have" support for joystick XYZ
• you include your model name, VID, PID and USB report descriptor attachments. To get them under linux, you can use the following method:  http://www.slashdev.ca/2010/05/08/get-usb-report-descriptor-with-linux/ please leave a comment if you would like a windows tutorial.
• I add the right values in the firmware to be able to support it
• You test it with your gamepad (using the kernel test application by example) and report if it is ok.
• I can close the ticket !

Please comment here or on the mailing list if you have any trouble !

Playing TitanFall and Super Mario 3D World on the bitbox

 Well, playing a video of Titanfall on a Bitbox, of course playing a demanding PC / nextgen console videogame is out of reach :) But OK, then, can we have video on the bitbox ?

Full motion video on a very small hardware like the bitbox poses some interesting optimization issues and challenges. That's the kind of challenges you're faced with when you've got a few k on RAM - too few to store the image you're showing entirely- and 180MHz to generate the content and synthetise you VGA signal by software ...

Can we made nice cinematic cutscenes for the game, i.e. full motion video on the bitbox ? Can we make it 4K 3D video ? Well, no (What did you think ? 1080p50 with an Arduino ?)

But ... how far can we go ?

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.