News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: ExLoROM & ExHiROM & extra emulated mappers discussion  (Read 20925 times)

obscurumlux01

  • Full Member
  • ***
  • Posts: 168
    • View Profile
ExLoROM & ExHiROM & extra emulated mappers discussion
« on: October 12, 2015, 12:09:45 am »
There was a great deal of talk in the thread which must not be named about these formats commonly known as ExLoROM and ExHiROM.
While emulation standards have stabilized over time for stuff like the NES, we're still discussing things over a decade later when it comes to extensibility of emulators to support uncommon and unusual mapping.

There was quite a nice in-depth and interesting discussion about it here from the 'emulator accuracy over everything' angle.

I'd hate to go back to a time where we had emulator-specific hacks (some of which are still on this very website) that only worked on specific custom builds of specific emulators.  I remember the time of Nesticle-only ROM hacks because they were focused on making something that only worked in that specific emulator.

The interesting issue has become where generalized formats have emerged to extend the inherent limitations of the consoles and allow for some amazing features such as the MSU-1 music chip to be created and placed inside a flash cart (the SD2SNES) and used to play cd-quality music for games like Chrono Trigger and Super Metroid.  The true effect varies depending on the soundtrack utilized, but it is still quite an amazing achievement to get that feeling of 'this is what the SNES CD addon might've been like'.

As it stands, it would be interesting to hear some feedback on this particular aspect of an otherwise cluttered discussion that littered the 'other' thread.

Discussion point:  Emulation-only mapper support.  Yay? Nay?  Meh?  While this primarily deals with the Super Nintendo/Super Famicom, we can extend the discussion to other systems as well if it helps out.

Notable quote:
Quote
Byuu:
These LoROM/HiROM/ExLoROM/ExHiROM names are all pretty silly.
There aren't four mapping layouts, there's around 60-80 of them. Most of the differences are in minor mirroring issues, but they do exist.
These names just kind of became quick descriptions for generalized layouts, and they stuck really well.
The important part to you is that ToP (Tales of Phantasia) and DKJM2 are 48mbit and 40mbit with no MMC; SO (Star Ocean) and FEoEZ (Far East of Eden Zero) are 48mbit and 40mbit with MMCs. I have no clue why they chose to use MMCs when clearly they weren't needed, but they did.

EDIT:  I have no clue what DKJM2 is...someone wanna fill me in?
« Last Edit: October 12, 2015, 12:16:05 am by obscurumlux01 »

