> Did you know that you can’t write to video memory on the Game Boy Advance in units of 8 bits, and if you do, it’ll still work but all your graphics will be messed up with no obvious way to figure it out unless you read one specific paragraph of the documentation? Hey did you know that when you compile a binary optimized for size, memory copies will be by units of 8 bits, but not if you use debug mode?

Andrew (or any Zig mavens) - What would be the idiomatic way of solving this issue? Can you define your own memcpy with @std.mem.doNotOptimizeAway or something?

Oh look, small world!

I will also say that starting to use Linux in earnest around the age of 20 was a very humbling experience having been raised on Windows. Back in the 00s being able to deal with Microsoft esoterica by way of registry hacks and MMC snap-in wizardry meant that you were a "smart computer kid" that non-technical folks found impressive. It wasn't until I started using an OS that acted more consistently and predictably that I realized I'd been building a career (and decently-sized ego) out of Microsoft-specific make-work. Being freed up to learn more timeless and universal concepts lined up perfectly with my college coursework centered around writing shells, compilers, etc. and completely changed how I interacted with computers for the better.

Apropos - if I ever win the lottery and don't need a job I'm going to spend some time learning Plan 9. Superficially it seems to be Unix without many of the warts combined with some concepts from NT/VMS that make good sense.

Python is actually relatively easy to set up on Windows. (Or at least it was easy to set up on Windows 98 in the early 2000s. I don't know how it's now, or five years ago.)

You just download the official Python installer, and off you go. It even comes with Idle as a reasonably good IDE.

    For better or worse, UNIX has won on embedded and server room.

windows 95 did come with Qbasic for MS-DOS. it wasn't the latest and greatest, but it did contribute to a moderately large online scene of kids making Qbasic games or Windows-like Qbasic GUIs for DOS.

Yet those of us that started to program in the 1980's and older decades, were able to acquire all the required programming tools for Windows.

And we didn't had the Internet to learn from.

Personally I don't get this kind of excuses.

> only interpreter

Hey now, Windows Script Host (WSH) supported VBA and JScript scripts. WSH was installed by default on systems up through Windows 7, I believe. Scripts run though WSH had access to a wide array of APIs -- a lot was possible. The WSH executable (wscript.exe) was also configured to be the default handler for .js files in Windows Explorer.

Also, HTA apps were an option. Write an HTML file, include a <script> tag with either JS or VBA, and you have access to APIs equivalent to a local HTML file opened on IE5, plus some. This was a popular option at one point for powering CD-ROM autorun menus, among other things.

(The company I worked for used embedded HTA in a massive C++ COM app to render some forms where the fields and values had to be dynamic based on data only known at run time. Debugging was horrible until I learned you could inject Firebug Lite into the HTA apps and at least be able to console.log(). It was truly a dark, dusty corner of Windows programming -- of which there were many.)

wow, i also started using linux about 5 years ago due to frustrations with getting python to work on windows

sure, the windows installer is easy enough to get set up, but pretty quickly i started noticing a pattern in most documentation/tutorials.

Linux: one-line setup command

Windows: nothing, or a complicated, multi-step process (that rarely works without hiccups)

wasting my time going down rabbit holes debugging my environment was not as fun as actually writing code

When I was first getting started with programming in about 2008, I found it to be so unbelievably frustrating. Any tutorial I was following would invariably run into something that didn't work how it was supposed to. I would try to find some work around, and sort of would, but it would lead to other unforeseen issues down the line. I finally came across cygwin, and that sort of made things start to work.

Eventually, though, I just installed a linux partition and literally never looked back. The entire ecosystem of everything I was learning at the time (Python, JS, PHP) was set up for unix. Things have improved over time, and obviously WSL is nice, but it's still a pain.

Opposite hot take: one of the main reasons I got into programming was because Microsoft Access made it accessible enough that I was confident enough to produce value even knowing nothing about how to think like a software engineer

In all those years (and in years since) the most-used programming environment was the web browser. But it always gets written off.

