ExLoROM & ExHiROM & extra emulated mappers discussion

[Disch]

And then you proceed to shit on emu authors who were at the forefront of figuring out how the system first worked and built the foundation for future emulators to come, just because they don't adhere to your personal opinion on what a "right" emulator has to be.

What?  When did I EVER do this?

I have tremendous respect for first gen emu developers.  That shit is crazy hard to do.  NESticle was down right revolutionary.

But time moves on, and those things fade out, and better things come up.  Yes, standing on the shoulders of emu devs before them.

I'm out of this discussion, but I hope you'll eventually realize how full of yourself you are.

I'm sorry that the history of emulation upsets you.  Hopefully you'll realize that history is what it is, and not what you want it to be.



EDIT:

I don't know how I missed this part:

And which council of emu authors gave you the authority to speak definitively for all of them?

Come on.  I'm obviously speaking generally here.  There are going to be emudevs that disagree with me, just at there are going to be ROM hackers that disagree with you.

I'm trying to give you insight on a culture that I was a part of for years and that you don't seem to be a part of.  For some reason you're interpretting that as a personal attack... or me being big-headed... or whatever.

[AWJ]

Isn't Star Ocean considered an 'ExLoRom' or are things a bit janky there?

Star Ocean uses the SDD1 chip. SDD1 games, SA-1 games and SuperFX2 games are in a way "both" LoROM and HiROM--the same ROM is mapped in both 32KB banks and 64KB banks  (and SDD1 and SA-1 support bank switching as well)

The SDD1/SA1/SFX2 mappings are nothing at all like what the romhacking community calls "ExLoROM", which is simply LoROM with A23 connected (analogous to how "ExHiROM" is HiROM with A23 connected)

[tryphon]

It seems there's a conflation between patches and extra-features.

When coding an emu, you make a patch when you missed something in implementing the emulation of a piece of hardware (for example because you lacked documentation) that cause a specific game not to work. Your patched program will behave differently that the hardware it tries to mimic, but hopefully the specific game will play decently.

An extra-feature is implementing a behaviour that isn't in the original hardware, but which doesn't conflict with it. I don't really see why implementing these will be in conflict with accurate emulation.

The question is rather : why emu coders would bother implementing features only puzzledud uses, for debatable reasons ?

[henke37]

When it comes to features there is always the limited amount of developer time. And some of the mentioned features are highly invasive. Savestates for example are very hard to add as an afterthought.

[FAST6191]

Savestates for example are very hard to add as an afterthought.

I imagine I could put on my best code obfuscation tshirt and also make a spaghetti code based emulator that would see it hard to do but any sanely coded emulator will surely be able to dump/restore memory+registers, and possibly halt it if you somehow need a "long" time for it.

[Disch]

Yeah savestates aren't exactly hard to work in unless you do weird non-deterministic threading stuff -- like the early releases of bsnes.

[KingMike]

That said... I'm not entirely sure what 'extra mappers' you're referring to.  Are you talking about the FFE mappers?  Because there is little to no reason for emulators to support those.  They've effectively been deprecated by the NES emu community.

My guess is a whole bunch of Chinese/Russian bootleg mappers added by a ROM dumper in Russia with a difficult to remember name (like c4he...).
Most famous of those is Nanjing (who made a lot of bootleg RPG ports including FF7 and Pokemon).

[obscurumlux01]

Ok people, please let us keep things on topic and refrain from personal attacks against others.  We're here to discuss and debate, not yell at others for not agreeing with us.
I would especially expect mods and admins to be held to a higher standard by virtue of their position and show the rest of us how to act rather than devoluting into such antics.

On your 'About this Site' page it is explicitly stated that the purpose of this site was to bring the ROM Hacking Community together.

I personally requested Disch not to leave the conversation pages ago just because things became a bit heated in the debate as long as people refrained from personal attacks.

And whether anyone here likes it or not, you learn the most from the people who disagree with you; especially those who offer a unique perspective/insight that is very rarely if not ever represented on a RomHacking-focused website like this one.

In 'the thread that shall not be named' we shall refer to 'the one that shall not be named' by the acronym of P-Diddy.  Fair enough? 

I disagree with what P-Diddy stated not out of malice but out of understanding.  I can understand the need for wanting to prevent karters as I've been fairly lurking and active in various RomHacking circles.  In particular, sometimes all it takes is one person to give a swift kick in the ass of a stagnated translation project that hadn't seen a release or update in over a year

There are an amazing amount of peripherals and accessories that were made just for the Famicom and NES.  I'll keep it simple.

Faimicom Data Recorder basically duplicates the functionality of what most NES emulators offer today with saving custom stuff from the game.  Unfortunately we didn't get the 'save custom tracks' stuff from Excitebike though; I'm unsure if that was ever emulated properly.

The savestate hardware for the Famicom and Super Famicom was the 'ASCII Turbo File'.  Make your own savestates on actual hardware.  Done.  So all the talk about savestates not being an official thing and not a focus of what emulators should include is kinda silly now.

