asiekierka

I had no issue with the toolchain, as I happened to work on a game (ZZT) whose toolchain of choice was documented by the author himself (well, he was off by one Turbo Pascal release). Lucky!

What took me the most time was actually the beginning: building a mental model of what assembly patterns map into which Pascal patterns, and finding good areas to start writing code from. In hindsight, I should have probably started by generating inline assembly equivalents of each procedure/function. The ending was relatively smooth sailing in comparison, but it is of course much easier if the compiler you're targeting doesn't do much in the way of optimization passes, so it's not representative of decompilation work for more modern targets.

> All no$gba program code, both emulation and user interface, is all hand-crafted and pure assembler code.

https://problemkaputt.de/gba-dev.htm

I think it is more likely that the "amazing" things, as described, will become mundane, thus shifting the definition of what becomes interesting or noteworthy. Even then, I believe people who continue to write by hand will still be appreciated, given this is fundamentally a hobbyist space.

One good example is nocash, who continues to write all of his Windows-targetting emulators in hand-rolled assembly to this very day. For a long time, some of his emulators - most notably NO$GBA - were at the forefront of popularity among homebrew developers due to their unmatched debugging tools; even though one could make them much faster with an HLL, nobody really stepped up to the task. Even now, his work remains relevant thanks to the extensive documentation he maintained alongside the emulators he developed.

Does it being a creative transformation rob the derivative work status? Personally, I'd liken the process of decompilation to that of translating a book from one language to another - the copyright on the original work does not become void merely because the process of translation requires extensive creativity.

Nicalis and Take-Two have both gone after decompilation projects, also. In particular, Nicalis has gone after a decompilation of Cave Story, but not a black box reimplementation of the same, while Take-Two ended up suing a decompilation developer (albeit settled out of court). However, in some jurisdictions, even clean reimplementations have failed - see Tetris v. Xio.

