LOOM — an x86-64 os experiment where cells replace one another and the bootstrap gives up control some stages have machine traces and some are still unresolved this is not a finished operating system

SHINESEA — a rust filesystem image core built around contiguous extents mirrored catalogs checksums and recovery rules tests cover damaged images as well as successful reads not claiming a finished release from the work in the source tree

CINDER-16 — a 16 bit virtual computer written in io with fixed width instructions cycle counting strict image loading and a debugger that can step backward i wanted a cpu i could inspect from end to end

DBLYATEM — c experiments with pe images amd64 decoding and strict binary checks on linux low level groundwork rather than a complete windows compatibility layer

DBYTE-HOLYC-OPT — studying the original HolyC optimizer and trying more transformations around its intermediate code passes the compiler and native backend are still HolyC and the extra work is experimental

DBYTEPAD — a native win32 text editor written in c with file handling search replace diffs and optional DByte integration there are tiny executable experiments too but the smallest builds do not have every editor feature

DEADFLASH — a windows disk image writer that makes the target explicit and checks it again before writing flush readback and verification are part of the job the repo records seven passing ctest checks for the qualified build

DEADBYTE-RECLAIM — plain win32 software inventory removal and rollback the graphical interface passes an operation plan to the cli instead of inventing another privileged path

DBNET — windows networking diagnostics with throughput probes and controlled configuration changes package sources are tracked and external measurement tests require consent

DEADWIRE-HTTPD — a small http 1 point 0 static server with assembly oriented backends more attention goes to request bytes bad paths and measured hot paths than feature count

BYTE-KEEPER — m0te is a little digital creature running in a native rust program it has persistent state a room and a taskbar companion weird idea but there is working code and there are tests

DEADGL — a c99 software renderer that takes text commands and produces framebuffer pixels ppm output and deterministic hashes i want to see what happens between the command and the pixel

DGP-1 — old style fixed function graphics hardware research with a command fifo triangle coverage texture units scanout memory arbitration rtl and software reference models no finished physical graphics card

dbyte-dbpx — a small lossless raster image format with explicit chunks and pixel formats built so the decoder can be read without dragging in a massive image library

DBYTE-370 — a socket 370 atx motherboard design for a pentium iii and via chipsets cpu and chipset pins sdram agp power clocks and reset are the work here not claiming a board has been powered on

S3CORE01 — a small rv64 computer design around the sg2002 one four layer cad revision has zero drc violations and zero unconnected items that does not mean a physical board or linux boot has been proven

USBDEADFLASH — a usb flash drive designed from the connector inward controller nand controlled impedance power and kicad layout still a design and not a manufactured drive

RIGOS — an old usb bootable cpu mining appliance experiment kept here for the record i stopped working on this one and do not maintain it anymore

JOBSIM-DESKTOP — keyboard and mouse compatibility work for job simulator archived as an engineering alpha rather than passed off as a finished release

Shower Game remaster study — source provenance and clean room planning for an old game research only and not a playable remake or a copy of someone else's files

i do not use all of this every day this is the stuff i have actually worked with

languages

systems

build and debugging

hardware

most of this started with breaking things on my own machines and figuring out why bios setup and recovery rom reads with a CH341A memory and storage trouble windows internals linux builds and boot failures

on the software side i have worked with parsers linkers executable formats win32 controls disk access sockets bytecode virtual machines x86 boot stages interrupts fixed point graphics and native tests i use debuggers disassemblers qemu compiler warnings regression tests and raw binary comparisons checking the bytes is the part that never changes

on the hardware side i use kicad for schematics footprints buses layer stacks power nets and drc i check pin maps against documentation and work on old chipsets firmware small stepper motors and salvaged hardware cad and simulation are not proof that a real board works

i also make game mods and investigate runtimes including my summer car reading someone else's code keeping the original behavior intact and tracing a value back to its actual source are all part of that work

this is independent engineering and personal research no made up employers no invented job titles and no pretending a prototype has shipped

source     identify the exact revision
build      record what compiled
run        keep the output and failures
compare    check bytes and hashes and behavior
hardware   measure the real thing before claiming it works

a passing unit test does not prove a pcb works a benchmark with different conditions proves nothing a screenshot is not the program that made it