DCEmu Featured News Articles

Newly released for Pandora

The package contains SD card ready PNDs and fact sheets for the following emulators:

Dega 1.16-4 (SMS)
DOSBox 0.74 (PC)
GnGeo 0.8.3 (Neo Geo)
GnuBoy 1.0.5 (GBC)
gpfce 0.4 (NES)
gpfce-gp2x 0.4 (NES)
gpSP (GBA)
Handy 0.5b (Atari Lynx)
HuGo 1.1.0 (PC Engine)
MAME4ALL 2.5b7 (Arcade)
Mednafen r2 (Neo Geo Pocket/PC Engine/Others)
Mupen64plus R1B5+ (N64)
PCSX-ReARMed r8 (PSX)
Picodrive 1.80 (SMD)
PocketSNES 6.5.0 (SNES)
RACE 1.0b3 (Neo Geo Pocket)
Snes9x4P v20110310 (SNES)
UAE4ALL v1.1.1.19 (Amiga)

Thanks to all authors for the hard work.

Version 0.2 : DOSBox 0.74 (PC) added
Version 0.3 : UAE4ALL v1.1.1.19 (Amiga) added
Version 0.4 : Mednafen r1 (PC Engine) added + fact sheets updated
Version 0.5 : Mednafen r2 (Neo Geo Pocket) added + fact sheet quick ref added

http://dl.openhandhelds.org/cgi-bin/...?0,0,0,0,5,404 ...

Newly released for Dingoo:

chip-8 emulator for dingux, original author : garzul

http://dl.openhandhelds.org/cgi-bin/...0,0,0,0,73,510 ...

Newly released for Dingoo:

