Rockbox

New version changes the screen option for small screen targets. Now you can choose from scaled, scaled (aspect mode retained), and unscaled. By default, it’s scaled.

   rockboy2.patch (6.5 KiB)

Tested on my H10 and works well except for a bug where changing the Screen Options makes it abort if the /.rockbox/rockboy/options file doesn’t exits. Steps to reproduce:

1. Make sure /.rockbox/rockboy/ doesn’t exist
2. Load a GB rom
3. Go to the menu→options→screen options and change it to “Scaled - Maintain Ratio” 4. Back out of the menu
5. Get a splash about invalid opcode… (it’s too quick to see properly)

After further testing, it looks like it might not be dependent on the presence of the file but on it being the first time saving to it. Also, I wasn’t able to reproduce it on my Sansa so it looks like it’s a new problem introduced by this patch (possibly only affecting smaller screen targets?)

Hmm, Barry I can’t reproduce your issue on the sim. I’ll toy around for a bit to see if I can get the same crash.

Well, on the nano sim I can get crash by setting the screen to unscaled and then going back into the game, then returning to the menu. Hurray segmentation faults!

This version centers the image on all targets regardless of scaling mode. Still haven’t fixed the unscaled mode issue on smaller screen targets, it has to do with rockboy writing beyond the framebuffer. I haven’t decided the best way to deal with it.

   rockboy3.patch (6.8 KiB)

This should fix the unscaled mode freezes. Enjoy.

   rockboy4.patch (7.9 KiB)

The fixes you made work great.
Unfortunately, I am still experiencing the problem I mentioned previously. I’ve done some further investigation and found that it is not related to the presence of the options file after all (I can cause the crash both when the file is present and not present). Rather, I now think that it only happens the first time Rockboy is run after powering my H10 on. Steps to reproduce are:

1. Power on H10
2. Load gb rom
3. Enter options menu and change an option
4. Back out of menu
5. Get a splash saying “invalid opcode 0x1FDE274 at address 0×0924, rombank = 33106944” 6. Plugin exits

If try to load the same rom again, everything works perfectly and I am unable to cause the crash. I can only cause the crash again by powering off and back on again. I also tested with a different ROM and get the exact same symptoms and error message, including the exact same numbers.

I’ve tried to reproduce this problem on my Sansa and in the H10 simulator, but I haven’t managed to do so yet. I can cause the crash 100% of the time on my actual H10 though.

I’ve included my rockboy.map file here in case it is of any help. I’ve tracked the error message down to the cpu_emulate function in cpu.c. It’s clear from that that the opcode is very very wrong. Also notice that errormsg is at 0x1FDE274 according to rockboy.map. Not sure how much help that is.

My guess is that somehow the PC is getting moved to an invalid address when exiting the menu, but for some reason only the first time Rockboy is run after powering on. Could there be an uninitialized variable somewhere? It’s just a guess though.

   rockboy.map (44.6 KiB)

Newest version:

!) Supports changing palettes for Game Boy ROMS. Presets only and you can’t save a specific palette per ROM yet.
2) Change all tabs to space.
3) Remove a bunch of unused code, variables, and garbage.
4) Minor reshuffling of IRAM (No idea whether this causes the emu to speed up or slow down, I think its slightly faster).

Let me know if I broke anything. The bulk of the patch is the whitespace changes. Still no word on the H10 bug.

PS: For people not following along the bug doesn’t occur on the Nano or X5. So far it’s only the H10 20GB, no word on the 5/6 GB.

   rockboy_clean.diff (234.5 KiB)

There was a report on IRC last night of the bug not being present on a H10 5GB. Maybe it’s just me that’s having the problem. Is there anyone else who can report if the problem is present on their H10 20GB?

rockboy_clean.diff doesn’t change apps/plugins/SUBDIRS to have it include all targets that have an LCD screen. Easy fix on the patcher’s end, but it shouldn’t be too hard to add to the patch either.

More removing of unneeded code and variables.
Also added some of the changes found in the short-lived gnuboy CVS.
A few more whitespace changes.
Change C++ comments to C comments.

On my test roms, this version seems just barely (1 or 2 fps) faster than SVN.

(SUBDIRS change is included)

   rockboy_clean2.patch (239.6 KiB)

The patch applies cleanly, but when I try to compile, I get this error:
make[3]: * No rule to make target `palette-presets.h’, needed by `/home/user/rockbox-20070131/h10-build/apps/plugins/rockboy/lcd.o’. Stop.
make[2]: * [rockboy] Error 2

oops, add palette_presets.h to the patch

   rockboy_clean3.patch (247.6 KiB)

it would be great to have ability to slide screen in unscaled mode, cos the text couldn’t be shown peroperly

does not patch cleanly aginst svn:HEAD (rejects attached) applied manually and testing.

   loader.c.rej (11 KiB)

appears to work but all I have is a test ROM (not a real rom just an free legal to have rom)

1) Disable writing to the RTC every cycle since it’s not implemented.
2) Let’s not write and read sound when sound is off.
3) Include some changes found in WAC gnuboy CE
4) Include sound fixes from the old gnuboy CVS that I forgot in last patch
5) Clean up dynarec code to make it resemble the rest of the rockboy code
6) Completely remove all remaining C++ style comments
7) Have each opcode in dynarec write debugging info
8) Add s to all unimplemented opcodes
9) Add in a few unimplemented opcodes (although my work is probably wrong)

Hopefully the cleaned up dynarec.c inspires someone to pick up work on dynarec. Rockboy with sound is slightly faster than before and with sound disabled I’m getting about a 5-10% speed up (especially when few sprites are on screen and there isn’t much motion).

   rockboy_clean4.diff (343.8 KiB)

I just tried this patch against current SVN. It applies fine, but compiling for H10 fails. Do I need to apply one of the earlier patches first?

Hmm, some of my changes didn’t make it into that patch. This one should fix it (I hope).

   rockboy_clean5.diff (346.7 KiB)

Why don’t you make rockboy run on the COP, it would be a great speedup.

I currently don’t have an iPod or any other PortalPlayer target, so I have no way of testing code with the COP. Someone who’s interested could take a look at the iBoy code that has a arm7tdmi assembler core and some basic implementation of the COP. Looking at their code, it appears to have undergone a great deal of changes and a lot of it I don’t completely understand. Much of it looks like GBC support was stripped out and then readded and looks messier than our implementation (although I don’t like the random asm sprinkled throughout our code, who wants to move those to .s files?)

For Coldfire targets (iriver H100, H300 and iAudio X5) the framework of dynarec is already in place and I cleaned it up a lot. Currently, it will disassemble the rom and write the disassembly to a file. It is missing about 130 opcodes out of the 256 possible operations. Much of this code is repeated so its less code than it sounds.

Unfortunately, the dynarec code seems way over my head and I am probably not the best person to work on it. Someone like jhMikeS, preglow, or amiconn would probably much more comfortable considering how familiar they are with m68k asm. I have tried to implement a few more opcodes but I may be writing them wrong. This dynarec code won’t be useful for any PortalPlayer targets.

I don’t know much about code or anything but I thought it might be good to know that rockboy_clean5.diff has erreors and doesn’t patch correctly in current svn.
The error is with ../plugins/rockboy/loader.o
hope this will be of some help!

Yah, oops I’m not doing so well on the patch creation front. Here you go:

   rockboy_oops.diff (346.7 KiB)

Exact same problem!

Make sure you have the most recent version of SVN. I just patched and built the recorder, h100, h300, nano, and h10 builds fine.