Well, seeing as somebody's already pinned me for this, I guess I might as well own up! I (Andrew Church) was the one who wrote this, way back in late 1997, as more of a free-time project than anything else. I have no idea where the comment about "thumbing my nose" comes from, because I was certainly never approached by anyone, and in fact I had only mentioned it to Andrew Vestal at the time; I didn't "look down" on the scene so much as I was simply uninterested in it. I probably would have just left the project sitting around, but when I casually mentioned it to a couple of friends later on, they encouraged me to put it up somewhere. So I went back, touched up the translation a bit, wrote a quick patcher program to apply the changes, and there you have it.

Re: the 1-megabyte size and Dragon Warrior IV, it looks like some old bit of (incorrect) folklore stuck with me through the years, and I seized on it when explaining the size change in the README file. In all honesty, I never even thought to check it out. (: Mea culpa. That said, there really isn't enough space in the 512k ROM for a proper translation, so I stand by my decision (and would probably have turned down the job if I'd had to do it on real hardware that couldn't support more than 512k).

Hell man, I'm still impressed that you went and expanded the ROM, back when common ROM hacking knowledge prevailed that expanding NES games was next to impossible. It looks great, and it's a hell of an accomplishment, and I'm glad you sent it out to me way back when. Sorry for the lengthy turnaround. ;)

And hey, at least it works in NESticle. :D

You're not a fan of data compression? You somehow think data compression is a kludge? Perhaps you thought he was talking about squishy tiles or something. Imaging a technological world without the advent of data compression makes me sad.

Well, that's one way of looking at it. But it didn't stop Square-Enix from using it in the SNES and PS1 era.

I certainly don't approve of pointless bloat, but I also don't particularly enjoy trying to squeeze every last byte out of a program. Sure, as a sort of puzzle to solve it can be fun, but there are too many other fun (and more productive) things I could be doing instead. I suppose that's part of why I never really became interested in the scene. (:

It's not even squeezing every last byte. Simple compression can yield you savings of 50% of more. You exaggerate the complexity. You could add dual character or dictionary compression in say 10-20 lines of code. Possibly less depending on the game. I'd hardly call it kludge. I'd call it smart programming instead. Dictionary is an over glorified pointer swap trick when it comes down to it.

Furthermore, sticking in a working compression routine can help you across the board. It can save space on the menus too or whatever else you're doing that may need some type of expansion like this.

I'm sorry, you're supporting evidence for not using data compression is pretty weak. You can choose to not like it and not use it and that's fine, but don't try and argue that it's too complex, bloated, or kludgey. Simplicity or beauty as you like to say can be something as simple as literally few lines of code for bitpacking or RLE. Instead, it appears to be the exact OPPOSITE of the severals definition of 'kludge' on dictionary.com.

Please elaborate how 10-20 lines of organized code of an established algorithm that can save your a large % of space  is inelegant, inefficient, clumsy, or patched together?