5 ms·

I like this: http://www.romhacking.net/utilities/269/ http://www.romhacking.net/utilities/269/ "Newer versions have been released, however contain poor docume

by shthed 10y ago

I like this: http://www.romhacking.net/utilities/269/ http://www.romhacking.net/utilities/269/ "Newer versions have been released, however contain poor documentation, and removal of features that can be found in v0.06. Version 0.06 is still considered the best version available by most ROM hackers until the author addresses the shortcomings of subsequent versions."

byuu 10y ago
There's a reason I stopped associating with that scene/site years ago. Almost everyone in it is toxic and stuck in their rebellious teenage years. Case in point: http://www.romhacking.net/forum/index.php/topic,21797.html http://www.romhacking.net/forum/index.php/topic,21797.html The newer versions are called bass, and you can compare yourself here: http://byuu.org/tool/bass/ http://byuu.org/tool/bass/ There is full documentation of every possible command, the code is readable by human beings (eg variables are named words instead of single letter abbreviations, C++ is used for more than just the class keyword, there's more than one source code file, I learned how to use the spacebar key in my code, etc), it has a real recursive descent parser that builds a proper abstract syntax tree for evaluations, it has a macro system that supports recursion and conditional evaluation, supports multiple architectures instead of just one, allows the user to dynamically add/change the actual opcode mnemonics used by the assembler (useful as the SNES has games using several strange coprocessors), has no known bugs (as opposed to xkas' that allow native code execution), etc. xkas was written when I had about a years' worth of real programming experience, bass was after over a decade's worth of experience; including experience using assemblers to create code. If you want to know why RHDN users threw a fit about it; it's because I used // as a comment delimiter instead of ; and decided to add a closing marker to defines so you could say "lda {macro}_b", which was impossible with the old "lda !macro_b" because it'd look for "macro_b" instead of "macro". That's really it. That's the whole of why many people there say they'll never use it. The syntax is 99% compatible otherwise. I could link you to posts saying as much, but I really don't feel like browsing their site any more than I have to. SMWC's case is very different: they're all hacking the same game, so they require 100% backward-compatibility with a decade's worth of game patches; and they only make the problem worse as time goes on. This constraint would not apply to new games started on from scratch.
- caf 10y ago
  This is a great illustration of why, once you've got a user base of any size, backwards-compatibility needs to be one of your touchstones. (eg. if you add {macro}, continue to support !macro as well) Sometimes you do find that you've painted yourself into a corner, though.
  - byuu 10y ago
    Certainly, backward compatibility is critical and has always been a weakness of mine. I've always been an idealist there. But in xkas' case, this was code from before I really learned how to program; let alone design a proper parser. This would be like asking for strict compatibility between Linux 0.01 and Linux 3.0. I understand how SMWC became trapped in a cycle of using xkas v06, but any new projects really have no sane reason to be using it anymore. And I'm not even saying, "use bass instead!", there's dozens of cross-assemblers that work much better than it ever did (it would seem that writing an assembler is a rite of passage for ROM hackers.)
    - caf 10y ago
      I wasn't trying to comment directly on the specifics of xkas - I just think this is a perfect illustration of how backwards-incompatibilities that means users can't just upgrade and keep working introduce friction against upgrading, and once you get too much friction significant portions of your userbase will stop upgrading at all. I think this lesson is really valuable in a wider context than xkas. Since you mention Linux, this is why Linus has the "no regressions" policy - if something works on kernel N then it should also work on kernel N+1, so that people can upgrade their kernel and not worry about something breaking in userspace. (I think there is actually a very good chance that an a.out binary compiled for Linux 0.01 would still work today.)
      - byuu 10y ago
        > I just think this is a perfect illustration of how backwards-incompatibilities that means users can't just upgrade and keep working introduce friction against upgrading, and once you get too much friction significant portions of your userbase will stop upgrading at all. I definitely understand and respect your point. In fact, I've lost about 80% of my userbase (about 80,000 users) to older versions (and forks galore) of my emulation software. And that's mostly due to lacking backward-compatibility with older game ROM formats. I've since made efforts to accommodate using older media types, but the damage is done, so to speak. > I think there is actually a very good chance that an a.out binary compiled for Linux 0.01 would still work today. ... seriously?? Jesus. I don't even see how it's possible to produce good software that way. We don't know what we really want until we iterate over the design a few times. At least, that's the way it is with me. My first drafts have never been anything close to my ultimate designs. You should see how amazingly better my GUI abstraction library (think wxWidgets but more like Qt with reference counting memory management and C++11 features) has gotten since the first version. I couldn't imagine being stuck with that first version in the name of backward compatibility. I'd rather be the only user of it than have that first version be it, and be as popular as wxWidgets is today. I mean, I'm very much ashamed of xkas v06, and wish my name wasn't attached to it.

by shthed 10y ago

byuu 10y ago

There's a reason I stopped associating with that scene/site years ago. Almost everyone in it is toxic and stuck in their rebellious teenage years. Case in point: http://www.romhacking.net/forum/index.php/topic,21797.html http://www.romhacking.net/forum/index.php/topic,21797.html The newer versions are called bass, and you can compare yourself here: http://byuu.org/tool/bass/ http://byuu.org/tool/bass/ There is full documentation of every possible command, the code is readable by human beings (eg variables are named words instead of single letter abbreviations, C++ is used for more than just the class keyword, there's more than one source code file, I learned how to use the spacebar key in my code, etc), it has a real recursive descent parser that builds a proper abstract syntax tree for evaluations, it has a macro system that supports recursion and conditional evaluation, supports multiple architectures instead of just one, allows the user to dynamically add/change the actual opcode mnemonics used by the assembler (useful as the SNES has games using several strange coprocessors), has no known bugs (as opposed to xkas' that allow native code execution), etc. xkas was written when I had about a years' worth of real programming experience, bass was after over a decade's worth of experience; including experience using assemblers to create code. If you want to know why RHDN users threw a fit about it; it's because I used // as a comment delimiter instead of ; and decided to add a closing marker to defines so you could say "lda {macro}_b", which was impossible with the old "lda !macro_b" because it'd look for "macro_b" instead of "macro". That's really it. That's the whole of why many people there say they'll never use it. The syntax is 99% compatible otherwise. I could link you to posts saying as much, but I really don't feel like browsing their site any more than I have to. SMWC's case is very different: they're all hacking the same game, so they require 100% backward-compatibility with a decade's worth of game patches; and they only make the problem worse as time goes on. This constraint would not apply to new games started on from scratch.

caf 10y ago
This is a great illustration of why, once you've got a user base of any size, backwards-compatibility needs to be one of your touchstones. (eg. if you add {macro}, continue to support !macro as well) Sometimes you do find that you've painted yourself into a corner, though.
- byuu 10y ago
  Certainly, backward compatibility is critical and has always been a weakness of mine. I've always been an idealist there. But in xkas' case, this was code from before I really learned how to program; let alone design a proper parser. This would be like asking for strict compatibility between Linux 0.01 and Linux 3.0. I understand how SMWC became trapped in a cycle of using xkas v06, but any new projects really have no sane reason to be using it anymore. And I'm not even saying, "use bass instead!", there's dozens of cross-assemblers that work much better than it ever did (it would seem that writing an assembler is a rite of passage for ROM hackers.)
  - caf 10y ago
    I wasn't trying to comment directly on the specifics of xkas - I just think this is a perfect illustration of how backwards-incompatibilities that means users can't just upgrade and keep working introduce friction against upgrading, and once you get too much friction significant portions of your userbase will stop upgrading at all. I think this lesson is really valuable in a wider context than xkas. Since you mention Linux, this is why Linus has the "no regressions" policy - if something works on kernel N then it should also work on kernel N+1, so that people can upgrade their kernel and not worry about something breaking in userspace. (I think there is actually a very good chance that an a.out binary compiled for Linux 0.01 would still work today.)
    - byuu 10y ago
      > I just think this is a perfect illustration of how backwards-incompatibilities that means users can't just upgrade and keep working introduce friction against upgrading, and once you get too much friction significant portions of your userbase will stop upgrading at all. I definitely understand and respect your point. In fact, I've lost about 80% of my userbase (about 80,000 users) to older versions (and forks galore) of my emulation software. And that's mostly due to lacking backward-compatibility with older game ROM formats. I've since made efforts to accommodate using older media types, but the damage is done, so to speak. > I think there is actually a very good chance that an a.out binary compiled for Linux 0.01 would still work today. ... seriously?? Jesus. I don't even see how it's possible to produce good software that way. We don't know what we really want until we iterate over the design a few times. At least, that's the way it is with me. My first drafts have never been anything close to my ultimate designs. You should see how amazingly better my GUI abstraction library (think wxWidgets but more like Qt with reference counting memory management and C++11 features) has gotten since the first version. I couldn't imagine being stuck with that first version in the name of backward compatibility. I'd rather be the only user of it than have that first version be it, and be as popular as wxWidgets is today. I mean, I'm very much ashamed of xkas v06, and wish my name wasn't attached to it.