Since I am not doing Settlers of Catan I have decided to pick up Risk and make that on the DS. So far I am messing around with different ideas and I think this is what I am going to go for. Takes just a second to load, the background is 8meg!

This is not playable but just shows the graphical style I am going for. Hit L to zoom in the map, you can use the directions to move around, and you can click on a die to roll it.

I want it later that the map will scroll with the stylus and if you double click anywhere on the map it will zoom in there. I am having a heck of a time trying to convert the unzoomed map coords to the huge back ground coords so if anyone has any ideas on how to do this, feel free to let me know.

-=Etias=-

I worked on this for the last two days and have it at least in a playable fashion. If you don't know what Khet is, here is a description.

It's the game that combines lasers with classic strategy. Players alternate turns moving Egyptian-themed pieces having two, one or no mirrored surfaces. All four types of pieces (pharaoh, obelisk, pyramid and djed column) can either move one square forward, back, left, right, or diagonal, or can stay in the same square and rotate by a quarter twist. Each turn ends by firing one of the lasers built into the board. The laser beam bounces from mirror to mirror; if the beam strikes a non-mirrored surface on any piece, it is immediately removed from play. The ultimate goal is to illuminate your opponent's pharaoh, while shielding yours from harm!

(The red laser shoots out the top left, from the circle there, the grey one from the bottom right. red pieces can't go on the grey squares and grey pieces can't go on the red squares)

This game is being released to get feedback, etc. I will be updating it with more features. As of now, it is only 2 player on the same DS. I hope to add Wifi and computer AI soon. I will also be adding different configurations to play with. There are 3 main ones in Khet but I am also going to make it that players can make their own. I am also looking at redoing the graphics, possibly 3D.

As for now, enjoy the game! This is my FIRST DS game and also my first C/C++ program so please let me know what you think!

v1.1 - 08 Dec 08
--------------------------------------
* Now with customizable game boards! You can make your own game board by alternating turns of placing pieces! Now no two games will ever be the same again!
* Finally added a logo for the game
* Fixed some of the background graphics

Outsourcing contract for development of an NDS application for visually impaired people.

My DS Reader project description:
A homebrew application which will assist blind users to read
ASCII documents stored in their NDS memory card (with future goals to support Word, PDF and direct email connectivity).

The user will interact with the application by means of strokes/gestures with audio feedback.

Language:
UK English

Essential features to be developed:
0) ASCII document parsing
1) text to speech module
2) simple gesture recognition for menu navigation
and audio feedback

Optional
3) parsing of PDF and DOC documents
4) email download and email to voice

Project outcomes:
1) documentation (possibly in UML standard)
2) source and compiled code
3) beta testing
4) support

Project duration:
1 year max for the first beta

Experience sought from candidates:
1) have developed multimedia applications for the NDS (Homebrew experience is welcome)
2) have an engineering or computer science background
3) have developed digital signal processing applications for other
embedded controllers
4) speak fluent English

Payment is flexible:
This is a funded project with partial payment in advance. An NDA will be required.

Contact Info:

[email protected]

Since this is my first post on the blog discussing the dynarec, I’d like to first explain what a dynarec is and why we’re going to need one to accomplish full speed emulation on the Wii. Then I’d like to describe the history of the dynarec in our emulator, where its at now, and what needs to be done to get it working.

First of all, dynarec stands for dynamic recompiler, which is actually a bit of misnomer in the console emulation world: usually its not accomplished by creating an abstract syntax tree or control flow graph from the emulated machine code and running a target machine code compiler over it, which is what recompilation would really entail. The proper term would be binary translation: for each emulated instruction, I convert it to an equivalent target instruction. Since the N64 is a MIPS architecture machine, I take a MIPS instruction, decode it (determine what kind of instruction it is and what operands it operates on), and then generate equivalent PowerPC (GC/Wii use PPC) instructions to perform the operation that the MIPS instruction intends to. What we try to do is take a block of code that needs to be run, and fill out a new block with PowerPC code that was created by converting each of the MIPS instructions in the block. The emulator then runs the block of code as a function: it will return when a different section of code needs to run and the process repeats for the next block of code.

