Slashdot Mirror

higan is encouraging users toward adaptive sync displays. Not just for latency reasons, but due to necessities of emulation: higan supports systems that run at 50hz, 60z, and 75hz currently. Short of taking over the entire display and refresh rate by changing modes (which isn't even possible in the Linux/BSD Xorg world; hence I won't even consider this), and even then, requiring a monitor that can handle 75hz in the first place ... you'll never get proper synchronization with Vsync anyway.

from https://byuu.org/articles/late...

The problem with higan is that it doesn't allow you to sync to refresh. This makes scrolling choppy as hell. He says it supports those refresh rates but it doesn't seem to work.

Generally, I use snes9x unless the title doesn't run on it. Since I generally don't play obscure japanese RPGs, it works fine for me.

Not really.
According to byuu:
https://byuu.org/emulation/pre...

Not only there are some unknown revisions of the games that he managed to find with his project, as the roms were often modified for dealing with emulators with poor heuristics, hacks to remove anti dumper code and just plain malice, like signing the rom with the name of the dumper etc..

He's doing more than just dumping the ROMs, he's been photographing the carts and scanning the manuals as well as part of his preservation project. He has a custom rig for dumping that knows more about some obscure hardware quirks of how it does addressing to properly map out the ROMs.

But maybe I should let byuu explain:

Yes and no.

First, there are many revisions of games that are undiscovered. Upon dumping my USA collection, I found two new game revisions. One for "The Death and Return of Superman", and one for "Ken Griffey Jr Presents Major League Baseball."

What is a revision? Sometimes a game publisher will release a game, and then discover a serious bug in the game and will fix it. They then release new cartridges, but these are not labeled. You often can't tell which revision you have unless you take the game apart and read the serial numbers off of the ROM chips.

