{"slug": "what-s-everybody-working-on-september-edition", "title": "What's everybody working on? (September Edition)", "summary": "A developer known as zigster64 published atari.zig, a repository that enables an LLVM m68k backend to produce a bare-bones Zig toolchain on macOS, and used DeepSeek tokens to have an LLM generate a Space Invaders clone against the toolchain's API to expose bugs. The LLM claimed \"miscompilations\" in LLVM and offered a solution, which the developer now plans to verify by examining the LLVM source code to determine whether the m68k backend is genuinely buggy. Other projects in the September roundup include tes3tool, a Zig-based attempt to replace tes3cmd for The Elder Scrolls III: Morrowind ESM/ESP files, and zig-humanize, a near-complete Zig port of go-humanize.", "body_md": "Okies, but be warned the purpose of this repo was to get hands dirty with building llvm and zig compiler variants, and getting more into asm. Eventually it might turn into a nice Atari toolkit, but rough edges as of today\n\nThen did my own experiments and notes to get llvm with m68k backend enabled. https://github.com/zigster64/atari.zig. That gets you a bare bones basic zig toolchain on MacOS, and duplicates the demo from the other repo.\n\nAt that point, the repo is pure hacky time experiments from there on ! Its exploration code in its current state, not a polished toolkit (yet).\n\nThen I used some DeepSeek tokens to ask an LLM to vibeslop me a space invaders clone against that provided api, to prove it’s usable and expose a tonne of shortcomings and other bugs.\n\nNote that the LLM claims “miscompilations” with llvm .. which it did manage to provide a solution for, but it may or may not have made that up ?\n\n.. so now I need to deep dive on llvm source code to see if the m68k backend is really buggy or not, then fix it if true.\n\nWorking on learning more about Zig and lower-level programming with tes3tool: an attempt at replacing tes3cmd for working with ESM/ESP files for The Elder Scrolls III: Morrowind.\n\nI learned programming and software development mostly on my own, and I’ve worked mostly in web development and, honestly, I’m trying to get out of web development. Generally I’ve worked with and taught myself with higher level languages: Common Lisp, Ruby, Python, Elixir, C#/F#, Java/Kotlin, Javascript/Typescript. While I do genuinely like some of those languages, I’ve found myself wanting to actually learn “lower-level” languages like C/C++ and Zig.\n\ntes3tool has been quite the project, especially since most people don’t take much issue with tes3cmd. I really just started it because I couldn’t run the giant Perl script that is tes3cmd on my musl Linux desktop (Chimera Linux) for whatever reason. If you’ve been modding Morrowind in recent years, you probably noticed the modding scene has had a lot of more modern tools come about. tes3cmd is…not exactly modern. I wanted to create a static binary that could be a drop-in-place alternative to tes3cmd, more performant, and easier to extend. I also wanted to make a tool that could be compiled to work on all, if not more, of the OSes and architectures that OpenMW can run on.\n\nAt first I had AI help me start the project, and then at some point I had to stop because I wasn’t learning anything. Since then, I found myself really liking Zig. I like that it forces me to be correct and clear about what the program is doing more than C and C++ do. I also really like not having to link against libc.\n\ntes3tool works on raw binary slices: a Record is just an in-memory slice into the file buffer, and the format specs aren’t applied until a command actually needs the structured/decode form (e.g. dump). tes3cmd decodes every record into an object model during the read pass.\n\nIt doesn’t have 1-to-1 parity with tes3cmd yet, but I’m working on it.\n\nI’d been working on a simple file inspector as a fun way to get deeper into stuff I’d always hand-waived at (learning how file types are determined, for instance). After writing some code to stick comma separators into large numbers when displaying byte sizes, I decided to pause working on the file inspector and instead start porting go-humanize to Zig (zig-humanize), which is now nearly done! (still learning the Ziggy way to approach things, so the APIs etc might change)\n\nI’ve enjoyed thinking through the tradeoffs between convenience and accuracy, determining when to stay close to that library’s design choices vs going out on my own, etc. It’s also been a nice opportunity to read more of the standard library. Even got myself rickrolled in the process!\n\nMade some big progress on our MIDI playing robot since I last posted about it in May or June. My buddy finished up the fixture for our v2 prototype and hand soldered some sweet looking custom PCBs. We have two esp32s (one on each hand) based off this esp-idf zig sample code! Built a half baked solver that will try converting MIDI events into a sequence of move commands and solonoid actuations. There’s some basic “future prediction” baked in so far that tries to move the hand a little over if more notes will be covered by that position in the future.\n\nNext steps are to polish up the solver to try and do some crazier solving strategies and to clean up the firmware to host a small web server for uploading the MIDI files instead of baking the image into the build. Video of the two hands working together is in the readme if you’re interested to see a musical demo!\n\nI’ve been working on Zova this month which I previously posted on here, and I’ve managed to release 1.0.0 version today, I’m proud to carry it to this far! It is an SQLite-backed database that can store vectors,graphs and objects, if you want to check it out or give some recommendations I’d be glad to read, here is the repo: GitHub - ata-sesli/zova: SQLite-backed local storage for records, objects, vectors, and graphs. · GitHub\n\nIt’s running in a WebGL canvas, autogenerates swedish crosswords from so far english and german bundled in databases, and supports serverless Multiplayer using WebRTC and WebTorrent trackers for signaling.\n\nEntire, scalable database in-memory nosql.\nHigh-performance with many clients and it implements batch/pipeline as object, not “abstract network protocol”.\n\nI started a few days ago a little crazy project, related to my earlier work with the DOS lemmings.\nThe idea is to generate random levels for a screensaver and let the lemmings (dimwits as they are) try to get to the exit themselves.\nFirst random level Lots of work to do…\n\nRecently I’ve released v1.0.0 of Meioziz, self-hosted analytics for games and apps.\n\nI use it in production for more than a month – for eight my projects. And it does what I expect.\n\nProduct wise I’ve added cleanup of old daily aggregates. For example, I keep data for the last 30 days only.\n\nCode wise I simplified html-writing functions: use *std.Io.Writer instead of html: *std.ArrayList(u8), allocator: std.mem.Allocator as parameters. And simplified working with allocator — it is defined in fn handleRequest().\n\nThis sounds like the perfect place to use Wave Function Collapse. You model the constraints each piece has, like what can go beside what, then start at a random spot and let randomness loose within the constraints of your system.\n\nI’ve not made a lot of showcasable progress on my game, mainly bein working on the boring stuff, and sharpening my axe stuff. But at work I got the time to start working on an alternative to libcamera written purely in zig\n\n```\nsrc ) cloc .\n      62 text files.\n      61 unique files.\n       4 files ignored.\n\ngithub.com/AlDanial/cloc v 2.06  T=0.03 s (2003.6 files/s, 637841.6 lines/s)\n-------------------------------------------------------------------------------\nLanguage                     files          blank        comment           code\n-------------------------------------------------------------------------------\nZig                             59           1585           1157          16610\nJSON                             2              0              0             67\n-------------------------------------------------------------------------------\nSUM:                            61           1585           1157          16677\n-------------------------------------------------------------------------------\nsrc ) tree\n .\n├──  hardware\n│   ├──  Camera.zig\n│   ├──  controls.zig\n│   ├──  core.zig\n│   ├──  Encoder.zig\n│   ├──  FrameBuffer.zig\n│   ├──  FrameLease.zig\n│   ├──  pause.zig\n│   ├──  platform\n│   │   ├──  debug\n│   │   │   ├──  Camera.zig\n│   │   │   └──  module.zig\n│   │   ├──  failing\n│   │   │   ├──  Camera.zig\n│   │   │   └──  module.zig\n│   │   ├──  ffmpeg\n│   │   │   ├──  Camera.zig\n│   │   │   ├──  H264Stream.zig\n│   │   │   ├──  module.zig\n│   │   │   └──  testdata\n│   │   │       ├──  sample_1280.mp4\n│   │   │       └──  tiny.ppm\n│   │   ├──  v4l2\n│   │   │   ├──  Device.zig\n│   │   │   ├──  dma.zig\n│   │   │   ├──  Encoder.zig\n│   │   │   ├──  h264.zig\n│   │   │   ├──  imx477\n│   │   │   │   ├──  Camera.zig\n│   │   │   │   ├──  Embedded.zig\n│   │   │   │   ├──  Encoder.zig\n│   │   │   │   ├──  Hardware.zig\n│   │   │   │   ├──  ipa\n│   │   │   │   │   ├──  Aaa.zig\n│   │   │   │   │   ├──  algorithms.zig\n│   │   │   │   │   ├──  alsc.zig\n│   │   │   │   │   ├──  awb.zig\n│   │   │   │   │   ├──  ClockRecovery.zig\n│   │   │   │   │   ├──  DelayedControls.zig\n│   │   │   │   │   ├──  hist.zig\n│   │   │   │   │   ├──  module.zig\n│   │   │   │   │   ├──  options.zig\n│   │   │   │   │   ├──  Sync.zig\n│   │   │   │   │   ├──  sync_runner.zig\n│   │   │   │   │   ├──  test_hardware.zig\n│   │   │   │   │   ├──  testdata\n│   │   │   │   │   │   ├──  flat.json\n│   │   │   │   │   │   └──  tuning_min.json\n│   │   │   │   │   └──  tuning.zig\n│   │   │   │   ├──  Isp.zig\n│   │   │   │   ├──  lens_shading.zig\n│   │   │   │   ├──  metadata.zig\n│   │   │   │   ├──  module.zig\n│   │   │   │   ├──  options.zig\n│   │   │   │   ├──  peek.zig\n│   │   │   │   ├──  Sensor.zig\n│   │   │   │   ├──  simd.zig\n│   │   │   │   ├──  stats.zig\n│   │   │   │   ├──  topology.zig\n│   │   │   │   ├──  types.zig\n│   │   │   │   └──  Unicam.zig\n│   │   │   └──  module.zig\n│   │   └──  virtual\n│   │       ├──  Camera.zig\n│   │       ├──  module.zig\n│   │       └──  testdata\n│   │           ├──  tiny.ppm\n│   │           └──  tiny.y4m\n│   ├──  Request.zig\n│   └──  stream.zig\n├──  hardware.zig\n├──  root.zig\n├──  runtime_config.zig\n├──  ustream\n│   ├──  h264.zig\n│   ├──  Packetizer.zig\n│   └──  rtp.zig\n└──  ustream.zig\n```\n\nIt’s going well, my idea is to fix what I don’t like about libcamera, while also being a drop in replacement, the goal is to give the user the full power even racy API exist where you can if you want do stuff in the ring buffer in DMA, but the clock is ticking and if your processing is slower than the camera, too bad. The idea is centered around an Allocator like API, and the library is expected to be a BYOB (bring your own backend). Where basically if you want something you just implement it, expose the Camera, Encoder, Processor interface and you can reuse the rest of the code. Thanks to the interface, I’ve implemented a Virtual camera which uses ffmpeg to loopback video, I’ve implemented a Debug camera which records/logs issues like the DebugAllocator, And I have a Failing camera for testing. This is far from finish and will still need a lot of time and polish.\n\nBut the end result should be a library with an C api if needed, that’s minimal, doesn’t use 3 threads out of the box, gives full power, still uses and parses the calibration.json file that camera ships with, and gives you everything that you need in order to use, and manage cameras efficiently with Zero copy. I also integrated my ustream project to it, in order to send the h264 through the network in order to visually debug it with ffplay.\n\nAnyway still a work in progress, no repo to show for it\n\nOn the note of uniformity, I haven’t seen people mess enough with using a different algorithm to generate more interesting initial constraints! Something I really want to try (but is forever on my backlog of projects)\n\nI’m a total beginner when it comes to web dev, so please excuse my question if it’s naive:\nI see you have no html or css files in your codebase. To my understanding, all of it is generated on the fly in server.zig. What are the advantages of this technique? Is this a standard way of building an application?\n\nThat’s a great question. No, it’s usually not a standard approach.\nCommon practice is to use templates and embed them into binary or put near the binary.\n\nInlining HTML could be used for very small and not changing frequently code.\n\nI chose the second approach because Zig standard library doesn’t provide templating and I wanted to keep external dependencies minimal.\n\nI think it would be more clear to move all of rendering code into separate html.zig, so server.zig would be compact. Alas, in current version some structs from DB-layer are involved and I find it okayish now, but not appropriate for use in html.zig.\n\nI am trying to create a tool to query/stat CIM XML. CIM is used a lot in the (European) (energy) industry and the performance of the existing tools is pretty bad.\n\nSo far, I have only implemented a single feature: making a histogram of the classes in the xml.\n\nFor the architecture, I generate the counting struct during compile time (based on the RDF schema of CIM), plus some slack for extensions and user-defined classes. The (zipped) XML is then streamed in blocks of 512kB and I use SIMD patterns to match elements in the blocks.\n\nI am getting around 5-10GB/s performance on raw XML on my laptop, depending on the order of the elements. It is optimal when elements are placed contiguously per class. Zipped XML is doing around 1.2 GB/s. I am very happy with the result, because I think this streaming design could process even a terabyte of xml with consistent performance.\n\nNow I am trying to crack a harder problem. I want to make a histogram of references between elements.\n\nSomething like this (this is mock data)\n\n``` bash\n$ cmd relate data/*.xml CommonAndBoundaryData/CommonData_and_Boundary_merged.zip\n\nSOURCE                     |  PROPERTY                                        |  TARGET                |  COUNT\nTerminal                   |  Terminal.ConnectivityNode                       |  ConnectivityNode      |  3536\nTerminal                   |  Terminal.TopologicalNode                        |  TopologicalNode       |  3536\nSvPowerFlow                |  SvPowerFlow.Terminal                            |  Terminal              |  2409\nTerminal                   |  Terminal.ConductingEquipment                    |  Disconnector          |  2062\nConnectivityNode           |  ConnectivityNode.TopologicalNode                |  TopologicalNode       |  1192\nConnectivityNode           |  ConnectivityNode.ConnectivityNodeContainer      |  VoltageLevel          |  1186\nDisconnector               |  Equipment.EquipmentContainer                    |  VoltageLevel          |  1031\nSvStatus                   |  SvStatus.ConductingEquipment                    |  Disconnector          |  1031\nSvSwitch                   |  SvSwitch.Switch                                 |  Disconnector          |  1031\nTerminal                   |  Terminal.ConductingEquipment                    |  Breaker               |  878\nCurrentLimit               |  OperationalLimit.OperationalLimitSet            |  OperationalLimitSet   |  482\n...\nPowerTransformerEnd        |  PowerTransformerEnd.connectionKind              |  WindingConnection     |  106\n...\nFullModel                  |  Model.DependentOn                               |  ?                     |  2\n```\n\nHere’s what the input data looks like:\n\n```\n<cim:Terminal rdf:ID=\"_a1b2c3\">\n  <cim:Terminal.ConnectivityNode rdf:resource=\"#_f00d01\"/>\n  <cim:Terminal.ConductingEquipment rdf:resource=\"#_ZZZ\"/>\n  <cim:Terminal.sequenceNumber>1</cim:Terminal.sequenceNumber>\n</cim:Terminal>\n\n...(could be millions of elements later, in any order)...\n\n<cim:ConnectivityNode rdf:ID=\"_f00d01\">\n  <cim:IdentifiedObject.name>CN_123</cim:IdentifiedObject.name>\n</cim:ConnectivityNode>\n```\n\nThe problem is that each element references the ID of another element, not its class, so we cannot directly count from here. While streaming through the XML, we do not have a map yet which class each ID belongs to. So, we have to build that map while we go through the XML.\n\nOne solution would be to make a conservative guess of how many bytes per class in the text (e.g. 64 bytes per instance), and allocate memory based on the file size stat during initialization, but I felt that this would allocate gigantic amounts of memory in an imprecise way (the mapping would be from u128 to u16, so (if I am correct) 16 + 2 = 18 bytes per 64 bytes, so a pretty large fraction of the original size of the XML.\n\nBut something irks me in this design as it could potentially lead to gigantic memory allocations when files are very large. One idea is to write this to disk to reduce memory pressure, which perhaps is even worse.. so I’m still tinkering with this!\n\nI’m currently working on a small WebAssembly runtime on Zig.\n\nNow it’s something like a hybrid of runtime and compiler. I implement the part itself related to WASM on my own, and I use LLVM for experiments with native code generation and separate parts of the compilation pipeline.", "url": "https://wpnews.pro/news/what-s-everybody-working-on-september-edition", "canonical_source": "https://ziggit.dev/t/whats-everybody-working-on-september-edition/17434?page=5#post_101", "published_at": "2026-09-14 09:57:25+00:00", "updated_at": "2026-09-14 10:06:12.497721+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "large-language-models"], "entities": ["zigster64", "atari.zig", "LLVM", "Zig", "DeepSeek", "tes3tool", "tes3cmd", "zig-humanize"], "alternates": {"html": "https://wpnews.pro/news/what-s-everybody-working-on-september-edition", "markdown": "https://wpnews.pro/news/what-s-everybody-working-on-september-edition.md", "text": "https://wpnews.pro/news/what-s-everybody-working-on-september-edition.txt", "jsonld": "https://wpnews.pro/news/what-s-everybody-working-on-september-edition.jsonld"}}