be negative, no problem - the goal is different - we are foremost developers that like the challenge to get the game back into its source state - its interesting to see on an algorithmic level how the devs got it working at that time with all this hardcore constrains (It's like the joy of an archaeologist unearthing an old wooden tool.) - for many developers gaming was the startpoint of interest in software development, and reversing is the gold-class, all your life long expirience needs to be on point to be able to reach such a goal, maybe hard to understand for non-developers - and only a few people on the world are able to do that (even with LLMs) and developers praise these ones :)
First step was the full reverse to assembler, second step is to convert the assembler to binary equal compiled C code, all this still on DOS until no assembler code is left, then the porting to Linux,Windows will start
Reversing tends to bring in new bugs and its not easy to find all bugs in such old and reversed code - but so far everything seems to work
try finding open bugs if you got version 451.03 of F-15 around combined with Dosbox or a real DOS
I’m not sure you should beat yourself up too much for a Linix* port, emulators are so well supported and ubiquitous, if it works there (not everything does), call it a win!
its mostly the combined work of AJenbo, neuviemeporte and others - my part is very small, fixing some compilation problems with newer compilers and spreading the news
C source needs to get compiled on every platform reachable - that is a must :)
Somehow I’m not that concerned. I haven’t heard of any company but Nintendo trying to assert rights to 1980s game IP, and that’s because they’re still selling those literal ROMs as part of a subscription service.
Would I port such a game and then sell it? No, because that kind of puts a target on your back. Keeping it open source and also noncommercial, I don’t think it’s ever gonna matter.
(Obligatory I’m not a lawyer disclaimer - this is a vibes based comment not legal advice. Obviously copyright is nearly infinite, in theory)
No argument on the latter, but I feel like they also have a 'practical' concern that if they very openly ignored 8-bit and 16-bit 'piracy,' it's conceivable that devices like the Anbernic and Powkiddy ones (that already exist in our timeline) would get sold more in the open and be even easier to get started with. Maybe some parents (say, millennials who want our kids to learn the kind of gaming we grew up on) would rather buy those than a $349 Switch with the $10/month subscription they sell to the selection of 80s and 90s games in Switch Online.
In our timeline of course, those are already easy to get, but those companies cater to the kinds of nerds who flash a new OS to SD cards and download collections of ROMs.
Now, do I think Nintendo actually makes that much money on Switch Online from people who (A) are only there for the retro games and (B) would jump on some "more mainstream" and easier version of retro piracy handheld? Mehhhhhh not really. But someone probably espouses that viewpoint at Nintendo HQ.
You could do “clean room engineering” approach where the reversing agent generates a specification from its findings, and then have a separate agent reimplement the code without seeing the original binaries/code.
You’d just have to make sure the specification doesn’t include actual source snippets (the AI will try this if you don’t specify). Pseudo code would be sufficient I guess where necessary.
Unless you develop your AI agent from scratch or you clone a never-released game, it would be extremely easy for the rightholders to claim that both agents have most certainly ingested the binary during their training phase, since it's well known that the hyperscalers have pirated everything that could be pirated to train their LLMs. Which is why malus.sh is a parody, not a real service.
One should be honest about what one builds. The F-15 project does that: the aim is the reconstruction of the original game, down to the opcodes; on the other hands it requires the user to provide the original game assets.
Reality would disagree. If the models are large enough few legal consequences are to be expected because governments don’t want to lose out on AI investments. And in the US the industry owns the executive, legislative and well, thoughts and prayers.
This creates an interesting problem via the normative power of the present - only people willing to accept the erosion of copyright can partake in the AI economy and since the AI economy has become essentially all growth, money and power rapidly concentrates on these people.
There won’t be a legal reckoning because the regulatory capture is complete - these models are “national security level” too big to fail now.
Tools:
IDA Pro 5 (Freeware) is the last Freeware version able to handle DOS executeables (official available by the ScummVM devs https://www.scummvm.org/news/20180331/) - IDA Pro still supports DOS-stuff with latest release - but not the freeware
or Ghidra - but the DOS/16bit support is sometimes lacky - but the decompiler is builtin
During the build, build.rs uses rustc_codegen_nvvm to compile the GPU kernel to PTX.
The resulting PTX is embedded into the CPU binary as static data.
The host code is compiled normally.
Actually, it does use a union, in both libstdc++ [0] and libc++ [1]. (Underneath a lengthy stack of base classes, since it wouldn't be C++ if it weren't painful to match the specified semantics.)
the .Net environment strongly depends on the runtime-ability of all .Net Languages - its feel like AOT (ahead-of-time/finaly compiled) but its not, so Rust woulnd fit good
so Spice86 helps in translating realmode 16bit DOS code into similar assembler looking like C# code - which got the exact same semantic and behavior but its pure C# - you can then use the normal Visual Studio debugger/IDE to port or extend the code - that is a huge benefit over beeing trapped using >30 years old DOS debuggers, compilers and IDEs for this already very hard work
its to ease the process of rewriting assembler code into high level code by having a highlevel-assembler-code in between
Spice86 is not intended for Binary exact reversing, like with https://www.scottsmitelli.com/projects/cosmore/ or Duke Nukem, ZZT or F15 Eeagle reversing project - these are using the same compiler and try to replicate every byte of the original exe - to prevent any reversing bugs at first - but this is the hardest form of reversing and takes easily years of hard work
