This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Welcome, Guest
You have to register before you can post on our site.



» Members: 10,116
» Latest member: blaesttsbl
» Forum threads: 12,573
» Forum posts: 57,268

Full Statistics
  OpenTTD v1.0.0 Released
Posted by: Alastor - 04-03-2010 07:13 PM
1929 Views - No Replies

OpenTTD is an Open Source clone of Transport Tycoon Deluxe.

Changes :
- Fix: Network clients would crash while connecting to a server with AIs (r19526)
- Fix: [NPF] Crash when finding a waypoint before finding the closest depot [FS#3703] (r19460)

Print this item Send this item to a friend

  Ootake v2.35 Released
Posted by: Alastor - 04-03-2010 07:09 PM
3370 Views - 1 Replies

Ootake is a PC Engine (TurboGrafx 16) emulator .

Changes :
- Processing that adjusts the balance of brightness and the gradation of the
screen is improved, and the image quality of default has been readjusted.
- "Setting->Screen->Scanline Density"(density of the horizontal scanning
line) menu was moved to "Screen->Scanline Density", and the setting of
"10%, 30%, 50%, 60%, and 70%" was added.
* When the value of this "Scanline Density" is set small, the gamma value
is optimized (bright). This can be set at "TV Mode" or "Horizontal
- "Optimize Gamma" was added to "Screen->Scanline Density" menu. Remove the
check if you do not want to optimize the entire brightness(gamma value)
when the scanning line is displayed. Use by having put the check is
recommended usually. Because it must not become difficult to see the
character of the shade part.
- The setting of "0.94" and "1.04" was added to "Screen->Gamma" menu.
* Set "Brightness" greatly when you set Gamma small. Because it must not
become difficult to see the character of the shade part.
- The image quality of the "TV Mode" and "Horizontal Scanlined" at "x4" has
been improved.
- The speed and timing were brought close to the movement of a real machine.
In "CITY HUNTER", the problem that the lower hem of the start demo
occasionally fell into disorder (generated from a recent version) was
- When "Metal Angel 2" is started, a part of CD-ROM access processing
becomes slowness near a real machine. The problem that the voice of the
visual scene becomes interrupted was solved.
- When "Metal Angel 2" or "Travelers!" is started, the message of CD
installation("CD-ROM->CD FullInstall" menu) recommendation is displayed.
(For the voice problem solving. However, a little gap of voice happens at
a real machine, too.)
- In "Xak III", the problem that an uppermost line of the screen had
flickered was solved.
- Additionally, a detailed part has been improved and corrected.

Print this item Send this item to a friend

Information Interviews are back!
Posted by: nickblame - 04-03-2010 03:07 PM
1492 Views - No Replies

Our interviews are back online after the site redisign. Check them out right here and be prepaired for more to come real soon Rolleyes

Print this item Send this item to a friend

DC nkeynes, the author of lxdream
Posted by: nickblame - 04-03-2010 02:55 PM
7675 Views - No Replies

Hi nathan! this is First of all, congratulations for lxdream which imho has a really special touch as an emu project.

Second of all, the penguine logo kicks a$$. It's not that shiny but it does make an impact Tongue And off course the linux all the way philosophy and the properly maintained site/source/forum makes lxdream emu one of my personal favorites. I've been following lxdream for quite some time now and I really have some questions that I believe many other observers of the project have as well.

So here goes.

Are you working alone on the project? I mean I think I saw somewhere on the site something "us" or "we" I'm not sure.. Off course I don't think that you never ask for help by any1, officially how many people are on the project.

There's been a couple of people who have contributed code, especially Wahrhaft who's done a lot of work to support GUI-less environments, but mostly it's been just me so far. I would like to build up a broader development community around lxdream, but it's been difficult to find people who both have the skills and are interested in working on it.

How old is this dream and what does that "lx" on the front mean? oh wait.. I think I just got it! linux?Big Grin

If I recall correctly, I first started looking into it sometime in 2004, and the earliest code would have been late '04 or early '05. At the time no one appeared to be (publicly) working on Dreamcast emulation, and there weren't many open source emulators in general (which still surprises me to this day). There had also been a lot of work done on dynamic binary translation in recent years that hadn't made it into production emulators, so it looked like there might be an opportunity to advance the state of practice there.

Originally the emulator was titled 'DreamOn', but since that was taken by the time of the first release in mid '06, it became 'lxdream' for (as you've guessed) linux.

Did you work on other emu related projects before or side ways with lxdream?

I've worked on binary-translation systems professionally, (not gaming related), but lxdream is the first full-system emulator I've been involved with.

Do you plan on having a windows port for lxdream? And if so, is the source in a good shape for win porting? My point is whether lxdream is too linux committed or not.