What we’re doing now is running an interpreter: instead of translating the MIPS code we want to run, we just decode each instruction and run a function written in C which performs what the MIPS instruction would do. Though this may seem like less work: we don’t have to translate all the code and then run it; we just run it, but because the code is ran so many times and running the translated code is much faster than running each instruction through the interpreter, the extra time translating is made up for my the faster time running through long loops.

The dynarec was the first thing I started working on with the emulator: it seemed like the most interesting aspect and the most crucial for such a port (besides the graphics which I didn’t understand well enough at the time to do much useful work besides porting a software renderer). It’s gone through a few different stages different stages: 1-to-1 register mapping binary translator, quickly dropped attempt at reworking the translator to be object oriented, slightly further progressed attempt at a MIPS to Scheme translator, and where I’m currently at: the first binary translator without 1-1 register mapping, confirming to the EABI (Embedded Application-Binary Interface).

I was concerned about performance initially, and I got a little greedy: I decided that since both MIPS and PowerPC had 32 general purpose registers, and MIPS has one hardwired to 0, and PowerPC has an extra register (ctr) I could move values into for temporary storage, I could do a simple translation of most of the instructions by using all the same registers as the MIPS would use on the PPC. The idea was that I wouldn’t have to shuffle things in and out of registers; I would load the whole MIPS register set values into the PPC registers, run the recompiled code which would operate on those values, and then when its done with a block, store those values back and restore the emulator’s registers. This was a bad idea for several reasons: small blocks that only fiddled with one or two registers still had every single register stored, loaded, and then stored and loaded again for each block, I had to disable interrupts because I destroyed the stack and environment pointers that were expected if any interrupts were taken, and because I couldn’t take interrupts, it was very difficult to debug because I couldn’t run gdb in the recompiled code. I had developed a pretty large code base and a somewhat working recompiler before I truly came to realize all the drawbacks of the method: it ran some simple hand-crafted demos I had written in MIPS which computed factorial and a few other simple things, but overall it was too unweildy and inefficient to continue to debug.

My attempt at refactoring the code I had written in a OOP way was soon abandoned, but it did inspire some improvement to the way I generated instructions. Instead of piecing together the machine code from all the different parts, I wrote new macros which would do that for me for specific instructions thus reducing some major code clutter in the translator functions.

I was unimpressed by the improvements I predicted I would see by refactoring the code in C++, and inspired by Daeken’s work on IronBabel to start the dynarec from scratch using a high-level language. The idea and the code was much simpler: decode the instructions using high-level magic and instead of generating low-level machine code, generate high-level code to execute each instruction, collect all

Hey wraggster, since you're a reliable source and don't drop off the face of the earth as often as other people, I thought I'd let you in on a bit of info.

I'm just dropping by to let you know that Wii64 / WiiSX now has an official home at www.emulatemii.com, it currently doesn't have much but there is a progress video and a few lengthy posts about progress

It's a website run entirely by the Wii64Team (myself included), plus it will have in-depth updates on the status of the emulator and it's progress.

Enjoy and feel free to post it as news.

OpenTTD CargoDest port for gp2x

- port of CargoDest branch
- GUI changes for 320x240
most big windows are resized to fit, window placement improved
- SDL_mixer music
- compiled with network play support (tested with usb, works
both as client or server, needs corresponding version compiled
on other machine)
- source diff included

Controls:
(No touchscreen, as I don't have a F-200,
get ZodTTD & Senor Quack's excellent port for this!!)

stick: mouse pointer
x,y,a,b: scroll
L: leftmouse button
R: right mouse button
vol-: hide/unhide windows (but don't close)
vol+: switch toolbar
R + vol-: close windows
R + vol+: increase game speed
R + x: send top window to bottom
R + y: send bottom window to top
R + a: clear pointer
R + b: transparency
select: ctrl
start: shift
L + start + stick: move window

Note that you need to put original data files in data/:
sample.cat
trg1r.grf
trgcr.grf
trghr.grf
trgir.grf
trgtr.grf
and music files in gm/

anyway, hope some will enjoy this,cheers!!

Here is a great Atari 520 emulator compiled for the pandora, ready to play with when you'll get a pandora board

Here is a great Atari 520 emulator compiled for the pandora, ready to play with when you'll get a pandora board