(I am not a lawyer either, etc etc, but that's my understanding)

For whatever it's worth, the one resource I recall for DS homebrew dev with Rust is https://github.com/SeleDreams/libnds-rs , but it hasn't been maintained in a while.

For the sake of public record, I would like to state that I was doing nothing "behind the scenes". My part of the conversation in question is public - I was pinged as a gbdev Discord community member and that is the extent of my "consultancy". I also warned the GBcompo organizer that they should validate the rules' interpretation with a lawyer before trying to justify any requests that go beyond disqualification/delisting, particularly ones where finances get involved.

The comment about "burning bridges" is not a statement of intent, but of observation: if I publicly call someone out on the Internet, and we fail to reach a common agreement or understanding, that bridge inevitably becomes burned - even if I'm correct, even if most people agree with me! It was based on my understanding of how other people reacted to the controversy as it was brewing in community spaces, but I understand now how it could have been interpreted as a threat in its own right.

The reason I made a comment below the post (now deleted as per the game author's wishes) is because I saw him accusing the gbdev community of "censorship" - as such, I wanted to provide full transparency and accountability with regards to my role in the dispute. That was the extent of what I could do at the time, as someone who was never involved in the organization of gbcompo23 or any other gbdev community event and thus had no decision-making powers. I realized later that my stance led to harm. I regret getting involved in this at all, and I regret the things I said.

It is not possible to create a license that would satisfy the Free Software Foundation's "four freedoms" while also solving the issues many of those vendors have with the AGPL. At the same time, the "source available" mindset doesn't have a steward organization like the FSF or OSI.

We already know what the main remaining issue is - LLVM-MOS's register allocator is far from optimal for the 6502 architecture. mysterymath is slowly working on what may become a more sutiable allocator.

Here's a benchmark of all modern 6502 C compilers: https://thred.github.io/c-bench-64/ - do note that binary sizes also include the size of the standard libraries, which means it is not a full picture of the code generation density of the compilers themselves.

> it creates a huge disincentive to those who want to create open platforms since it is going to be nearly impossible for them to get any traction when they are up against jailbroken devices from huge multinational corporations.

I'm not so sure about that. More specifically, I wonder if there are more or fewer Steam Decks in the wild than jailbroken Nintendo Switch units.

> Thing is, GPL requires you to explicitly allow that behavior, so HBC can't use GPL software.

Couldn't, not at the time. HBC has been open-sourced some time ago, sans DRM, as the Wii has long lost commercial relevance beyond enthusiast communities. This open-source re-release is what the repository is.

IIRC, at least a few years ago, Mumfrey had a tendency to develop Mixin in private and only push the commit backlog for releases, leading to periods of time where no activity was publicly visible. (Also IIRC, this is part of the reason why the FabricMC fork exists.)

Doe it literally check for the specific solution?

Writing

    to = append(to, ctrl)

which is functionally equivalent and, in my personal opinion, with clearer intent (ctrl = 0 at that point in the code), returns "incorrect".

In fact, it seems that any placeholder value should work - as it is always overwritten by the final value of ctrl for a given set of bytes at the end; however, the checker rejects this.

The Linux kernel did not even compile on most non-GCC compilers (like LLVM) as recently as a few years ago: https://www.phoronix.com/news/Clang-Kernel-2018

Therefore, for the Linux kernel specifically, I think the only concern is whether or not GCC remains supported in addition to LLVM - as GCC and Clang are, as far as I know, the only two compilers which actually can be used to build the kernel as we speak. There's work being done on both gcc-rs and rustc_codegen_gcc to allow using GCC as a Rust backend, meaning that all platforms currently supported by the Linux kernel should be eventually capable of being supported without porting a compiler backend.

The key words are "optimized" and "OpenGL 4.6 with Zink". "Functional" and "OpenGL 2.1" is a different story, and the same trustworthy source said in https://rosenzweig.io/blog/asahi-gpu-part-6.html that:

> thanks to the tremendous shared code in Mesa, a basic OpenGL driver is doable by a single person. I’m optimistic that we’ll have native OpenGL 2.1 in Asahi Linux by the end of the year.

It's likely that even a bare-bones OpenGL driver will probably run better than llvmpipe, which is especially important in a laptop context due to the resulting power use improvements.

Yes, the Apple laptops need a whole host of proprietary blobs for bringup and firmware.

For me personally, there's a few reasons:

1. It's a kind of code golf - or rather, it's about seeing how much one can squeeze out of a highly limited and fixed platform. Writing this, I think of things like Mahoney's Cubase64 ( https://www.youtube.com/watch?v=PTGkf21UpJ8 ), which uses a combination of skilled coding and creative (mis)use of hardware functionality to perform real-time effects on sampled audio data on the Commodore 64. As the demonstration itself states: "You need 32-bit, 2000MHz, 1GB at least; what if... 8-bit, 1MHz, 64KB is enough?".

2. Creating a game which can stand its own to the platform's contemporaries on an 8-bit ecosystem can be reasonably achieved by a bedroom coder in their spare time. To do so for modern consoles or machines, one typically needs a higher budget and multiple people.

For this point alone, though, there are arguably easier ways to accomplish this. PICO-8, the herald of the "fantasy computer" phenomenon, created a system inspired by 8-bit limitations in graphics and sound, but offering a modified Lua interpreter in place of coding assembly by hand, in an attempt to balance the stack more towards creativity and away from complexity. (And, of course, nobody is stopping anyone from simply making a retro-styled game with modern tools. Many indie games do exacly that. There's two separate "notable" Game Boy jams on Itch.io - one enforces games actually targetting the real platform, the other cares more about matching the look/feel.)

3. The ability to reason about every component of the system down to bare metal is a welcome retreat from writing complex, object-oriented code running on top of stacks on top of libraries on top of runtimes...

In the end, it's a novelty which tickles a particular part of my brain, I suppose. So long as I enjoy it...

For me at least, an AMD/Intel desktop box plus its multi-year power bill still is likely to come out cheaper than a comparable Apple desktop or high-end laptop plus its multi-year power bill. The lower-end Apple laptops are not an option for me due to the "one external display" limitation. Competing ARM desktop hardware is not an option for me due to insufficient performance - I might as well not upgrade at all.

The only world in which fair product reviews lead to no product review units whatsoever is one in which no company ever actually considers their own product to be of quality.

Ultimately, follow-ups are rare because they don't sell - the benchmarks which get referenced are the ones which spread the widest, which are the ones closest to release, which is when usually the most people are interested in a given product.

3DMM was a lucky one, because Microsoft and Foone managed to get sign-offs from the rightsholders of third-party code utilized.

Not even Windows 1.0x, 2.0x, or 3.x got open-sourced. In terms of complete operating systems, we got source code dumps of MS-DOS 1.25 and 2.0, and that was that.

I don't think it's going to happen.

If $30k is at stake, it might be better to spend a little bit more money and ask a professional lawyer.

Drastic had its own, recently open-sourced, reimplementation of the BIOS which claimed to be clean-room.

Regarding image compression, have you considered using jpegrescan on top of mogrify resizing? In my experience, it can shave off a few percent losslessly.

https://github.com/kud/jpegrescan

Presumably it targets the Homebrew Channel, not Nintendo's official methods.

I was thinking specifically of the BBS platforms of the early 90s, not the descendants of Ayashii/2channel.

The page linked was targetted to community oldbies who haven't been around for the last few years and the revival of the scene. If you're new to ZZT, try https://museumofzzt.com/about-zzt instead.

That quote you brought up is referencing, in a veiled manner, a specific time and events in the past of a specific, major ZZT community. The people who were harassed then certainly didn't deserve it. Some oldbies feel guilty, in retrospect, over what transpired in the past - it was wrong then as much as it is seen as wrong now.

Obligatory PSA: If you have any backups of community ZZT game worlds from the 90s and early 00s, please let us know! The past year has brought hundreds of rediscovered worlds, previously lost or not known about, particularly from the AOL era. Unfortunately, we also know there were more worlds on AOL which we don't have backups of, as well as poor coverage of the Prodigy, CompuServe, and other BBS-era communities.

If you have anything, let us know!

The save file check is separate to the SECRET flag, but they are both meant to not be editable. (Of course, community-made external editors like KevEdit lift this restriction.)

For the past 2-3 years, I've been working on archiving many of these games made by the ZZT and MegaZeux communities. I do have to say, though, that the DigitalMZX administrators have already been making attempts to keep track of and locate known lost games for over a decade. As always, however, more hard drive backups and other sources would certainly help find and preserve more works!