Andre Weissflog is a user on You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

Andre Weissflog

Retrospective of a year writing C code again (for those not also on twitter):

also posting this here: investigating an unexpected binary size reduction when replacing a bunch of C++ code with C code in the Oryol Gfx module:

more like, buts whatevs :) I've started a Z80/M6502 assembler in Typescript, with the long-term goal of a modern 8-bit IDE for my home computer emulator as VSCode extension: (Per Vognsen's Bitwise project finally pushed me over the edge and convinced me that lexing/parsing isn't the voodoo-magic I thought ;)

big update to my 8-bit emulator: the chip emulators are now in separate dependency-free C headers, Z80 emulation is now (machine-)cycle-perfect, the Amstrad CPC emulation is much more precise, the web version defaults to WebAssembly. github project:, wasm version:

I have changed the license of the sokol headers (sokol-gfx and sokol-time so far) from MIT to zlib/libpng: (cc @rlyeh )

...there are countless topics on the Unity discussion forum about his, but most recommend to mess around with pivots in max, or after the import in Unity, I wonder if there's a simple "Y points up" in the Max FBX exporter which fixes this more in a more robust manner...

Unity/FBX/3DSMax question: what's the best/cleanest fix to get rid of the -90 X-axis rotation when importing 3DS-Max-exported FBX files into Unity (also for animated characters), is there an FBX exporter option, or is artist intervention needed?

I finally wrote that big blog post about my latest Z80 emulator tinkering:

New approach how emulated chips talk to each other by simulating the system bus pin connections. Involves running the finger through wiring diagrams like this: :) (here's how I understand this so far:

Z1013 emu example complete now with keyboard input and preloaded BASIC, 259 lines of C (not counting blank and comment lines):

it's kind of surreal that the entire Z1013 operating system (with text console, debugger with register dump & breakpoints, cassette loading, etc...) is 2 KBytes and fits into a 130 lines hexdump:

simple 8-bit emulator sample (a Robotron Z1013) for my new cycle-ticked Z80 emulator, kbd input missing (will add about 100 loc) GLFW+flextgl+sokol_gfx+chips:

PS: to clarify I didn't have problems with a variable QPF frequency so far, but I also didn't look very hard

I have created a very small standalone C-header for cross-platform time measurement (currently Win, OSX, Linux, emscripten): sokol_time.h (

Some good idea how to reduce wasm/asm.js size further in here: "Z80 speed" the old instruction-ticked Z80 emu is running as fast as a 1.2GHz Z80, vs about 300MHz for the new cycle-ticked emu (on my mid-2014 2.8 GHz i5 MBP with clang -O3)

ok, got the time for running ZEXDOC+ZEXALL Z80 tests to under 300 seconds for the new cycle-ticked emulator (from 538 secs), still nearly 4x slower than the instruction-ticked version (which is 76 secs), but pretty ok now considering that an indirect call happens every few host-CPU ops

I started making SWFW, a window management library in C (it's only two files):
#gamedev #indiedev

I think I'll do some optimization attempts first before going on to the wait-state and interrupt handling. This is what the ZEX-test runner looks like (just needs some RAM and 2 CP/M system calls for char and string output):