OpenHandhelds.org

Here is a minesweeper game that I've made for the a320.


The controls are:
- The D-Pad moves the cursor.
- A uncovers a tile.
- B marks a tile.
- Select takes a screenshot.
- Start exits.

The playable game is available here: http://flatmush.juliusparishy.com/a320/MineSweeper_Release_110.zip
The source code is available here: http://flatmush.juliusparishy.com/a320/MineSweeper_Source_110.zip

This is probably more use as an example of how to make applications without using the s2dsdk, it contains enough functions to get anybody started in a320 programming without all the useless bloated sdk code.

Edit: If you downloaded before 02:19 17/05/2009 GMT then re-download since the level 4 crash bug is now fixed, was due to my rand function not being random enough.
Edit: Updated to version 1.1.0 at 23:00 17/05/2009 GMT

Great, thanks a lot for starting point. Few comments/questions:

Is the game busy loooping? Is there some way to sleep (wait for event or timer to expire) so it doesn't eat battery so quickly? What _sys_judge_event(NULL) is supposed to do?

Whas is the point of extra game buffer pointer? Did you see any difference when writing directly? LCD controller has its own memory so IMO the buffer received by _lcd_get_frame() should be already safe for direct writing. And anyway from the flip,get,set procedure it looks like maybe it is already some shadow buffer which gets copied somewhere else (set) and then transferred to LCD controller (flip).

It also looks like the buffer received by _lcd_get_frame() is already in non-native 320x240 so there is diagonal tearing when updating the screen

And btw, in minesweeper display_flip() the size set by
uint32_t* tempDispEnd = (uint32_t*)((uintptr_t)tempDispBuff + (display_width * display_height * 2));
may be in fact 2 or 4 times bigger due to *2 (depends on sizeof(uint), should be /2?)

_sys_judge_event() is like the calls in <signal.h>, it detects requests for the program to terminate, that'w what allows the program to automatically exit when you plug in usb, I don't know how to stop the program busy looping though yet.

The _lcd_get_frame isn't the LCD's internal framebuffer, it's just the buffer that the lcd copies from. If you don't use two buffers then you will end up overwriting the buffer while the lcd is updating which leads to very bad artifacts like only the top 5 or so lines updating. I messed around for ages to work out how that was meant to be done, so trust me this is what you do, look at Loader.cpp and you will see that their old code did it.

Yes, the screen is set to receive data at 320x240, but I haven't noticed any really bad tearing, though flashing screens do cause it.

The pointer arithmetic in display_flip is correct though confusing, all that code does is performs a fast memcpy. The code basically sets the start pointer to the address of the display, and the end pointer to the address of the display plus its size which is (320 * 240 * 2) because it is a 16-bit frame-buffer, if it were writing past the end of the display then it would cause a segfault (I tried). I can see why you are confused but since the arithmetic is done as integers and then converted to a uint32_t pointer, it isn't multiplied by 4 as an array offset would be.

Ed has set up a dingoo archive which will eventually be part of the main page here (you will see what's new when you visit the main page).

http://dl.openhandhelds.org/cgi-bin/dingoo.cgi

You should be able to upload to that, we should try to get all the software on to it so people have a central place to get it.

craig, can we already upload our dingoo stuff to it ? cause it seems it seems there are still some little quirks here and there (like images not showing up, saying wiz archive etc). Just checking before i upload my games.

edit: uploaded them anyway

I found out how to stop it busy looping, in entry.a there is a function from micro c/os-ii:
void OSTimeDly(uint16_t ticks);

This causes the task to be rescheduled, unfortunately the wise folks at dingoo didn't include OSSetTicksPerSec function to calculate the tick rate. I know the OSTimeDly works but I'll have to figure out the tick rate, but I should have that later today when I get round to it.

Edit: I found the information for Micro C/OS-II functions at:
http://www.rabbit.com/documentation/docs/modules/ucos2/
http://instruct1.cit.cornell.edu/course ... -Color.pdf
There are 64 ticks per second, for the operating system tick counter.

Yep it's cool to upload, those image and faults should be fixed today.

I thought this is a bug. Why should game exit when you attach charger? I've lost progress in "7 days" because I feared the battery might go flat and attached charger and poof

hmmm, will test. You mean lcd_flip() or lcd_set_data() is asynchronous (starts DMA) and you will overwrite previous frame when drawing into next one? then I don't understand why there are 2 operations needed (lcd_set_data and lcd_flip), what do they do then?

It is clearly visible even in the HelloWorld when pressing buttons.

hmm, I thought "(uintptr_t)tempDispBuff" is pointer, not integer, so you add constant to pointer, nevermind, will test

Not on mine, it was only visible when flashing the screen very rapidly, do you have a white a320 with the slower memory cause that could cause a big difference in the screens update rate, mine is a black one.


Nope uintptr_t is an integer type in the c99 standard defined to be big enough to hold a pointer, you can see if you look in the lib folder that contains the standard library that I've been writing for it since the mipstools libs don't compile correctly.


I don't honestly know what lcd_flip does, I tried to use it in various situations but it seemed to have no effect, judging by half the functions in the "Loader.cpp" that comes with the sdk, it's quite probable that it actually does nothing.

I'm not certain that lcd_flip is "void lcd_flip()", it never crashed when I called it like that, but since I never got it to work and I don't know the mips calling conventions, I couldn't say, I'll try to edit anything I have left around defining it.

Black one too, got it few days ago. I see it clearly when pushing buttons in helloworld and screen color changes. Also I see it clearly on boot logo or even in builtin file manager when launching stuff when moving one line up/down. That light blue selected line is always torn somewhere when moving it.


My bad then. Didn't check. Pretty confusing type name.

From the name I guessed it would flip between two buffers automatically so next lcd_get_data() would give you another frame which is free to write but I guess I was wrong. EDIT: Just tried to remove it from hello world and it still works. Removing _lcd_set_data breaks it.

I've uploaded a new version, with some new library code. The game plays identically, however it no longer busy loops and there is the code for the beginnings of a libgcc so that unsupported types like uint64_t can be used (and eventually floats).
I should probably turn this into a proper sdk and make it a community project at some point.

Anyways the new files can be found here:
http://flatmush.juliusparishy.com/a320/MineSweeper_Release_110.zip
http://flatmush.juliusparishy.com/a320/MineSweeper_Source_110.zip