I don't have any plans to do a windows port myself, but if anyone else thinks it's worth doing, I'll certainly accept patches for it. I don't expect it would be particularly difficult - I've built it successfully under cygwin in the past - so it's mostly just a matter of adding native support where needed.

This could be the most stupid question but I can't get it out of my head and it was the first thing that struck me when I came accross lxdream in the first place. When lxdream gets polished enough and runs like hell, can I make a bootcd/bootusb that loads live linux and converts my pc into a dreamcast? I mean how cool could that be? (don't shoot me please)

Unfortunately as far as I am aware there's no way to get a PC CD/DVD drive to read GD discs (except perhaps by hacking your drive's firmware), so that would tend to limit the uses of such a thing, but otherwise I don't think there's anything stopping you from doing that from a technical pov.

lxdream has a very good status in terms of com games compatibility, sound, speed. Although you have not yet given the version 1.x.x yet. So how close is lxdream getting to version 1.x.x?

It does? That's news to me ^_^.

In any case, it will be 1.0 when all of the hardware is fully emulated, preferably at full speed. There's still quite a few pieces missing at the moment, some fairly substantial - they just aren't necessarily used by every application/game out there. At a very rough guess I'd expect it to be at least one to two years before we reach that point.

I can't compare lxdream to other dc emulators since I think there is not emu for dc for mac and linux, is there? (and 64bit support as well) So could you compare lxdream to lets say demul and nulldc, in any possible way. (I leave out chankast since it is
the first bang and nothing compares to big emu bangs)

I believe Makaron and nullDC have better audio support at the moment (I know nothing about demul) - otherwise they are generally fairly similar in term of capabilities, at least to my knowledge. I agree that portability is definitely an advantage for lxdream, and of course there's also the fact that it's the only one that's open source.

Do you enjoy working on lxdream? This is not another stupid question. Let me explain. You can't work on an emulator and hate it. You would have stopped long before of that. But judging by the release frequency of lxdream, things kind of slowed down a bit. Don't get me wrong Im just poking here. Did this dream become a nightmare for the developer?

Of course, as you say I wouldn't be doing it if I didn't. The unfortunate reality though is that I simply have far less free time these days than I did even a couple of years ago, so I have to fit coding time in where I can. So of course, if there's any programmers out there who'd like to join in and help move things along a bit faster... that'd be awesome too ^_^.

Dc was a console that lived fast and died young. Emulation for dc had some ups and downs too, I remember about icarus and all the fuss back then. What are your goals and plans for lxdream?

As I said above there's still much that needs to be done in terms of both completeness and performance. Myself, I'm particularly interested in experimenting with more complex translator techniques (e.g. hotspot optimization, trace compilation), and both the audio and video subsystems still need quite a bit of work.

I'm also interested in generalizing the framework to be usable for general-purpose emulation + virtualization (a lot of the code nowadays is not at all DC specific), but that's probably a bit further down the track.

Thank you nathan! wishes you the best for your emu project as much as your real life Smile

Thanks for the kind words Smile

Visit lxdream official site for news and releases at

Print this item Send this item to a friend

SNES byuu, the author of bsnes
Posted by: nickblame - 04-03-2010 02:49 PM
7605 Views - No Replies

Hi byuu! this is I'd like to congratulate you for your continuous efforts to write a really... i mean REALLY complete emulator for the snes.

I’ve been following your posts on your site for quite some time now and i have to admit that there are no other projects in the emulation scene like bsnes. both the percentages of compatibility and the lack of any hacks on the code are quite a piece of work.

Here are some questions that you could answer for us in order get some extra info about you and your project.
So here goes.

How old are you, and are you working as a programmer in real life? Studies?

26, and no. Self-taught.

When did you started working on bsnes?

October 14th, 2004.

Was that the first project of yours in terms of writing an emulator?

The first emulator I tried to write was StarSNES in 2000 or so, which ran about ten demos. I also wrote a Genesis emulator a few years later, again only running a handful of demos. But this was mostly having fun, and I was more interested in the CPU cores for ROM hacking purposes.

bsnes was the first really serious attempt at writing an emulator.

Can you give us a percentage of completion on the bsnes project?

There are things about the hardware that we don't even know about yet, so unfortunately I can't really say.

Compatibility-wise, we're in good shape at least. Right now, there are only three unplayable titles, and all three require their program ROMs to be dumped first. As for everything else, I'm not presently aware of even a single bug in any commercially-released game.

I mean I thought it was complete for like a year now and releases just keep coming (which is awesome btw)

Most of the recent releases have been about adding user interface features. Things like save states, rewind, movie recording, pixel shaders, 7-zip multi-archive parsing, etc.

The core changes I have planned will require me to have a vast amount of free time to dedicate solely to the emulator. I hope to start on those sometime in mid-2010.