SunGodPortal

  • Hero Member
  • *****
  • Posts: 2921
  • 2 + 2 = 5
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #1 on: October 12, 2015, 01:22:28 am »
I don't mind things like making a new mapper that allows for a bigger ROM but I don't like the idea of stuff like the MSU-1. A bigger ROM for example would just mean more game (or in a recent case, hell for cart makers who want to make money from someone else's work). The MSU-1 on the other hand adds something that no SNES game ever had. Now I know what you're thinking. "There was never a 8MB SNES ROM" or things like that, but to me the difference there is that the size of the ROM isn't noticeable during gameplay. CD-quality music is noticeable because no SNES game ever had it. If you're going to do that you might as well make a SNES mapper that gives it graphics on par with the PS1 or the N64. Where does it end? A huge ROM would also have benefits like less or no need for compression which would make editing easier. It's so annoying editing graphics for A Link to the Past because I have to use a program that dumps and decompresses the graphics, make my changes and then use the same program to re-compress and re-instert the graphics. That's fucking annoying, especially since the program is so stupid that it requires a header when nearly all other Zelda III resources are for a ROM with no header. That means I can't just do what I've described. I have to add and remover a header every time I want to work on graphics.

Whether a SNES ROM works in this program or that program I don't really care. They're all free, so why would I care? It's not like they take up loads of space on my hard drive. I'm sometimes annoyed when an certain ROMs don't work on my Powerpak, but again I'm not paying for anything so why should I whine about having to play only a handful of games on an emulator as opposed to the sweet goodness of real hardware and a CRT-TV?
War is Peace. Freedom is Slavery. Ignorance is Strength.

tc

  • Hero Member
  • *****
  • Posts: 1132
  • Lum Fan
    • View Profile
    • Eon Blog
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #2 on: October 12, 2015, 01:49:29 am »
Feasibility of running on an original console is the foundation. Hackers and emulator authors choosing to support absurd or impractical mappers is outside the scope of RHDN, in principal we shouldn't endorse the practice. If they happen to be hacks so marvelous they're lasting worldwide cultural icons, not our problem.

SunGodPortal

  • Hero Member
  • *****
  • Posts: 2921
  • 2 + 2 = 5
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #3 on: October 12, 2015, 02:32:06 am »
Quote
Feasibility of running on an original console is the foundation. Hackers and emulator authors choosing to support absurd or impractical mappers is outside the scope of RHDN, in principal we shouldn't endorse the practice. If they happen to be hacks so marvelous they're lasting worldwide cultural icons, not our problem.

I can understand that but at the same time I don't necessarily agree with it. Even if ROM hacking is an illegal hobby I think authors should have the right to prevent people from making money off of their work if they choose to do so. If RHDN doesn't support that I suppose that doesn't keep authors from being able to do so, but I still don't agree with that stance.

That said, when I finish one of my hacks I won't be using any weird setups. I'm just too lazy and I don't want to hear people whining. :P
War is Peace. Freedom is Slavery. Ignorance is Strength.

AWJ

  • Full Member
  • ***
  • Posts: 105
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #4 on: October 12, 2015, 02:48:56 am »
Feasibility of running on an original console is the foundation. Hackers and emulator authors choosing to support absurd or impractical mappers is outside the scope of RHDN, in principal we shouldn't endorse the practice. If they happen to be hacks so marvelous they're lasting worldwide cultural icons, not our problem.

There's nothing absurd, impractical or even difficult about making an 8MB SNES cartridge. You could turn a Tales of Phantasia cart into an 8MB one literally just by replacing the 16Mbit ROM with a second 32MBit one. No commercial games were ever made using the mapping the community calls "ExLoROM", but I strongly suspect you could make such a cartridge out of one of the right kind of original cartridge with a few wire mods.

Going bigger than 8MB would be a bit trickier. You couldn't wire mod any standard cartridge to fit that 12MB Star Ocean hack on it, you'd have to build a cartridge from scratch.

What would be truly impractical is oversized cartridges using coprocessors. SA-1 is physically limited to 8MB, SuperFX2 is limited to 2MB, the original SuperFX is limited to 1MB. No idea what the limit on Cx4 is but I doubt it's bigger than 4MB. The chips don't have the physical pins to address any more ROM than that. To put an oversized hack of a game using one of those chips onto a real cartridge, you'd have to make a clone of the coprocessor, completely duplicating its functionality but giving it additional address pins, which would be... very difficult.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #5 on: October 12, 2015, 03:00:39 am »
Is it really impossible to think that those mappers could actually be implemented in a SD card reader for the real hardware ?

I have a Megadrive with a Mega Everdrive, and I know it is possible for it to access the whole capacity of the card. So I consider the feasability of a homebrew that could use some GB of data (for example, a Street Fighter).

tc

  • Hero Member
  • *****
  • Posts: 1132
  • Lum Fan
    • View Profile
    • Eon Blog
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #6 on: October 12, 2015, 03:08:09 am »
Is it really impossible to think that those mappers could actually be implemented in a SD card reader for the real hardware ?

I have a Megadrive with a Mega Everdrive, and I know it is possible for it to access the whole capacity of the card. So I consider the feasability of a homebrew that could use some GB of data (for example, a Street Fighter).

Flash carts still have to operate within the hardware's tolerances, however far they're stretched.
An emulator doesn't.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #7 on: October 12, 2015, 03:12:36 am »
I'm just speaking of the mappers. AFAIK, mappers lie inside the hardware tolerance.

AWJ

  • Full Member
  • ***
  • Posts: 105
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #8 on: October 12, 2015, 03:13:00 am »
I can understand that but at the same time I don't necessarily agree with it. Even if ROM hacking is an illegal hobby I think authors should have the right to prevent people from making money off of their work if they choose to do so. If RHDN doesn't support that I suppose that doesn't keep authors from being able to do so, but I still don't agree with that stance.

Okay, I just found the thread being alluded to. If I'm interpreting things right, the guy who shall not be named "protected" his hack from being used in ways he didn't like by zipping it, renaming the file from .zip to .sfc, and distributing it with custom builds of SNES9x and ZSNES that treat .sfc files as .zips? And then created pages and pages of forumdrama by bragging about how clever and how morally superior he was for coming up with this stupid scheme?

 :banghead:

tc

  • Hero Member
  • *****
  • Posts: 1132
  • Lum Fan
    • View Profile
    • Eon Blog
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #9 on: October 12, 2015, 03:33:22 am »
I can understand that but at the same time I don't necessarily agree with it. Even if ROM hacking is an illegal hobby I think authors should have the right to prevent people from making money off of their work if they choose to do so. If RHDN doesn't support that I suppose that doesn't keep authors from being able to do so, but I still don't agree with that stance.

That said, when I finish one of my hacks I won't be using any weird setups. I'm just too lazy and I don't want to hear people whining. :P

I didn't say you couldn't do that. The method used would just need to be consistent with RHDN guidelines.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #10 on: October 12, 2015, 03:37:35 am »
@ AWJ:

Not exactly. He designed the game in such way as it uses a mapper that doesn't work on real hardware, but only on some emulators.

Other protections are quite puerile. And I'd be surprised if an average SNES hacker couldn't convert this game so as it works with regular mappers.

But I understand why he did that and doesn't condemn him for.

The problem with using specific features of emulators is :

* if lots of people use it, other emulators will include them and they will become some of standard. But otoh we'll have full of hacks unable to work on real hardware, which can be a problem

* if not enough people use them, then when snes9x or zsnes won't be the most popular emus (which will happen, if not already), other emu devs won't feel the need to implement them, and those hacks will disappear like tears in the rain. Pretty sad

AWJ

  • Full Member
  • ***
  • Posts: 105
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #11 on: October 12, 2015, 03:51:26 am »
@ AWJ:

Not exactly. He designed the game in such way as it uses a mapper that doesn't work on real hardware, but only on some emulators.

Oh? My understanding is that he used ExLoROM (which really isn't as big a deal as it's being made out to be) but he also did something else that supposedly "locked" the hack to the specific custom emulator builds he bundled with it, and bragged about how this made his hack safe from nasty evil repro sellers.

SunGodPortal

  • Hero Member
  • *****
  • Posts: 2921
  • 2 + 2 = 5
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #12 on: October 12, 2015, 04:07:11 am »
Quote
Is it really impossible to think that those mappers could actually be implemented in a SD card reader for the real hardware ?

I can play the 12MB Star Ocean hack on my SNES Powerpak.

Quote
Flash carts still have to operate within the hardware's tolerances, however far they're stretched.
An emulator doesn't.

That would probably depend on what they feature onboard. See above. Note: I'm not expert on this though.

Quote
If I'm interpreting things right, the guy who shall not be named "protected" his hack from being used in ways he didn't like by zipping it, renaming the file from .zip to .sfc, and distributing it with custom builds of SNES9x and ZSNES that treat .sfc files as .zips? And then created pages and pages of forumdrama by bragging about how clever and how morally superior he was for coming up with this stupid scheme?

First, you're wrong about the sfc thing. The ROM needed to have an sfc extension otherwise the patcher wouldn't accept it. It had nothing to do with the zip. If it had, I would remember having to rename it to extract it. Second, no one would ever accuse Puzzledude of having too many people skills but I believe his intentions were noble. And yes, people were bitching and moaning about what he did and totally ignoring his hack. Look through the thread and out of 131 replies there are probably only 5 that were actually about the game, which is a bunch of horse shit. Fucking pathetic.

Quote
Other protections are quite puerile. And I'd be surprised if an average SNES hacker couldn't convert this game so as it works with regular mappers.

They'd have to have an intimate knowledge of ALttP, reorganize the data and rewrite a shitload of pointers. Probably more as well. I believe his methods were quite extensive on this one.

Quote
* if lots of people use it, other emulators will include them and they will become some of standard. But otoh we'll have full of hacks unable to work on real hardware, which can be a problem

I don't see what the problem is there. Don't most people use emulators anyway? True, I prefer to play on my Powerpak but I'm certain that SNES players who own such devices are in the minority so hardware compatibility is really only an issue for emu devs with a purist streak.

Quote
* if not enough people use them, then when snes9x or zsnes won't be the most popular emus (which will happen, if not already), other emu devs won't feel the need to implement them, and those hacks will disappear like tears in the rain. Pretty sad

Not necessarily. This would probably only happen if the emus that took their place were by anal purists who were not familiar with these formats.

Quote
Oh? My understanding is that he used ExLoROM (which really isn't as big a deal as it's being made out to be) but he also did something else that supposedly "locked" the hack to the specific custom emulator builds he bundled with it, and bragged about how this made his hack safe from nasty evil repro sellers.

If I understand things correctly, an older version of one of those emulators already had support for 8MB ExLoROM but for whatever reason they didn't include it in the next version. That's part of the reason why he had to include a modified emulator.
War is Peace. Freedom is Slavery. Ignorance is Strength.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #13 on: October 12, 2015, 04:23:10 am »
They'd have to have an intimate knowledge of ALttP, reorganize the data and rewrite a shitload of pointers. Probably more as well. I believe his methods were quite extensive on this one.

ALttp is far from being the most obscure SNES game. I'm not a SNES specialist, but this kind of thing on MD would cost me at most some weeks.

Quote
Not necessarily. This would probably only happen if the emus that took their place were by anal purists who were not familiar with these formats.

I bet you never had to open a Word document written under Windows 3.1 containing lots of mathematic formula.

Maeson

  • Sr. Member
  • ****
  • Posts: 278
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #14 on: October 12, 2015, 05:22:57 am »
I'm not going to comment about the hack, the ExLoROM or the repro-carts douchebags. I find this entire thing too silly after that long, sad, and kind of cringe-y post entire thread.

I'm here just to say DKJM2 may be Dai KaiJuu Monogatari 2. The sequel of what we know as Super Shell Monsters Story (title given by Dynamic Designs' translation).