I respect the point of Disch to stick with 'whatever was done in hardware' and I get the limited time/resources for emulator authors to include things specific to ROM Hacking that haven't been done in hardware (yet).  I'm still waiting on the MSU-1 compatability to be added to SNES9X.

I'm gonna expand on the emulator versions thing that Disch mentioned earlier.

Version 1 - Hacky/buggy and just to get things to work (Nesticle, ZSNES, etc)
Version 2 - Still somewhat hacky but steadily improving towards more accuracy (FCEUX, SNES9X)
Version 2.5 - The pinnacle of accuracy, sometimes at a severe performance cost (Higan)
Version 3 - The pinnacle of accuracy but with system requirements that are feasible on older or low-powered hardware.

I'm hoping we can all understand that ZSNES did a good thing initially for SNES emulation but now it needs to go the way of NESticle.  Those devs have different priorities now and unfortunately they are holding back the advancement of emulation by refusing to implement accuracy fixes and optimizations that would bring them closer to a 'version 2' emulator.

The good news is that if people want to do so they can just fork ZSNES and make an 'accuracy-focused' improvement on it.  That is absolutely possible.  I guess the main question would be 'why?'.  What does ZSNES offer to contribute to the emulation community now with both SNES9X and Higan fulfilling just about anything it could do?  A clunky pseudo-DOS style UI from the early 90s?

I don't even think ZSNES has actively been worked on in months/years.  Last change I noticed was a long ass time ago.  At least SNES9X still has a semi-active/public GIT repository.

And don't knock that FF7 pirate cart.  Maybe I hope that even Disch would have to admire the technical skill it took to pull off

EDIT:  Yes I hate wikipedia.  No I don't have other reliable sources except the ones at the bottom of those articles in mostly foreign languages.

UPDATE:  Inaccurate info about ZSNES.  It seems their forums are still active and they've been digging down to a planned 'v2.0' release that is apparently an entire overhaul/rewrite of major parts of that emulator.

ZSNES v1.51 is the latest official release from them (that is almost a decade old now) and it has notable severe issues with SA-1 games as noted in their thread.  Maybe posting it here might get some ZSNES lovers to notice.

I still haven't noticed ZSNES offering an updated or public source code repository so that others can see what they're doing and contribute.  Either that or I haven't found it.

[Disch]

My guess is a whole bunch of Chinese/Russian bootleg mappers added by a ROM dumper in Russia with a difficult to remember name (like c4he...).
Most famous of those is Nanjing (who made a lot of bootleg RPG ports including FF7 and Pokemon).

In that case, yes, I would (and did) support those.

EDIT:

Since you left out examples for a "Version 3" emulator... might I suggest NEStopia?  To my knowledge it does not employ a single game-specific hack and has damn near 100% compatibility.



EDIT 2:

about ZSNES.  It seems their forums are still active and they've been digging down to a planned 'v2.0' release that is apparently an entire overhaul/rewrite of major parts of that emulator.

Hey, what do you know!  History supporting me yet again.  I'm totally not surprised.

[obscurumlux01]

Nestopia being super accurate?  Really?  I'd appreciate if you could dig through the source code and verify this to be certain.
Also what about FCEUX?

I'll have to switch to Nestopia if it is indeed more accurate.  I wasn't aware whether or not FCEUX is less-accurate or if they're both equal in accuracy or whatever.

[abyssonym]

Just want to mention that I hate the MSU-1 hacks, because I have a Super Everdrive. I know that SD2SNES supports them, but it costs twice as much as an Everdrive. You see the same problem that you see with emulators... you end up with hacks that work on some flash carts, but not others.

I can understand and accept the issue of proprietary chips not being supported by all flashcarts, but when it's a homemade chip that causes a hack to be unplayable on my flashcart, I get a bit annoyed.

[SunGodPortal]

I can understand and accept the issue of proprietary chips not being supported by all flashcarts, but when it's a homemade chip that causes a hack to be unplayable on my flashcart, I get a bit annoyed.

I thought you could still play the game but the sound might be bugged. I was under the impression the the MSU-1 only effected sound.

BTW I'm just curious, not trying to knock your point.

[abyssonym]

I decided to test a couple and it looks like you're right, the MSU-1 hacks just play the original music on my Everdrive. That might be because the hackers diligently included workarounds in their patches for emulators without MSU-1 support, but I suppose that's good enough for me, as long as people keep doing that.

I was thinking that MSU-1 was the problem in Flames of Eternity, because that hack works on the Higan core, but not on my Everdrive. But it might be some other chip that the Everdrive doesn't have.

[Disch]

Nestopia being super accurate?  Really?

NEStopia was on the front lines for the NES emu renaissance a few years back.  The lead dev, whose name I sadly can't remember, was working in conjunction with blargg, bootGod, and quietust to implement hardware specifics as they were being discovered.  Thus, at the time, it was always one step ahead of everyone else in terms of accuracy (except for maybe quietust's emu, Nintendulator, which was keeping pace right along side it, but that wasn't as feature rich and was much more CPU intensive).

