Zoinkity

As it's long divorced from the original distro, here's the readme for the TWINE SED bugfix and what the password does:
https://pastebin.com/Q2FJbywe

@KingMike TWINE protos are quite different internally (as in code), but assets are only additive. SED's big difference is more color depth and polys. Later protos & retail reduced poly counts and replaced ci8 images with ci4. Noticeably worse, probably unnecessary, but there you have it.
This late proto is from PAL localization, but the NTSC pre-release demo not included here had a couple different characters including a bikini Electra. Otherwise, near identical. Still cooking up a way to get the root debug menu going...
SED differences were discussed a bit on the now-defunct AssemblerGames forums. Labyrinth had a gazebo, the sub pen was incomplete, can't remember much else.

Actually, there was a different dedicated emu for KI/KI2 ages ago. That the games were playable on a Pentium 2 should be a good metric, especially since MAME on the same computer stuttered along the intro unplayably when it didn't outright crash. Would be neat to see a modern iteration of it.

Pretty sure the same project released some tools for extracting images, maybe other data from the files as well.

If it were a reprint of the 2001 game that would be a different story. That was pretty low run and didn't sell terribly well at the time, but it's a really great conversion and fun to play. Absolutely treasure my own copy.

It wouldn't be surprising when the VG industry finally runs out of heads to lop for Nintendo to start licensing & producing the GB line again, taking advantage of the growing homebrew scene. Not likely, but also not surprising.

Until a TV tuner mod is made sticking to an original GG thank you very much.

What's more, in this particular case it was plagiarism.

I was one of your few sales back then!
Absolutely great game, still have and play it. All the work really was worth the effort.

@TransmitHim The company they licensed the title from may not have sourcecode anymore or it may not be buildable. A lot of reasons for that. Not everything was done in-house, old DATs are tricky to recover, missing parts of the build environment, they might not have archived the project, etc.

In those cases you need to hack the existing binary or decompile it. Decompilations often take months and are overkill for simple translations. Effectively, you're documenting every blasted bit of code and resource in a game. A programmer would need to work from a decompilation but frankly, it's rare that's ever necessary.

Programmers don't necessarily know how to hack. It's a fairly different skillset requiring lower-level knowledge specific to your target. How many actually look at the code their compiler outputs?

Won't fault them on that front. They are in a position where they can't identify plagiarism on their own though. and...
You are dead-on the second point: a second translator who reviews/tlcs the final product would have caught 1) the mention in the credits and 2) any lack of original script dumps. Might not be possible though on budget. These are low run for a small audience. Doesn't seem there's a debugging team that tests gameplay either.

@LuigiBlood If they're being honest about the explanation at all and haha, there's no blasted way that's true. Anyone lazily copying a translation wouldn't be beyond a copypasta rant from 20 years ago.

To be fair, pointers were a solved problem 25 years ago too. You only mess with them directly if you're doing something "not sane" like overlaying multiple memory ranges.
Even if they were using DOS (there was an ancient Word for DOS, but lol) why not just use qbasic to calc them for you? Or there was that fad with using excel formulas to straight up build ROMs. Any sane person nowadays would java or python a list of strings & locations, have it spit out pointers with a warning if you roll over bounds.

Basically, they were caught with their pants down. The proper response is : "Well, s***. I had deadlines and didn't think anyone would notice. Sorry about that."

So, let's get cynical!
Sometimes you want to cause a lawsuit. Doesn't seem Anbernic is willing to do that yet, but guarantee somebody will--and fail.

There's a long history of companies that do pirate distribution to effectively settle the suit with the copyright holders by becoming their legitimate distribution service. The single best known case internationally is by all accounts the first: Napster.

It won't work in the VG marketplace, not realistically. You'd be seen as inferior competition to existing services targeting off-brand products and a direct distribution license competitor. Remember that Nintendo, Sony, M$, etc. still need to obtain distribution licenses themselves. As an example, all Speccy ZX stuff is publicly-available except Ultimate Play the Game titles who refused to release their licenses.

The viable way to get the ball rolling would be to aggressively seek to manage licenses for defunct studios, then push for public domain when those entities no longer exists. Build a competing portfolio to make a competing distro service tied not only to your products but available at a cost to the big names that would sue you when you take it too far...intentionally,.

Krokodyl did a great job on the RE and comparison work here. Thanks!
Translation work is an iceberg. The text you see at the top hides the other 80% of work involved to store and print it. There's no one solution to that, or even an optimal solution. When you're rewriting code, writing a codec, doing original image work, reworking existing resources, choices on reshuffling and reorganizing, your choices are very much your own. Implementation is rarely repeatable. It's almost a personal signature. I'm glad to see someone use that as the metric for comparison.

It's funny where simple games like Pang get bundled up. One place is the first Bomberman Land PSX game and its counterpart Bomberman64 on the N64, both Japanese exclusives.

@smoreon Oh no, this game eats memory more than most. The intro alone is ~6MB. These animations are largely full-screen keyframes, crossfaded, with some additional elements on top of those.

The trick is TLB entries don't have to point ram to ram and multiple virtual things can be mapped to a physical range. That's only on N64 though. These are all extra hardware on an Aleck64.

@guy-man The "original" Japanese .n64 is also a conversion...
Didn't have a problem with the Mayjinsen3 translation though?

Anyway, it works via USB so the culprit is in the menus.
The original conversions only ran because the intentional fault in IPL3 was ignored, so guessing there's an extra bit of code making that happen. They'll surely sort it out sometime in the future.

@guy-man
The menu probably doesn't recognize the 5101 CIC yet, so use the command line thing via USB:
sc64deployer.exe upload -t eeprom4k -s eep.bin --cic-seed 0xAC srmvs.n64

@smoreon
E92 boards have 8MB of rdram plus 4MB of sdram (slower, limited access, kinda like GameCube) so you fraud that using TLB entries, like all the other fun hardware it supports. The whole thing is a magic act, honestly. All the conversions work this way.