All Projects

This is a patch to change brickmania into using a standard menu instead of the bitmap one. The purpose of this is to make it easy to add a Playback Control menu to this plugin in FS#9953. A side benefit is that it will be ever so slightly easier to port brickmania to new targets (you won’t have to come up with new main menu images).

In addition to the attached patch, delete app/plugins/bitmaps/native/brickmania_menu*

Note: for some reason the patch decided to interspace adds and removes in the game_menu function which makes it difficult to read. I recommend applying it and comparing it visually for that portion.

patched against r20108

patched against r20054.

These are a few code cleanups for the goban plugin, including:
- Adding new comments
- Fixing obsolete or incorrect comments
- Getting rid of a few C++ style comments (woops)
- Using memset instead of a for loop
- Getting rid of an obsolete debug print
- etc.

There should be no difference at all to the function of the plugin.

r20030:
When a menu is opened in a plugin, the status bar often does not show itself. In plugins where there is colourful content at the top of the screen, this looks quite ugly because the previous content shows through and clashes with the rest of the menu.

Incomplete list of plugins which exhibit this problem:
- Goban
- Mazezam
- Sokoban (doesn’t look bad, but the status bar doesn’t draw)
- Wormlet

It is the most noticeable in Wormlet and Goban

Steps to reproduce:
1) Start the device and load the Wormlet plugin
2) Select “Play Wormlet!” from the menu.
3) Open the menu again (power button on e200).
4) Notice that the blue background shows through where the status bar should be.

Note: you may have to repeat steps 2-3 several times for the bug to appear, but it is at least 1/2 of the time on my e200. Sometimes the status bar will draw itself after a delay (seems to be different each time), and sometimes it will never draw no matter how long I wait.

The bug is evident in the e200 simulator as well, and in other devices’ simulators, but it appears to happen less often (you may have to repeat steps 2-3 above a few more times than on the device).

Tested with default settings with the r20030 build downloaded from the website (not built myself).

This is an attempt to turn the goban plugin into an overlay for the recorder and ondio targets (where the plugin buffer is too small for it to run normally).

goban-overlay.patch is the actual patch.
To run it in test mode apply turn-on-testing.patch IN ADDITION to the other patch, and unzip test_sgfs.zip to your player root.

You have to watch the screen a little bit for the test suite, as the result is only reported there (it will clearly say if it passed or failed).

Here are the initial button maps for the following targets (for the Goban plugin):
- Sansa Fuze
- Sansa Clip
- Sansa m200
- Creative ZV
- Creative ZVM
- Phillips HDD1630

I also included the required changes to the manual for the Sansa players. The other targets don’t appear to even have the start of a manual and are completely new keymaps, so I couldn’t do much (I’ll make those changes when those manuals get started).

svn revision: r19908

Several of the release tools (tools/release/bins.pl, tools/release/manuals.pl, and tools/release/voices.pl) are using the system ‘echo -e’ command. ‘echo -e’ is not portable and is broken on my system (kubuntu 8.10 amd64) which means that these scripts fail. Here is a patch to fix it, by using a pipe and perl’s own printf command instead.

Note: My system’s echo command actually supports -e, but perl seems to use sh for running system commands and backticks and sh has its own built in lame version of echo. This makes it all the more confusing when you try to debug it.

I’m not even sure that this is a bug, it may be something I’m doing wrong or a misunderstanding on my part. But regardless, here it is:

This was tested from subversion revision r19442.

When making a new multi-file plugin, I can’t just copy the structure of the sudoku.make file from the sudoku plugin. These extra lines are needed at the end of the .make for some unknown reason:

$(call PRINTS,LD $(@F))
$(SILENT)$(CC) $(PLUGINFLAGS) -o $*.elf \
	$(filter %.o, $^) \
	$(filter %.a, $^) \
	-lgcc $(PLUGINLDFLAGS)

ifdef SIMVER

$(SILENT)cp $*.elf $@

else

$(SILENT)$(OC) -O binary $*.elf $@

endif

If this blob is not present, then the plugin does not get linked or built into a .rock. (there is no error message, it just builds the object files for the plugin and fails to do anything else with them. No .rock file is made for the plugin.).