Second, there are bad dumps out there. There are many reasons for these. One is that games were often patched to remove anti-copier protections. These often do serious things like slow games down by up to 25% of their original speed (though usually it's not that drastic), because the oldest copiers did not have RAM with fast access speeds inside of them. Another is that due to the use of floppy disks, bits would get flipped occasionally. The third would be from older piracy groups adding "trainers" (advertisements upon booting the game, often with the ability to apply cheats to the game from an onscreen menu), and sometimes people would remove these trainers rather than redumping the games. The fourth would be header changes to make games run in emulators with poor heuristics. And the fifth and least likely would be malicious changes: people putting their names into the game images for bragging rights. Most notably here would be Diskdude and Vimm's Lair.

In the first batch of 100 PAL games I dumped, I found two games with bit corruption. The first was Spider-Man & Venom, where the main Spider-Man sprite was partially corrupted. The second was Fatal Fury 2, where one of the fighter sprite frames was partially corrupted. What's so damning about this is that both of these games were marked as "verified" in GoodSNES, which for many was considered a gold standard that the games were 100% bit-perfect copies.

A friend, KingMike, has found a half-dozen bad dumps of Japanese games from his own collection so far.

It's important to note that the USA set is easily the most dumped set there is. The PAL and Japan sets are not dumped nearly as often. Dumping the PAL set is thus of great importance.

The fact that you need to ask is a bad sign.

I work in technology. I have stopped purchasing consoles and "Exclusive" bits of hardware where ever possible. Console needs to die, not because I am a PC gamer, which I am, but because people should not be asked to shell out $$$ just to play on an exclusive platform. The different in cost and performance are less of the issue compared to vendor lock in with game titles.

Regarding the Retro community. There are many fans like http://byuu.org/ that focus on 100% accuracy with emulation. Compound that with available Up-scaling technology and you can make an older titles visually look better without altering the original code or game-play. I cannot tell you how terrible many game ports have been and show a clear trend that game companies do not respect their IP and would rather damage it in the pursuit of money than to do right by it or the gamer community.

Do we really need to get into Nintendo's terrible history against gamers to add more fuel to this?

You can turn those off with userchrome.css.

.tabs-newbutton, .tabs-closebutton { display: none !important; } /* use Ctrl+T for new tabs, and middle-click to close tabs */
.toolbar-grippy { display: none !important; } /* get rid of the grippy controls on the left of each bar */
.toolbarbutton-menubutton-dropmarker { display: none !important; } /* kill the outer-nested back/forward boxes */

To get clicking on the blank area to open a new tab, you have to extract omni.ja (which is a ZIP file with an intentionally corrupted header, so only a few unzip tools can actually extract it), and patch some of the UI code, then recompress it. Guide here: http://board.byuu.org/viewtopi...

The problem is, no matter how much patching you do, it's not really possible to get Seamonkey to behave decently. There's just so many little annoyances.

I've never been able to get Flash to work in Seamonkey on Windows no matter what I've tried. Fullscreen video doesn't actually go fullscreen, it just opens a slightly larger window inside your browser. F11 browser fullscreen mode doesn't auto-hide all the navigation controls. Trying to add an exemption to your popup blocker is damn near impossible ... I haven't figured it out yet, whereas with Firefox it was just, click the icon in the address bar, hit "allow popups from this site", done. Dragging tabs out of the window to spawn a new window doesn't work, let alone recombining windows into tabs. And on and on and on and on.

I'm just holding out on Firefox 28 for as long as possible, and hoping someone makes a decent Webkit or Gecko browser UI for Linux. If it gets too bad and FF28 is too old, I'll have to start looking into making my own. And just to mention it, Classic Theme Restorer looks absolutely hideous under Linux with Xfce/Clearlooks. It's clearly designed for Windows, with OS X and Linux as an afterthought. Half the UI options don't even have apply to Linux or just plain don't work, and the other half result in very extreme rendering bugs.

I actually run into emulation errors with games I want to play on a semi-regular basis.

Which emulators are you using? For NES/SNES/GBC/GBA, I've been using higan, and I've yet to find a single emulation error. Checking the forums, the kind of emulation bugs still getting reported are literally "on the Super Game Boy player for the SNES, an obscure series of cross-system memory writes with multiple joypads enabled ends up writing the wrong value to a register, which breaks this contrived test case". So it seems to be exceptionally solid. For more recent systems, yeah, I haven't found any truly good low-level emulators, but those are also not the ones you'd be breaking out the CRT display for.

This is done for the SNES, and all known coprocessors have been perfectly emulated. Write-up here, with pictures and explanations.

That is exactly what I am doing now.

See my database here. Each game gets a manifest file that describes the board layout and each individual memory chip.

The difference between my approach and MAME's, is that my board descriptions are external to the emulator, and not bundled in an internal database. And I also store all the files inside a unique folder per game, rather than inside a ZIP archive per game. That approach lets me put save game data into the folders as well. The database I linked can generate the game folders from individual files.

I agree with you completely. Read up on what Rufus Pollock, a Harvard professor found after doing research on copyright. The optimal length is 14 years, of which all SNES games have passed. Anything longer is corporate greed.

As far as letting someone read them, that is exactly why I bought them in the first place. I read every one by hand with my own custom hardware (here is a picture of my setup.) This allowed me to image the entire function of the PCB, not just the ROMs like current dumps. I also scanned every box, cartridge and PCB. I then put up all the information in my online database here. I can't distribute the ROM images for legal reasons, but by comparing my SHA256 hashes to yours, you can verify your ROMs are legitimate and unmodified, clean dumps.

I agree with you completely. Read up on what Rufus Pollock, a Harvard professor found after doing research on copyright. The optimal length is 14 years, of which all SNES games have passed. Anything longer is corporate greed.

As far as letting someone read them, that is exactly why I bought them in the first place. I read every one by hand with my own custom hardware (here is a picture of my setup.) This allowed me to image the entire function of the PCB, not just the ROMs like current dumps. I also scanned every box, cartridge and PCB. I then put up all the information in my online database here. I can't distribute the ROM images for legal reasons, but by comparing my SHA256 hashes to yours, you can verify your ROMs are legitimate and unmodified, clean dumps.

I haven't distributed any of the images, only SHA256 checksums (here), and I promise that I'll delete all the ROMs as soon as the set sells ;)