If someone compares your work with other good emulators for snes the only thing that bsnes lacks is speed. Is there any chance that bsnes gets a polishing in terms of speed?

I've been working on it, with the help of Exophase and Cydrak. It's gotten a few 3-10% speedups here and there. But ultimately you have to consider that this emulator really does run at up to 32x the precision of other emulators. I don't believe it is possible to get bsnes more than twice as fast as it is now without sacrificing at least some accuracy.

bsnes synchronizes the S-CPU at effectively 10.74MHz, the S-SMP at 2.048MHz, and the S-DSP at 1.024MHz. All other emulators run the S-CPU at ~900KHz, the S-SMP at ~256KHz, and the S-DSP at 32KHz.

Note that synchronization and clock speeds are very different. This is a measure of the smallest unit of time allowed to pass before a processor will see a change made by another processor. bsnes uses the smallest possible timeslices for synchronization such that any additional precision would be completely unobservable to the software.

Ignoring all emulation overhead, modern computers are only capable of up to ~20MHz worth of synchronization between two threads, and even that requires a highly optimized cooperative threading model. Emulators for newer and faster systems avoid this by synchronizing components even less frequently. Quite honestly, it isn't needed for newer systems with games written in high level languages like it was in the old days with hand-written, fully-optimized assembler code.

The thing to understand is that emulation overhead is not based on the MHz rating of a processor, but how frequently the emulator has to switch from emulating one chip to another. On modern processors with 12-stage pipelines and tiny L1 caches, context switching absolutely destroys performance. This is why a Saturn emulator with its 10 slow chips is much more demanding than a Dreamcast emulator with its 2 fast chips.

Some refer to this as the difference between opcode-based and cycle-based emulators, but bsnes further emulates the bus hold delays during memory accesses between opcode cycles.

This is relevant to the previous question a bit. Is it possible for bsnes to port on other consoles? Of course ones that have the needed horsepower.

Yes, I believe the PS3 with Linux is more than capable of attaining full speed with bsnes. It should not even need porting, as the source is already fully portable.

For other platforms, I would strongly recommend Snes9X for now.

Well I do believe that the next question is one that pops on every mind that came across bsnes. Do you consider working on another platform by the time bsnes is 101% complete? Or even do you work on any other project currently?

I don't plan on working on an emulator for another system, but I do hope to find a group willing to work on a speed-focused and accuracy-oriented emulator one day. Just enough accuracy for full library compatibility, nothing extra.

I am working on different projects simultaneously: I'm about to begin work on translating Far East of Eden Zero to English with the help of Tomato, I've been developing a multi-target cross assembler for a while now, and I'm also developing something like a competitor to SDL for cross-platform audio/video abstraction.

How is your involvement in emulation programming working out for you as an experience? Is it worth it as a sport considering that there’s a real huge ammount of work needed to get results. Are you becoming a smarter programmer by reverse engineering consoles?

The SNES scene itself is great. Everyone is really nice, and very helpful. We all share our source code, so we all work together for one end goal; there's no pressure or competition involved.

It is fun to see the results of emulation, but that fades as compatibility continues to increase. At this point, the things left to emulate will only slow the emulator further without providing any visible benefits to gamers. It's very hard to explain to the casual gamer why preservation matters when they can't even see the difference.

I've learned quite a few new tricks while working on the emulator, but much of it is only useful for writing more emulators.

Are you happy with the anticipation of people on your project? Do you thing that bsnes is overrated/underestimated?

A little bit of both.

I am disappointed that so few people know it exist. And that of the people who have the required processing power to use it, so few actually do. In the early days, I lacked a lot of common features; but these days I have them all and many original features, like Super Game Boy emulation, Xbox 360 controller support, 7-zip support, multi-archive support, UPS patching support, a full-fledged debugger, pixel shaders, etc.

But it's also not the be-all/end-all of accuracy. I still have a lot of work left to do to reach my ultimate goal.

The biggest issue right now is that the S-PPU video renderer is something of a hybrid between a scanline and cycle-based renderer. I want it to be fully cycle-based, but this will take years of effort and will no doubt require a massive performance hit. It's not just a matter of synchronizing after every pixel write, I could do that in ten minutes. The real challenge is reverse engineering how the two SNES PPUs accessed memory during each cycle. That will take months, maybe even years, of non-stop work. I intend to continue offering the current renderer for gamers, and the cycle-based renderer for preservationists.

Are you happy with the anticipation of people on your project?

I think the biggest problem is that people seek to constantly compare bsnes to ZSNES et al. They are completely different projects. bsnes aims to document every last piece of the SNES hardware, speed be damned, so that the information will be around for the future. Once the last SNES console dies, like the Game & Watch devices already have, what we have reverse engineered will be all that is left. I want to get as much info as we can, while we still can. ZSNES et al aim to emulate the minimum amount necessary to play the most popular games with the lowest system requirements obtainable. In my opinion, they are both very useful goals. Not all of us have fast computers.