Final (I guess, all fixed) version of my HHexen port, featuring: sound and music, save autonaming. adjusted menus, improved controls, screen scaling and lots of speedups.
What's updated?
-> Aiming
-> Default controls
-> Config/save folder altered from ./ to ~/.hhexen/ (Now uses the home directory)
-> Screen Scaling (Activated on the "more...' section of the options)
-> Source code!

Be happy!

http://dl.openhandhelds.org/cgi-bin/...0,0,0,0,30,509 ...

Newly released for Caanoo

The package contains the following SD card ready emulators and fact sheets:

CPS2Emu v8 (CPS2)
DrSMS v2 (SMS)
Ginge 1.0 r4 (GP2X)
GnGeo 0.7 (Neo Geo)
gpfce 0.4+ (NES)
gpSP v0.9.2 (GBA)
HuGo v1.1.0 (PCE)
MAME4ALL 2.6 (Arcade)
NeoCD2x 1.0a (Neo Geo CD)
OhBoy 1.0.0 (GBC)
PCSX4ALL 2.0 (PSX)
PicoDrive 1.8.0 (SMD)
PocketSNES 7.2.0qf (SNES)
ScummVM 1.2.1 (Classic Adv Games)
Snes9x4C v20101227 (SNES)
Temper Wiz 0.75 with Ginge (PCE)

Thanks to all authors for the hard work.

Version 0.2 : Fact sheets updated
Version 0.3 : DrSMS updated + fact sheet corrections + quick ref added

http://dl.openhandhelds.org/cgi-bin/...?0,0,0,0,5,696 ...

Newly released for Wiz, Caanoo and Pandora

A game by Colombian Developers.
Gp2x Wiz / Caanoo & Pandora port by GECA soft.

http://dl.openhandhelds.org/cgi-bin/...?0,0,0,0,3,543 ...

Newly released for Wiz

An unfinished, but fully playable port of the legendary indie platformer

http://dl.openhandhelds.org/cgi-bin/...?0,0,0,0,3,543 ...

News via http://dsx86.patrickaalto.com/DSblog.html

For the past week I have been working on the new audio system for DS2x86. As I mentioned in the previous blog post, the code was mostly done by last Sunday, but the problem was that it sounded very bad and also seemed to cause the games to hang much more frequently than with the old audio code. The current status is that the new code is in use, and works at least as well (if not better) in the games that had audio also with the old code. The new code also has ADPCM audio supported, and it works fine in Warcraft, when the original code either failed to initialize or caused the game to crash very often.

I have been using four different games to test the new audio code, as each of these games use somewhat different SoundBlaster audio features:

Supaplex uses the plain simple DMA transfers, playing one digitized sample at a time. The samples have varying sample rates.
Doom uses auto-initialize DMA method, with a 1024-sample buffer but with an IRQ request after every 128 samples. The playing rate is 11kHz.
Warcraft uses auto-initialize DMA with 2048-sample buffer and IRQ request every 1024 samples, with 11kHz sample rate.
Duke Nukem 2 uses various ADPCM sample formats with simple DMA transfers, and with varying sample rates.

I am using 22050Hz audio playing rate in DS2x86. In the original audio code I had initialized the DSTwo audio transfers to 3*128 samples per transfer (with the ds2io_initb() call), as that was the closest I could get to be able to send a new audio buffer within my 60Hz main emulation timer handler. That number was derived from the fact that I would need to send 367.5 (= 22050/60) new samples during each 60Hz timer interval, and the need of the transfer size to be divisible by 128. Using the 60Hz timer for this also meant that I could not emulate an SB IRQ faster than at 60Hz (which again corresponds to 367.5 samples at 22050Hz). For example Doom wanted to get an SB IRQ after every 128 samples have been played. As Doom played the audio at 11kHz (which is very close to half the 22050Hz playing rate I use), I should have generated an SB IRQ after every 256 output samples, or at 85Hz (= 11000/128). To make the audio in Doom work, I had coded a special hack into my audio code where I slowed down the sample rate if a game wants SB IRQs faster than my code could provide them. Obviously this was not a proper solution, so in my new audio code I wanted to handle this situation better.

The basic idea of my new audio code is that the emulation interrupt runs at 4*60Hz (240Hz) and calls the screen and keyboard handling only during every fouth interrupt. The audio emulation is handled at 240Hz, which should be fast enough for any SB IRQ frequency a game would need. By last Sunday I had implemented this new audio code, using 128 samples per transfer in ds2io_initb(), with a separate 1024-sample ring buffer that is filled in the 240Hz interrupt. Since 22050/240 = 91.875, I had designed the ring buffer filling algorithm so that it tried to fill the buffer with approximately 96 samples in each 240Hz interrupt, with the actual amount adjusted by the number of DSTwo IO/ layer audio buffers in use. Since the DSTwo I/O layer has 4 audio buffers, I calculated the needed new samples as 128-ds2_checkAudiobuff()*32. And in every interrupt where the ring buffer had >=128 samples, I sent the buffer to the DSTwo I/O layer.

I thought this code was much better than the original one, however there were several problems that took me pretty much the whole of last week to fix:

Doom had a weird looping/stuttering problem, where parts of the audio kept repeating.
The audio had a horrible constant warble, regardless of what audio was playing.
All games (playing audio) kept hanging within a minute or two of playing them.

I first debugged the behaviour in Doom, as that was one of the main problematic games I tried to fix with the new code. At last I found that the problem was in how the timer and SB IRQs interract in the Doom code. For some peculiar reason, Doom does not fill the 1024-sample DMA buffer during the SB IRQ, but instead in the timer IRQ. And with my new 240Hz maximum SB IRQ frequency, when the DSTwo audio buffers were empty, Doom could get two SB IRQs with no timer IRQ in between, and thus it skipped one 128-sample block in the DMA buffer, which in turn caused that block to play some old data that was in the buffer. I fixed this problem by fine-tuning the amount by which I fill the ring buffer, and never continuing to fill it after it was time to send the SB IRQ to the emulated game.

The second problem with the warbling sound seemed to be simply caused by the 128-sample transfer size. The DSTwo I/O layer does not seem to work very well with anything less than 512-sample transfer sizes. I tested all sizes between 128 and 512, and the 512-sample transfer size sounds best by a wide margin. It would be better to use smaller transfer sizes, as the larger the transfer size the bigger ...

News via http://forums.daedalusx64.com/viewto...t=2640&start=0

DaedalusX64 is the best Nintendo 64 Emulator available exclusively for the PSP. To eliminate some frequently asked questions: No, the Emulator is not perfect, so any graphical bugs, or speed issues are considered normal. Yes, the audio does not always play full speed and can cause the Emulator to crash.

What's changed in this revision:
Revision 717
[=>] Merged from Dev branch:

Rev 302 - Corn
[+] Implemented RumblePak support
[+] RumblePak / MemPak option added to global options (RumblePak shakes screen when active).

Note: Enable RumblePak before booting ROM (also enable clean scene if there is garbage left on screen when shaking)
Rev 303 - Salvy
[!} Separate rumblepak from mempak to avoid any conflicts and keep code tyde
Rev 304 - Salvy
[!] Corrected regression in dynarec from 366 that caused random lock ups in several games
Rev 305 - Salvy
[~] Forgot to revert these in 644


download and give feedback via comments ... ... ...

News via http://www.nintendomax.com/viewtopic...e01e1ee39e3a54

Alekmaul offers version 1.3 and 1.4 of " A5200DS "emulator for the Atari 5200 for Nintendo DS / DSi.





V1.4: 13/06/2011
* Add automatic detection chip for 16k Roma (Goal You Can Change It)
* Button L to display / hide FPS
* Add R & L to change Rom
* Really fix flickering bp alphalerp is back & SCREEN IS smoother
* Better sound (not so much ...)

V1.3: 12/06/2011
* Fix With iEvo bp (it hangs menu)

V1.2: 11/06/2011
* Fix pb with B button (Now You Can Use bombs in HERO)
* Remove argc / argv management (test for Another World With history ievo)
* Fix flickering bp (remove alphalerp for now)

.

download and give feedback via comments ... ... ...