It has to be Windows, because the majority of emulators are developed to work on Windows only.

Drop the BS and pick up the BSNES. From that page: "(Windows, OS X, Linux)"

Even aims for cycle accuracy.

http://byuu.org/bsnes/

Do you mean something like this?

You seem to be missing the point. The triforce spinning was probably a bad example, since it's not that important. The problems with inaccurate emulators range from annoying visual glitches, to crashes, to actually making a game unbeatable. Star Ocean, for example, will sometimes crash in zsnes, but I haven't experienced that in bsnes. The battles run at double speed, much like the triforce in LTTP. Playing Yoshi's Island in zsnes, any level with those giant fuzzballs will tick every time you move. It's nauseating to get through. In zsnes, Super Mario RPG battles will sometimes de-sync to the point that the music and animations will continue, but your input will no longer work and you have to reset the game.

In Speedy Gonzales - Los Gatos Bandidos, if you're playing with zsnes, you can't even beat the game, because it doesn't emulate everything necessary to do so. In Sink or Swim, the room fills with water, and you need to swim above it. But because of timing and speed issues, the room fills up much too fast and you will drown instantly.

You can read about some of these issues, and many more, here: http://byuu.org/bsnes/accuracy

bsnes is an emulator that began development on 2004-10-14. The purpose of this emulator is a bit different from others: it focuses on accuracy, debugging functionality, and clean code. The emulator does not focus on things that would hinder accuracy. This includes speed and game-specific hacks for compatibility. As a result, the minimum system requirements for bsnes are very high. The emulator itself was not derived from any existing emulator source code, such as SNES9x. It was written from scratch by myself. Any similarities to other emulators are merely coincidental.

bsnes has some of the features you would expect in every modern emulator like save states, but it's not like you have to use them just because they're there - I don't. As for the games themselves, you could make a rule for yourself to only play games you own a physical copy of, but if you download a game and can't be bothered playing through it, that's most likely a sign that you don't find it worth your time. As for the controller; adapters aren't so expensive you couldn't afford one. I opted for buying a replica USB controller instead, as they can be had for about $10 in most electronics stores around where I live, and look and feel exactly like the real thing except they obviously don't have the SNES logo on them. That controller coupled with bsnes (and its 99.9% accure emulation) feels exactly like the real experience back in the days, except games don't look like shit when output to modern displays.

I hate to come across as advertising, but for those worried about the possibility of any specific API going away ...

I've found that most small to mid-sized GUI applications only really need the basics: windows, menus, buttons, check/radio boxes, list/tree views, sliders, scollbars, combo boxes, and something to render graphics (Direct3D/OpenGL/raw pixels) onto. It won't get you Photoshop or Quark Xpress, but that's enough for most CLI frontends, emulators, text/hex editors, office tools, etc.

I put all my eggs in the Qt basket and got burned by a lot of platform-specific bugs. So I took all the core features and wrote a unified wrapper around all of the major toolkit APIs: pure Win32, GTK+ and Qt. In this way, there are no 4-10MB run-time library dependencies, the code is much simpler, and I feel my applications are more portable: the wrapper is so small one could port it to eg Haiku, Cocoa, etc in roughly one weekend. I can also target any platform (Win32, Win64, Linux, OS X), and any toolkit available on each, with the exact same codebase. Eg both Gnome and KDE users gets 100% native apps.

Doesn't have a snazzy public name, but internally I call it phoenix, and it's available here, if anyone is interested. There are, of course, obvious downsides: if you want a complex GUI, you would have to add the higher-order, platform-specific (floating docks, grid views, tab bars, sheets) controls yourself. And it also targets C++0x, which is great for lambda callbacks, but bad for portability at the moment.