Also, my goal is not to get everyone using bsnes. I honest to God do not care about popularity. I simply want to see the SNES scene as a whole continue to improve. I feel it has stagnated substantially: the last official SNES emulator released, other than bsnes, was SNESGT on May of 2007. Two and a half years ago. You can verify my sincerity by looking at the changelogs to ZSNES, Snes9X, SNEeSe, SNESGT and MESS. You'll find my contributions in all of them.

It bothers me that the SNES scene is stuck with ancient copier headers, dozens of ROM file extensions, voodoo magic memory mapping, a woefully inadequate soft-patching system with a 50% failure rate, ROM hacks that were designed in one specific emulator that won't run in any others, and bug reports that have been open for over a decade now.

I will lend my full support, time, knowledge and skill to any emulator author who seeks to better this situation and is also willing to share their research with the public.

Thank you for your time byuu! I hope we stay in touch and spam about bsnes more to the public Smile

Visit byuu’s site for his blog. News posts and ofcourse downloads at

Print this item Send this item to a friend

nes Nestopia Unofficial v1.41 Released
Posted by: Alastor - 04-03-2010 10:14 AM
2752 Views - No Replies

Nestopia is a NES emulator for Mac .

1. Removed manual option to set priority of Nestopia's main emulation loop thread. Instead, Nestopia now boosts its own process base priority AND its own main emulation thread priority whenever it is the active foreground window (and/or running in full-screen mode). This brings Nestopia much closer to real-time performance and responsiveness.
2. Removed some screwy input polling logic, and added some calls to input.Poll(), to ensure that the input devices are always polled immediately before the input state is utilized. This was the key change that got rid of most of the lag.
3. Removed some screwy input timing logic that was causing input polling to work only on certain clock intervals, rather than allowing it to work every time it was called.
(As far as I can tell on my own hardware configuration, these three changes taken together have completely eliminated the lag problems that have been present in Nestopia for several releases. Your mileage may vary.)
4. Updated the Visual Studio solution/project to build successfully under Visual C++ 2008 Express Edition.
5. Added this releasenotes.txt file and bumped the version number to 1.41.

Thanks to EmuCR .

Print this item Send this item to a friend

  GameEx v10.50 Released
Posted by: Alastor - 04-03-2010 10:10 AM
2184 Views - No Replies

GameEx is a multiple frontend for command line based game emulators .

Changes :
- The freezing issues reported are now fixed. A big thanks to Jeremy (Frequency) for helping me with that. We both put a lot of effort in.
- In addition there is a now a new in game menu with gameex that can be called up when running MAME, Daphne and emulators. You can view control panels, artwork and instructions and then either resume or exit the game. This is one of those dream features in a front end, and I intend to extend it in upcoming releases. As always please give your feedback.
- The video and DVD player has also had a few user interface improvements.

Print this item Send this item to a friend

Latest Threads
  Thread Title Replies Views Last Post
  CyanogenPSP v6.1 2 253 Yesterday 12:35 PM
by DragonNeos
  FRANTIX - ULUS10039 0 203 12-17-2018 09:12 PM
by raziel1000
  Complete rewrite of the video play modul... 4 359 12-17-2018 08:16 PM
by gid15
wii New dolphin revision 6b7a1ca6d1 0 4,012 11-14-2018 11:16 AM
by Live Downloads
download New xenia revision c949ce3d 0 4,037 11-14-2018 09:54 AM
by Live Downloads
wii New dolphin revision 61821b067f 0 4,854 10-25-2018 09:21 AM
by Live Downloads
download New desmume revision 064527e2 0 5,043 10-25-2018 08:13 AM
by Live Downloads
download New xenia revision 6a39d4b1 0 864 10-25-2018 07:06 AM
by Live Downloads
  Black screen on Braid 0 17,221 09-18-2018 02:13 AM
by ianovic
psp New jpcsp revision ebd518e3 1 3,467 01-14-2019 07:35 AM
by DragonNeos
Emunewz Network
ArcadeFlex Official Site
JPCSP Official Site PCSP Offical Site
Latest Posts
RE: CyanogenPSP v6.1
Posted by: DragonNeos
Yesterday 12:35 PM
RE: New jpcsp revision ebd518e3
Posted by: DragonNeos
01-14-2019 07:35 AM
RE: CyanogenPSP v6.1
Posted by: gid15
01-02-2019 01:11 PM
CyanogenPSP v6.1
Posted by: DragonNeos
01-02-2019 08:15 AM
RE: Star Wars : Lethal Alliance - ULUS10188
Posted by: raziel1000
12-20-2018 08:19 PM
Pro Portal 1.0 © 2010 Adnan TOPAL