News via http://www.aep-emu.de/PNphpBB2-file-...c-t-17298.html

Marat Fayzullin has ported his (free) Spectrum emulator Speccy to the Android platform: Speccy for Android


Quote:
New in 1.7.3:

1. Fixed audio.

2. Made virtual keyboard transparent.

3. Added on-screen modal buttons to fMSX and Speccy.

4. Made fMSX, Speccy, and ColEm load system ROMs from /sdcard/fMSX, / sdcard/Speccy, and /sdcard/ColEm respectively. ...

News via http://www.codemii.com/2011/07/18/hb...–-week-29-2/

The following applications have been added/updated:

18 July 2011

» Bolt Thrower v0.37 -> v0.59
» DOSBox Wii v1.5 -> v1.6
» LifeMii Wii v1.0
» SaveGame Manager GX r106 -> r108
» VectrexWii v0.2 -> v0.3
» Yabause Wii r2604 beta17 -> r2649 beta18 ...

Pate has updated his Dos Emulator for the Nintendo DS, heres the news:

Sorry it took me over a month to get a new version released. However, this version now has two noteworthy improvements, namely FPU support and the fact that this version is now built with version 0.13beta of the SDK. This version of the SDK has already been released at the end of last year, but I only recently noticed that I still used the even older 0.12beta version to build DS2x86. This might have caused at least some of the audio problems, as the audio features were somewhat improved in SDK v0.13beta. I also decided to jump the version number to 0.20 with this version, to show that it has some major internal changes.

The biggest enhancement is the addition of FPU support. For now this only works in 32-bit protected mode (meaning those DOS4GW games), as those are the games that mostly expect the existence of an FPU. My two test games, X-COM UFO and Destruction Derby, now seem to run the FPU parts fine. The problems I mentioned in the previous blog post were actually both caused by the FPU opcodes, though in some rather interesting ways. It took me almost three days to track down and fix the problems. There is still a rather serious problem in the texture mapping in Destruction Derby, but I am not sure if that has anything to do with the FPU opcodes. In any case, Destruction Derby runs much too slow to be properly playable, so fixing the texture mapping is not a high priority. Fixing it might fix some other games as well, so I do plan to look into it at some point.


Anyways, the FPU problem in Destruction Derby was in the FCOMP (compare) opcode. When I first tested that opcode it seemed to return a correct result, so I spent a lot of time looking elsewhere for the problem. In the end it turned out that I had a small typo in the opcode handler, I had written "sll t4, t3" when I meant "sll t4, t3, 1", and the assembler had interpreted it as "sllv t4, t4, t3". In this case the assembler tried to be a bit too smart, when it replaced the sll opcode (which can only have an immediate shift value) with the sllv opcode (shift by a register value). Since I had forgotten to type the immediate value, it would have been nicer if the assembler had given an error instead. That problem meant that the comparison result was mostly random, it sometimes returned the correct result and sometimes not, somewhat depending on the lowest 5 bits in the registers I wanted to shift left by one bit before the comparison.

A more interesting problem was the one that affected X-COM UFO. It behaved very erratically, dropping to a debugger with an unsupported opcode at random locations, where the opcode should have been supported. That pointed to the interrupt routine failing to execute properly and dropping back to where the interrupt should have happened. It took me a while to notice that when it dropped into the debugger, the Virtual 86 mode flag in the flags registers was set! I had not coded support for interrupts in virtual 86 mode yet, so that was the reason for the weird unsupported opcodes. However, I was pretty sure that the game does not set this flag on purpose, so I added a check into DS2x86 to drop to the debugger immediately after this bit gets set in the CPU flags. After a few test runs, the results were quite interesting. Once the bit did not get set, but DS2x86 dropped into the debugger anyways. In other runs, twice the opcode was fsin, and once fcos, two of my new FPU opcodes.