There are already emulators for the few consoles and arcade games that used actual vector monitors (e.g. Vectrex).
This filter looks quite similar to the existing HQnX series of filters, but with even more aggressive smoothing (from the paper, they appear to use a similar quantisation matrix approach then vector-smooth the result). As the paper shows, the results are fine for a few cases of a single isolated sprite, but for a whole display it looks really nasty, even worse than HQ4X.

My personal preference is CRT-emulated scaling. Yes, an LCD can display pixel-perfect data, but most consoles prior to the latest generation were designed with CRT displays in mind. 8-bit and 16-bit especially used some of the quirks of the way a beam scanned over discrete phosphors (bleeding, blooming, variable beam width, etc) as a way of blending edges and colours together to create additional effects.

Zsnes is great, but not a model of accuracy. The audio accuracy is especially poor. It's also written partly in 32-bit x86 assembly, so it's only going to be with us for as long as x86 is.

bsnes on the other hand is written to be cycle accurate. Everything the hardware does is emulated, with no shortcuts. That is what we really need from emulators. Plus it's written in portable C++, so it will be around forever. The downside is that you need a fairly hefty machine to run it.

Speaking of bsnes, byuu, its creator, is working to preserve SNES games and their history -- he just began a massive undertaking to catalogue, photograph, and document all known SNES games. Cf. here for more info. If I had access to my old SNES games (stored thousands of miles away at my parents' house), I'd help him out, but maybe you and some of the ./ crowd may be able to be of some help.
I used to be able to run bsnes without any real problems, but I think my desktop is getting old, and I've fallen back on ZSNES for the time being, unfortunately.

Except that newer LCDs have LED backlighting which is no longer constant, but flashed (WHY? WHY? WHY? Just to save some power? Please, computer manufacturers, let *me* make that decision!), so the experience is somewhat more like a CRT.

Even an LCD with zero lag (i.e. 0 msec GTG performance) and a backlight that's constantly on looks blurry when things move and you follow them with your eye. An LCD with 0 msec GTG and an LED backlight that pulses ONCE per frame will not have that blur as you follow the object with your eyes. This is similar to how a CRT has much less blur for the same situation, because as you note, the phosphor is only brightly lit for a very small part of the refresh.

When you follow the moving object with your eyes, your eyes move smoothly, even though the object is jumping to a new position every 1/60 second. If the object only flashes for a short time at each new position, the flash is always at the center of your vision. If the object is shown for each entire frame, it gets smeared across the center of your eyes, since your eyes are constantly moving during the entire frame. Thus, until LCDs flash the backlight for a short duration only ONCE per frame, there will be motion blur for human viewers (unless the viewer fixes his eyes on a point and never moves them).

Compatibility is the percentage of software output perceptibly reproduced by emulation. Accuracy is the percentage of hardware processes faithfully reproduced by emulation.

I personally had never heard of this emulator before, but I am going to try it now. They recommend a Phenom II or Core 2 Duo as minimum to get acceptable performance, which is reasonable for near-full compatibility with games, IMO.

Have you heard of bsnes? It's claimed to have 100% perfect emulation of all but 3 games.

I highly recommend it.

Great, been waiting for that for ages. So now we might finally get those original GBC colors for GB games in emulators (and especially the coloring for Metroid 2!). For reference, if anyone is interested, here's the story how the original GB ROM got dumped by decapping the chip holding it and reading out the values with a Microscope: http://www.cherryroms.com/forums/copier-and-hardware-forum/manually-extracting-rom.html?page=2 (two thirds down the pge, the post by nevikisti from Wed, 05/18/2005 - 10:26). Thread itself deals with how they tried to dump the SNES DSP1 chip, but ultimately failed to do so. Currently there's some effort underway by the creator of bsnes to do the same thing: http://byuu.org/