In fact it was so cutting edge it had implemented support for things before they were formally documented.  And some of the stuff, like obscure mappers, never did get formally documented... and the go-to reference for aspiring emu devs when it comes to that stuff is the NEStopia source.

It might choke on a few of blargg's timing ROMs -- I mean no emu is going to be perfect... but I haven't checked that shit in years.  Regardless, you'd be hard pressed to find any other emu that employs zero hacks, has comparable compatability, and is as feature rich as NEStopia.  It really is the gold standard.  The only thing it really lacks is a debugger.

Granted... since it hasn't been updated in a while, it's possible that FCEUX has caught up, but I kind of doubt it.


Not that I'm putting FCEUX down.  It's a great emu.  But NEStopia makes me splooge.


But like I say... this was the case several years back.  Things could have changed since then.  I'm too exhausted to check the source for both emus to confirm.... plus I don't really care enough to spend the effort to research it.



EDIT:

A quick check (without looking at the source) shows FCEUX 2.2.2 barfs all over Micro Machines in 2 different areas:

1)  It fails to render the proper color when the PPU is disabled.  This results in black splotches on the title screen, as well as a solid blue bar beneath the logo when selecting your character (as opposed to the fancy gradient bar the game should have)

2)  It fails to respond to properly to OAM reads during rendering, which the game [ab]uses to sync with HBlank, resulting in the character select screen shaking.

Micro Machines has been a typical stress test ROM for a long time specifically because of these two points.  These issues have been known about and resolved for a looooooooong time.  So yeah... there's no way FCEUX caught up to NEStopia.


I'll try out some other known problem ROMs in a bit.

[SunGodPortal]

I was thinking that MSU-1 was the problem in Flames of Eternity, because that hack works on the Higan core, but not on my Everdrive.

The problem with FoE is more likely bugs that made their way into the game because of some pretty extensive use of a level editor and likely the addition of what I would think would amount to a good deal of custom code. I know that in general I didn't have much trouble with them on my Powerpak but every so often I would run into a room or an event that would cause the game to freeze where on an emulator it would not (emulators are supposedly more forgiving of errors).

[Maeson]

... I don't know if Wii "homebrew emulation" has any value here (My guess is not, seeing the comments), but from all of the NES emulatos avaiable for it, Nestopia is simply the best thing there. The only problem it has is with some translations, curiously all of them being Konami fan-translations, and a couple of games like Startropics (Although this one could be my fault, maybe).

The only reason I use FCEUGX is for the Zapper games (After all, Wiimote as a Zapper is better than a PC mouse for this). And while it works pretty well, all games in general just run better in Nestopia.

[obscurumlux01]

Looks like I'll get to learn a 'new' emulator then.  I'll be damned...heh.
Perhaps we do need more information about just how accuracy-focused Nestopia is compared to other emulators.

I'd figured that since FCEUX was still being actively developed that it would've solved major known emulation problems by now.  I'm disappointed that they have yet to import the accuracy fixes from Nestopia (since both are GPL open-source projects apparently).

Trying to play Flames of Eternity instead of Crimson Echoes is like playing any of the 'Dick Nazi' hacks by HaxorKyo instead of the original game.
You COULD argue that it has merit, but the end result is tasteless trash that liberally mocks the source material.  For a community that is supposed to be against blatant plagiarism and disrespect of other romhackers I still find it discouraging that FoE is still talked about while Crimson Echoes is utterly ignored.

FoE is not better than CE.  Not by a long shot.  I'm debating on whether I should just write an article or two extensively documenting all the crap that went on so more people would understand.

UPDATE:  Nestopia is still being actively developed!  It was apparently forked and has a GIT repository.  YES!  =D

[abyssonym]

The problem with FoE is more likely bugs that made their way into the game because of some pretty extensive use of a level editor and likely the addition of what I would think would amount to a good deal of custom code. I know that in general I didn't have much trouble with them on my Powerpak but every so often I would run into a room or an event that would cause the game to freeze where on an emulator it would not (emulators are supposedly more forgiving of errors).

It would have to be a very specific kind of bug for it to work on Higan but not my Everdrive. "Forgiving of errors" doesn't describe Higan very well.

[SunGodPortal]

It would have to be a very specific kind of bug for it to work on Higan but not my Everdrive. "Forgiving of errors" doesn't describe Higan very well.

Now that I think about it the bugs were in Crimson Echoes, not FoE. That was the reason why I switched to FoE. At the time I started CE and upon looking for a final or more complete version I discovered FoE and assumed it was the real deal. I later found out otherwise.

[goldenband]

The only problem it has is with some translations, curiously all of them being Konami fan-translations

That sounds like it could be a header problem. A ROM that's in Nestopia's internal checksum database will work even if it has a bad header, but once the ROM is altered, Nestopia has no way of knowing if the header is wrong. That can mean that it uses the wrong mapper (among other things), and then anything can happen.