Attached is a patch containing an extremely simple plugin, named goban, that exhibits this behavior (it is basically a copy of the helloworld plugin made into a multi-file style plugin for demonstration). It appears to me that it should be doing everything necessary to be built as a plugin, but it doesn’t work. Notice that the goban.make has exactly the same structure as sudoku’s sudoku.make file, and yet sudoku correctly becomes a .rock plugin while this test plugin does not.

By the way, the extra blob above was found in reversi’s makefile.

Steps to reproduce:
1) Apply the attached patch
2) Build rockbox (I tested with e200 normal and simulator)
3) make zip and extract it
4) Notice that there exists no goban.rock file in .rockbox/rocks/games/
5) View apps/plugins/sudoku/sudoku.make and compare it with apps/plugins/goban/goban.make. Notice that the structure is identical and yet one works correctly while the other fails silently. This makes it very treacherous to start new multi-file plugins by copying the structure of existing plugins.

In lines 477-481 of firmware/usbstack/usb_core.c (noticed in r16521) there is a possible bug. I’d make a patch but I don’t know the correct fix.

The relevant text is:

          if (req->wValue)
              usb_drv_stall(req->wIndex & 0xf, false,(req->wIndex & 0x80) !=0);
          else
              usb_drv_stall(req->wIndex & 0xf, false,(req->wIndex & 0x80) !=0);
          ack_control(req);

This is basically if(something) do_x(); else do_x(); do_y();
Very confusing at best.

I mentioned this in irc, but nobody seemed to notice. Sorry if someone is already looking into it.

This patch adds the sgfbox plugin, a game recorder and viewer for Go/Igo/Weiqi/Baduk. It saves and views SGF ( http://senseis.xmp.net/?SmartGameFormat) files which are pretty much standard in the Go world.

It was developed and tested ONLY on a sansa e280, and there is no specific handling of any other platforms. In particular the button mapping is specific to the e200, and I doubt it will work well on other players (comments on what keys will work well one what players are welcome).

If you don’t know what Go is, try here: http://senseis.xmp.net/?Go

I did not include any SGF files with this patch, but you can easily find some on the internet. Here are some random ones if you’re lazy:
http://www.andromeda.com/people/ddyer/age-summer-94/companion.html

The bulk of this patch is ports of needed parts of GNU Go (libsgf and libboard). GNU Go is released under GPL, so there should be no issues with licensing.

Release notes:

This plugin is very much a work in progress and is /not/ ready for SVN inclusion. The porting of GNU Go code was done very sloppily and should probably be redone. A lot of code/data that isn’t being used is probably included in the ported parts, making this plugin use up almost all of the 512 KB available on most ports. It will definitely not build/run on targets with less than this available for plugins.

- No rigorous testing has been done. It seems rather stable, but

I would not be at all surprised if there are huge crashes and
file corruption bugs.  Don't depend on this to record games that
you care about, and don't come crying if it magically crashes your
player, deletes all your music, and burns your house down.

- Game results are not handled in any way (neither read nor written)
- Game comments and board marks are not handled
- Player and place information is not output
- The plugin reads and writes files to / for now.
- The plugin assumes that /default.sgf is an SGF file that it can use

to store the current game state if no other file is specified

- It has only been used/tested on a sansa e280
- The controls are almost certainly not going to work well on any

other player, but I really have no idea what will.

- It assumes that you have a color bitmap display, which shouldn’t be

necessary

- The code is really ugly and probably breaks every guideline. If

you are brave, the main plugin code is in sgfbox.c, the rest being
mainly ports of GNU Go code.  The malloc code seems to be in public
domain.

This plugin could be slimmed down quite a bit, but it’s never going to be small. A board library for Go is fundamentally a non-trivial problem, if you want to be able to undo moves in a timely fashion, for several reasons including:
- One move can change a large portion of the board and you have to either keep track of what changed, or replay through the whole game from the beginning
- Keeping track of strings of stones is really annoying to do efficiently (which is necessary to handle captures)
- There’s a lot of board state that is a little annoying (ko positions, captured stones)

Calling rb→set_int and selecting the maximum value from the list returns garbage results in the integer (once in a while I will get the expected answer, so please try it two or three times before you call me crazy). A simple plugin is included which exhibits this behavior on the simulator as well as on a sansa e280, with svn revision 13728 that I just checked out.

Again to reproduce this, build the plugin, run it and select the maximum value from the list (9).

If I am doing something wrong, please let me know but I don't see what it could be.