The reason for being mentioned alongside ToP or Star Ocean is because has some ties to DeJap.

http://dejap.eludevisibility.org/projects.php

Mostly because something related to a fix. But I don't know anything more than that.
« Last Edit: October 12, 2015, 05:32:01 am by Maeson »
I'm off for some time. If for some weird, strange, and important reason, you need to talk to me, just send me a PM and probably I'll read it whenever I come back.

FAST6191

  • Hero Member
  • *****
  • Posts: 2626
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #15 on: October 12, 2015, 05:37:12 am »
I missed out on the delightful thread others are referencing, however I did eventually read it all after the lock. puzzledude had some very strange ideas that only got stranger as that one went on.

I was linked http://sm64-hacks.square7.ch/?p=97 a while back around here which was a very amusing read to me.

I mainly come from the GBA and DS world where to the best of my knowledge there are no emulator only hacks (the hardware was pretty accurately emulated from day 0 really owing to leaked hardware docs ahead of time), give or take what people might have done with the Lua supporting emulators. Some say that non hardware support is outside the scope of RHDN and maybe it is, the Lua folks I would strongly argue to not be tarred with that brush and welcomed as any other hackers/skilled types might be.

For me the GBA and DS probably represent the pinnacle of 2d game playing hardware, though the SNES (and NES if you like the 8 bit aesthetic) is certainly no slouch and some of the software defined libraries that the PC can and does do these days utterly eclipse both -- https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true is a great read and covers the hardware developments that made for the differences. Ultimately they can and do have means to create fantastic games that hold up today. The N64 hardware was questioned at the time ( http://www.actsofgord.com/Propaganda/chapter02.php ) and time has not been kind at all and to that end I can support emulator only/emulator enhanced stuff there. Some of the N64 (and GC/Wii, possibly also PS2 but I have not gone deep there) folks have some very odd ideas -- the 800 meg texture replacement hacks that are just for translation purposes where about hour 2 of learning ROM hacking would have covered text systems and also spared the troubles with a branching storyline... but that is something I can treat as an unhappy accident.

Emulator only as some kind of anti repro measure... fuck that, possibly with the proverbial rusty spork. You want to put up screens saying "if you paid for this you...", protect those screens by in hardware capable technical means (so probably some kind of checksum or simple compare check), put in text in the game saying the same, possibly have your own kind of anti piracy game breaking/tweaking thing (enemies 10 times harder, no rare drops....), some kind of hardware capable obfuscation (I have seen people trash lookup tables and rebuild them during runtime)... it is all good. If you get in the way of cheat making/game tweaking I might not be happy but eh really and that one is on you. I do not really share the near visceral dislike that some around here seem to have for it, though at the same time if you want to document messing with their auction listings, hosting, the results of adding late game traps in code, laughing at the poor understanding of electronics and inflated egos (some seem to think they are doing good electrical engineering, I content my blind monkey with the alcohol shakes could do most of what I see for the NES and SNES stuff, some of the more modern GBA stuff you might need someone versed in basic electronics repair though) then I will be there with my popcorn and a high five, and similarly I am not going to be caught helping them excise said protections/frustrations.

Back towards the topic the option to expand the ROM is one I would have to accept as nice -- again I come from the GBA and the GBA has 32 megabytes of directly memory mapped ROM (no mappers, no banks, no windows -- all there directly in CPU/standard memory bus in every dumped game*), the average GBA game is 16 or less. The DS is even better (worse?) in that you can expand a ROM into the gigabytes and probably not so much as have to know what a pointer is, if you want to expand a sub file to the large sizes you might have trouble as some do use 16 bit pointers for internal sizes/locations but that is still not usually that troubling (if you are adding megabytes of text you probably already know what you are doing, and if you are adding megabytes of graphics you will probably have run out of VRAM long before).
The NES and SNES used hardware driven expansions at the time though and though space might not be such an issue if you know what you are doing it is far from unheard of for it to be one. To that end I have to at least consider how emulation and modern electronics (my $10 arduino would probably trounce an expensive 1990's FPGA and certainly the CPLD or PAL chips of the day) might help matters of expansion. On the other hand getting people to agree on a header format or other software defined things is a pain so I hold no hope of any hardware based/implementable standard coming to pass.
When most spoke of such things before it was usually dealing with either bugs or less strict emulation -- assuming you had what is basically an infinite stack to shuffle graphics or audio into for the SNES I believe it was. You want something like that and it is lua or equivalent or nothing for me.

*shrek and shrek 2 came as full films under the GBA video banner and those are undumped, they are presumed to be using some kind of bankswitching as the other (32 megabyte) GBA videos are considerably shorter than a full film. Likewise some homebrew could break the limit with certain flash carts (pogoshell if you want to go looking). In the end though nothing that really matters. I probably should mention Mother 3 though and say it is probably the only game, unless some new beta for something gets unearthed, that uses all the space and does not have a generous amount of padding available to play with (the 32 megaabyte, or 256 Mbit if you go around in GBA circles, list is short enough that I have looked at basically all of them in some capacity).

To further confuse my position, or make it more complex if you are being nicer, then for the most part I am all about the results from a game playing/game theory perspective. Some have something of a wary disposition when it comes to tool driven hacking, and it does send the signal to noise ratio way into too much noise territory, but one of my favourite hacks in general was a tool made one for pokemon* and was kind of a boss rush (it used a starter save to set things off at a baseline) and pretty highly polished at that -- no grinding, no mass of items, just having to know the way to beat things. By the same logic though I have to wonder if something more emulator only could not get something done.

*some around here are not fans of pokemon. I do not like the games (the GBA sported far better "clones" in the form of medabots RPG and robopon to name but two) and have been staff in various forms on GBA flash cart and emulation forums/sites for years so I am pretty sure my dislike is higher.

In the end I am not sure where I sit with regards to expansion. If it is something obvious like you have two extra storage banks but use a 2 bit command to select and thus have two redundant commands that could mean you have four banks then I could probably see my way to criticising most emulators (if you have to have the entire ROM in memory on a low memory system then maybe but those are getting a bit thin on the ground of late -- 512 megs is considered a crazy low amount of memory for a phone after all) and maybe even some flash carts for not including it. I am less keen about someone managing to bolt on some crazy modern ARM or MIPS processor (or I guess a FPGA with a decent gate count), even if the results are pretty cool, and then criticising things. If RHDN wanted to adopt some kind of hardware or lua only policy then that would not be a bad thing, at the same time I am not going to call for that. I will call things that will likely not ever be playable in hardware poor form though.

So as ever I have waffled for far too many paragraphs and at best my contribution will have been to link up some sites that see people have a wasted morning in reading them, though acts of gord is far more amusing than tvtropes or wikipedia for that one.

obscurumlux01

  • Full Member
  • ***
  • Posts: 168
    • View Profile
legalities are not the topic
« Reply #16 on: October 12, 2015, 11:36:02 am »
@AWJ:
Thank you for clarifying a way to 'protect' games but without requiring custom emulator builds or other shenanigans.  Awesome.  I knew there was SOME way to do it but you've provided some fantastic insight.  Thanks!

@tryphon:
I don't mind 'emulator only' hacks becoming a thing as long as the standard is standardized among all emulators (or all except Higan I guess).  I would see 'custom mapper support' as something that could be seperated into additional files if needed (or a custom fork of the original).  In fact we already have a precedent for this in FCEUX-mm (mappers modified) being forked from the original.
With the way SNES emulation has gone, I don't see a new SNES emulator coming out to replace SNES9X anytime soon.
Despite both emulators being open-sourced, we haven't yet had many notable 'forks' of the emulators in years.  I've been following the SNES9X Git repository and it is just a bunch of Pull Requests and Issues being posted but not much else.  Activity is there but sparse.

@Others:
Spoiler:
In order to keep on topic and prevent the thread from degenerating into stuff like 'that other one', let us not have the 'legality of ROM hacking' discussion in this thread.  That can be seperated into another thread.  Fair enough?

I'd rather have an open discussion about the formats and mappers and emulation rather than about feelings towards 'that other thread'.  Let's do our best not to get this thread locked :P

The best way that I see to get extended/custom stuff added in is to either FORK the original repository AND KEEP THE CODE OPENLY ACCESSIBLE AT ANY TIME (which is what GitHub and other source code respositories do pretty well) or to submit a PULL/MERGE request where you submit patches/updates to the original code for approval by the original authors of ZSNES/SNES9X.  I'm not aware of continued public development on ZSNES but I do know the SNES9X public GIT repository is still taking requests from well-intentioned authors even if such development is slow as molassas sometimes.

My main gripe with custom emulator builds is that they aren't open-source and do not have the source code publically accessible on a website like GitHub.  We have to download and open files on our computer (risking possible malware if they are malicious) under the guise of 'included source code'.  It is a lazy way to do it.

On top of that, the custom emulator builds included in 'that hack' did not even bother to include the full source code (as required by the GPL) so they are already in violation of that license.  I flagged that hack and the 'Best Hack Ever' for Super Mario World since both are emulator-specific hacks.  But politics extend to the moderation team as often as they do to the people posting and I find that a discouraging way of running things.

I'm all for requiring custom hardware chips (like the MSU-1) that are already included in certain flash carts for play on real hardware.  The thing is that having standards goes a long way towards current AND future compatability.  If we can come to some kind of agreement on accuracy-compatible ways to discourage carting (like you'd have to construct your own custom chip above a certain size like AWJ mentioned) then I'm all for that.  There are ways to do things that don't break accuracy so I hope we can hone in on those rather than custom emulator builds.
« Last Edit: October 12, 2015, 01:38:53 pm by obscurumlux01 »

Disch

  • Hero Member
  • *****
  • Posts: 2746
  • NES Junkie
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #17 on: October 12, 2015, 01:06:43 pm »
Warning... Incoming rant:



Emulating a system faithfully is hard.  Very hard.  But it's also very important -- and is ultimately the goal of any emulator.

Adding goodies like savestates, graphics filters, etc is also important, as they are pretty much expected of any emulator these days.  Plus they're largely non-invasive, so they can always be slipped in as an afterthought.

Adding advanced features like debuggers, memory viewers, etc are much more invasive, and not quite as important from an emulation standpoint -- but are hugely important from a ROM hacker standpoint.  Where would NES ROM hacking be without FCEUd / FCEUXD / FCEUXDSP / FCEUX?  That emulator pretty much became the standard 'must-have' tool for any NES ROM hacker.


Long story short, there's a lot of work on an emu dev's plate.  Console hardware, cartridge hardware, special on-cartridge chips, timing and syncing the various systems and subsystems, basic feature addons, advanced feature addons.... the list of things that need to get done goes on and on.  Getting any part of it wrong causes games to break.  If you want compatibility, you either have to be extremely diligent, or build dozens of game-specific hacks into the emulator.

NES emulation has reached the point where diligence has resulted in extraordinarily high compatibility.  Few emulators in use today rely on game-specific hacks -- games work simply because the emulators do a great job of simulating the system.

SNES emulation is close -- and it certainly has come a long way in the past few years -- but people are still clinging to old, hacky emulators (ZSNES/SNES9x) partly out of familiarity, and partly because the technically better emulators (BSNES/Higan) are not as friendly to use.  Granted ZSNES and SNES9x are certainly not nearly as hacky as they used to be -- but compare them to something like Higan and their accuracy is pretty flimsy.

SNES emulation is sort of in the transition period that NES emulation was in about 13 years ago.  The predominate emulators in use aren't great, but people are still using them... despite there being better alternatives.  For the NES it was NESticle, for the SNES is ZSNES/SNES9x.  The emus have simply been around so long that everyone uses them.

And at the end of the day... the average emu user doesn't really care how accurate an emu is as long as it runs the game they're trying to play.  What those users don't realize is how important emu accuracy is not only from the perspective of emulating the system, but also from the perspective of creating better emulators.  13 years ago people were satisfied with NESticle -- sure it wasn't perfect, but it ran the games well enough.  So why bother with making anything more accurate?  Fortunately, emu devs realize the significance of accuracy, and as a result, we have emulators like NEStopia which are damn near flawless.

Even efforts into creating more accurate emus can improve existing emus.  ZSNES and SNES9x have both improved greatly over the past couple of years largely because of BSNES and Higan... and the work byuu, blargg, and others have done into researching the hyper-technical details of system operations.

So yeah... accuracy is important.  Arguably the most important thing in an emu.  Even if end users don't realize it.  The natural progression of emulation demands that emus either get more accurate over time... or their respective community grows stale and irrelevant.






So when I see ROM hackers swinging their dick around saying "we've developed a new 'standard' that every emulator should support because we don't like the limitations of SNES hardware." --- and seeing them hack up already hackish emulators to support their 'standard'... it makes me throw up in my mouth a little bit.  It's taking emulation 5 steps backwards.

Emu devs have enough work on their plate.  They shouldn't have to keep up with the whims of whatever bullshit 'features' ROM hackers fabricate to make their hacks non-conformist.


Vehek

  • Full Member
  • ***
  • Posts: 178
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #18 on: October 12, 2015, 01:50:38 pm »
First, you're wrong about the sfc thing. The ROM needed to have an sfc extension otherwise the patcher wouldn't accept it. It had nothing to do with the zip. If it had, I would remember having to rename it to extract it.
*Sigh*. We shouldn't be starting this debate up again, but as the one who mentioned the ZIP thing in that thread, I feel like explaining it. It has nothing to do with the format of the source file, and I don't think xdelta cares anything about file extensions, only checksums. The patch turned a Zelda 3 ROM into a ZIP with a lot of pre-padding that hides its ZIPness by pushing the PKZip header down and inflates the filesize to reach the 8MB mark. Knowing how to either extract it out or just renaming the patched file, it seems to boot up just fine in snes9x 1.53. It's not really even 8 MB, just 6.

obscurumlux01

  • Full Member
  • ***
  • Posts: 168
    • View Profile
Re: ExLoROM & ExHiROM & extra emulated mappers discussion
« Reply #19 on: October 12, 2015, 01:52:51 pm »
*snip*
Gonna ask a few things here since trying to ask byuu on his forums is just asking for trouble (and another ban).

-I already know ZSNES messes up audio, but outside of that how would it be 'hackish'?  Byuu mentioned how ZSNES 'cheats' with the way it does audio but I haven't heard much else.

-How is SNES9X a 'hacky' emulator?  What does it get wrong?  I'm geniunely curious about this since I thought it was focused towards improving accuracy as well.

-BSNES no longer exists and is no longer supported (officially).  It is all wrapped up in Higan (which just came out with v095 recently).

The biggest problem with Higan for me has been 2 things; poor speed and unnecessary complexity.

The poor speed is pretty well known.  I used the 'Accuracy' profile in Higan and could barely run Chrono Trigger at a playable speed on my beefy 3.2 Ghz AMD Phenom II with Nvidia GTX 560 Ti.  Well and above what I should need for any emulator but Higan isn't satisfied.  I then tried again with 'Performance' profile and got a playable framerate but with audio issues.  I then messed with 'Sync' options until I got the results I liked but even then it just FELT wrong.  Delayed input, off-key audio notes.  It felt like I was playing on an inferior first-generation alpha-quality emulator than something that has been in development for YEARS.

The unnecessary complexity revolves around the use of 'Game Folders'.  I get the idea and it seems OK but too much stuff is up to the end-user to manually do certain things instead of just clicking OK and having things work like other emulators with all the fluff happening automagically.  I shouldn't need to use a seperate utility to manually extract the ROM and create a manifest file for each and every ROM file that I have.  I don't want to have seperate game folders instead of a few emulator-specific folders and the ROMs.

This obtuse complexity is what will relegate Higan to the extreme end of the enthusiast market rather than anything that non-techy people will bother to use.  It falls into the same boat as Linux distributions used to have about a decade ago.  It was BETTER and it was awesome but NOBODY used it because it was too obtuse.

It wasn't until Ubuntu ushered in the age of user-friendly distributions that Linux distros have finally become not only standardized but actually popular enough to support gaming through Steam.

So before anyone talks about Higan, let it be clear that it may as well be a tech demo of an emulator for all I care :P

*snip*
You and SunGod need to take it to another thread or to PMs to continue your discussion on that issue.  Please.  Let's not get this thread locked due to back and forth over unnecessary fluff in 'that thread'.  Thanks.