The interesting part was that I did not touch the CPU flags in the fsin and fcos opcode handlers at all! I did store the register that contained the flags into stack, along with various other registers that calling the GCC math library sin() and cos() functions will globber, and then restored the registers after the call. I could not immediately see anything wrong with my code, so just for fun I copied the flags before the GCC library call to the EAX emulated register and the same flags after restoring them from stack to ECX emulated register, and then added a forced drop to the debugger after the call. And, much to my surprise, the value restored from the stack was completely different to the value I pushed to the stack!

I looked into the dump file for what happens in the GCC library sin() and cos() functions, and noticed that indeed, they destroy the two topmost words of the caller's stack!. I have a very hard time believing this behaviour is by design, this might actually be a bug in the GCC compiler itself. Here below is the dump from the start of the math library sin() function. The input is a 64-bit double value, in 32-bit registers a0 (low word) and a1 (high word).

80250fd0 <__sin>:
80250fd0: 3c027fff lui v0,0x7fff
80250fd4: 3442ffff ori v0,v0,0xffff
80250fd8: 00a23024 and a2,a1,v0
80250fdc: 3c033e50 lui v1,0x3e50
80250fe0: 27bdfda8 addiu sp,sp,-600 // sp -= 600, make room for local variables
80250fe4: 00c3182a slt v1,a2,v1
80250fe8: afbe0250 sw s8,592(sp)
80250fec: afbf0254 sw ra,596(sp)
80250ff0: afb7024c sw s7,588(sp)
80250ff4: afb60248 sw s6,584(sp) ...

News via http://gbatemp.net/t301778-build-your-adventure-v0-1

Build Your Adventure is a new DS homebrew made by King Dodongo. The game is a 3D jump'n'run that features a level editor for building your own custom courses. Join in on the on-going discussion linked below to find out more about this project.



QUOTE(Release Notes 07/17/11)
- first release•This game use save-features, so don't forget to patch the Game with DLDI.
•The levels will be saved in the root of your flashcard as level1.ba1 - level5.ba1
•The controls are displayed on the screen, press START to exit every Menu.


Download Via Comments ... ...

News via http://gbatemp.net/t302296-bang-v1-0

Bang is a Micro LUA DS Homebrew where the user much shoot the target. The longer you play the faster the game goes and the more targets appear. Remember that Micro LUA DS is required to run this Homebrew.

Download Via Comments ... ...

News via http://gbatemp.net/t302301-the-legen...ny-demo-v0-0-1

Play the Ocarina in the Legend of Zelda Symphony Homebrew DEMO. This project is still in the early stages of development, follow its progress via the project post link below.

Download Via Comments ... ...

News via http://gbatemp.net/t302313-ankrace

AnkRace is a new NDS homebrew made by Min. The object of the game is simply to bet on which rubber duck you think will make it through the water course first. For more information visit the project's page linked below.



QUOTE(Controls)
•Left/Right - Select duck / rotate camera
•Up/Down - Control bet size
•A - Confirm
•L/R/L+R - Use with up/down to increase/decrease bet size more rapidly
Download Via Comments ... ...

News via http://gbatemp.net/t302427-earthshakerds-07-21-2011

ant512 has released version 20110721 of EarthShakerDS, a port of the classic Boulderdash style Sinclair ZX Spectrum game. This update mainly consists of bug-fixes. For the full story about this DS homebrew project, join in the on-going discussion via the link below.



QUOTE(Change Log 07/21/11)
•bugfixes


Download Via Comments ... ...

News via http://gbatemp.net/t302537-woopsigfx-1-4

WoopsiGfx is a C++ 2D graphic library for the NDS. The developer of this project has announced that he is leaving the DS scene for good. There may not be to many more updates to this project. Please see the change log for more information about the v1.4 update. Check the links below to read more about Woopsi and its developer.



QUOTE(Change Log)
•Animation:lay() stops if there are no frames to play.
•Animation::getCurrentFrame() returns NULL if there are no frames.
•Animation::getCurrentBitmap() returns NULL if there are no bitmaps.
•StringIterator::moveTo() ignores attempts to move to negative indices.
•Improved use of DMA hardware.
•WoopsiString::subString() passes the correct arguments to the WoopsiString constructor.

Download Via Comments ... ...