People here might also be interested in pwndbg, which adds a lot of qol improvements to the typical gdb/lldb experience. Including splitting dialogs over tmux panes, a lot more context info added to debug lines like where do pointers point to. Heap inspection. Colorization. makes for a much more friendly debugging experience.
re Dune 1 and 2 in same year: At some point Dune 1, developed by Cyro interactive, was officially cancelled and Westwood (so a totally different studio) got a crack at developing it. But it turned out Dune 1 kept on getting secret funding as well, and wasn't cancelled when the higher ups found out. So we were kind of lucky to get both of them.
a) thats awesome
b) I am taking a wild leap in deducing you're the same retro-games Benj Edwards journalist that was part of the infamous Retronauts East team. Just wanted to say i always quite enjoyed your presence :)
Yosys, the underlying compiler of ice studio, also targets the much bigger ECP5 FPGA, also by Lattice, which is called Project Trellis: https://github.com/YosysHQ/prjtrellis
Yosys functions more like a software open source tool. So command line compiling. It also has a REPL. It is very quick compared to the commercial solutions. Especially around compile times which can take seconds instead of minutes. YMMV, but I think the consensus is that it's a lot more convenient to use.
In general the hardware toolchains feel very ancient compared to software toolchains.
In Emacs you can set up Python in a (quite neutered) similar way. Whenever I change a function, I just evaluate the whole buffer to load it in the attached Python process, and will switch over to the Python process to play with it if need be.
I've gotten into GBA homebrew again recently. The community is small but getting a bit bigger. gbadev on Discord is a fun place to hang out.
The tooling doesn't seem to have changed all that much from back in the day, which isn't a bad thing: the best way to get music on the GBA is still to compose something in an old-fashioned tracker and using Maxmod to import it. Sprite conversion tools haven't changed that much.
Programming it is just so lovely bare-metal: poking/prodding registers, writing backgrounds and sprites into memory regions.. Really fun stuff.
I've got a Micro (well, two actually). It's super-cute, but the screen is just too tiny for me to be comfortable. You really need to strain your eyes a bit too much.
It's certainly not trivial, but still an interesting journey. I made a backend for MMIX, heavily influenced by the risc-v implementation, and kept the patches logically consistent by rebasing new changes to serve as an example. The last rebase was a year ago, but I think following a previous implementation is the best way forward as there is so much boiler-plate:
- https://github.com/stuij/mmix-llvm-support
- https://github.com/stuij/mmix-llvm-backend
That said, those kind of olden CPU's aren't a terribly snug fit for LLVM, due to their peculiarities. You'll have to bend LLVM quite a bit to bend it to your will, which also means that you need to get quite familiar with it as well.
LLVM folks have actually just started on such tooling: CIRCT. With Chris Lattner at the helm, and industry players like Xilinx and Intel seemingly on board.