I grew up in the MS-DOS era and my exposure to programming was basically batch files too. That and editing CONFIG.SYS.

I started on an Amiga without a compiler, and I've learned my first programming language there.

Then I got my first PC with Windows, and I learned a shit ton on it.

I am sure you had little effort to get your games, didn't you?

If you wanted to code, you would have done the same effort to get what you needed.

Magazines were a thing too...

Cheap excuses, the OS is irrelevant here.

I do have fond memories of batch files, though. I showed my classmates that it only took two lines of batch to make the school library's computers open their disk drives every hour.

I got my start on a computer that booted to a BASIC prompt! :)

Lol when I first had to use Linux at uni, I tried to set up a hard-drive partition and wiped my windows partition. That was a fun day, I knew nothing!

> the only interpreter being fucking batchfiles with no docs… come on…

QBASIC was always there, though?

From Win98 onwards, Active Scripting was there out of the box with VBScript and JScript. From Vista onwards, .NET runtime shipped as an OS component, and it includes C#, VB.NET, and (back then) JScript.NET compilers in the box. Although, granted, no offline docs in either case.

QBASIC.EXE: Am I a joke to you?

How did you find the cause of it?

And interestingly, one of the problems raised in the article

    __attribute__((target("arm")))
    void interrupt_handler() {
        ...
    }

that fancy __attribute output can be achieved quite nicely using a custom pragma/codegendecl -- we did exactly this for the embedded firmware written in Nim at my previous workplace, to get access to some specific features of the ESP32-S3 (things like RTC_ATTR_NOINIT for example)

Natu has an amazing commercial game called Goodboy Galaxy [0]. In addition to the Game Boy Advance version, they've also ported it to Windows and Linux with Xatu [1] (which is also written in Nim).

0 - https://goodboygalaxy.com/

1 - https://git.sr.ht/~exelotl/xatu

This is controllable by customizing TargetLibraryInfo [1] for your target in LLVM. Note, however, that detecting memcpy is always a valid optimization in C, not just in userspace. The C language standard, not POSIX, requires that a function spelled "memcpy" be available.

As a side note, the optimization pass that detects and replaces memcpy is called LoopIdiomRecognize [2]. It actually detects quite a bit, not just memcpy.

[1]: https://llvm.org/doxygen/TargetLibraryInfo_8cpp_source.html

[2]: https://llvm.org/doxygen/LoopIdiomRecognize_8cpp.html

The "correct" thing to do here is to use volatile writes to tell the compiler that they must not be torn: https://llvm.org/docs/LangRef.html#volatile-memory-accesses

> IR-level volatile loads and stores cannot safely be optimized into llvm.memcpy or llvm.memmove intrinsics even when those intrinsics are flagged volatile. Likewise, the backend should never split or merge target-legal volatile load/store instructions. Similarly, IR-level volatile loads and stores cannot change from integer to floating-point or vice versa.

Even in a baremetal/OS context, the compiler is generally allowed to split, combine, reorder, and eliminate memory access however it likes as long as the end result is consistent. Being able to do that is very important for performance and code size, which especially matters in embedded or OS dev -- for example, inserting memcpy calls can save on code size for things like passing a medium-sized struct to a function. The memory model for any reasonably low-level programming language nowadays requires you to specify whenever you actually need memory access that look exactly like you wrote.

The OP suggests:

> I know that this is a long shot, but it would be nice if there was some way to specify how memory in certain address ranges need to be addressed.

The downside to this approach is that the compiler doesn't usually know what address range an arbitrary pointer will acccess; it's not resolved until link-time or often runtime. So this would require dynamic checks around every single memory access, which would kill performance. Thus, the solution is to use volatile loads and stores for any memory ranges that need special treatment.

Even GCC emits calls to memcpy. Even for freestanding nostdlib targets. There is no way to turn it off. I had to implement memcpy because of it. Incredibly annoying.

https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

> The compiler may generate calls to memcmp, memset, memcpy and memmove.

> llvm (which zig is based on)

Wasn't Zig moving off LLVM?

But C/ C-compilers don't guarantee your struct wont have holes (by default), so you may have to do something like __attribute__((packed)) to ensure they are packed structs:

    struct bitmap_file_header
    {
      UWord signature;
      UDWord file_size;
      UWord reserved_1;
      UWord reserved_2;
      UDWord file_offset_to_pixel_array;
    } __attribute__((packed));

  An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit.

  #pragma pack(push)
  #pragma pack(1)
  /* ... */
  #pragma pack(pop)

  #pragma pack(push, 1)

in microcontrollers it's very common to see code generated that creates structs for the registers. They will typically output fields that are a full machine word in size (or maybe in some cases as small as a byte), and individual bits will be addressed with bitmasking (ie `my_device.some_reg |= SOME_REG_FLAG_NAME` or `my_device.some_reg &= ~SOME_REG_FLAG_NAME` to clear it). It is sometimes necessary to be thoughtful about batching writes so that certain bits are set before the periferal begins some process. A trivial example would be:

  port_a.data_out |= GPIOA_PIN_1 | GPIOA_PIN_2;

and

  port_a.pin1 = true;
  port_a.pin2 = true;

You either missed a 't' or an 'i'.

I imagine it must be a real (occasionally Freudian) pain in the ass

ill take bit banging over retooling to a worse pile of software written by clueless idiots every couple of years (muh clout)

its crazy how nice knowing 100% of whats going on is

[flagged]

Regarding the nit: this seems to be so common these days that I'm wondering if it's a bug in a default CSS theme in a popular static site generator or something

should be fixed now

in safari as well

They must have fixed the link, it points to a page with a .gba file now. I would have liked it to point to a page that loaded a js/wasm emulator with the playable game in it.

Check out https://gbadev.net

I'm not a compiler dev and I don't know Zig, but I can think of a couple of things that make this tricky:

- The compiler doesn't typically know anything about memory address ranges; that's the linker's business.

- Even if you taught the compiler about memory address ranges, the compiler often won't know what address ranges a pointer could point to at runtime. For instance, suppose you declare a function that takes a pointer as its parameter; and then maybe elsewhere in your code you call it with pointers to various address ranges. What's the compiler supposed to do, check the pointer value at runtime and branch based on its address range? That's certainly not good for performance or code size.

So we clearly need some way to "color" the pointer type itself as belonging to a specific address range -- a function needs to be able to declare what color of memory it wants to operate on, and it should be an error to pass a wrong-colored pointer to a function. Except you can already do this in programming languages today! Create a wrapper type representing a pointer to a specific type of memory (something like 'struct VramPtr(*mut u32)' in Rust), and define read and write functions that issue volatile writes of the correct type (or even inline assembly if you need some specific instruction that volatile doesn't guarantee).

DS has both 2D tile-based renderer and 3D renderer. You can find many examples of games with tiled graphics. I made a tile map viewer for my favourite DS game https://blog.gingerbeardman.com/2021/04/21/level-viewer-for-...

You mean the early systems like the IRIS 2000?

It arguably fits, because it pairs a 68010 with hardware accelerated 3d graphics. As far as I can tell, it's not quite modern 3d graphics. If you paid for the geometry engine, you did get hardware accelerated transform and clipping. And the framebuffer supported hardware acceleration of 2d polygon. But if you wanted texture mapping, that was all done on the CPU.

I don't think we can consider SGI as having "modern" 3d accelerated graphics until they implemented support for hardware accelerated texturing with the Reality Engine in 1992, long after they switched to MIPS.

Upper right quadrant would be an 8-bit (or maybe 16-bit) CPU paired with a 3D graphics capable GPU. SNES + the SuperFX chip is the closest example I can think of. Similarly, there is the Genesis/Mega Drive + SVP chip.

I can't name a fully 8-bit machine with a 3d focused graphics chip. Maybe there are arcade boards?

N64 is actually Silicon Graphics and it’s upper left.