Did y'all know that C has spelled out logical operators (and, or, not) in the iso646.h standard header <https://en.cppreference.com/w/c/header/iso646.html>? I use that in all my projects and add some more on top:

#include <iso646.h>
// For consistency with other bit* operators
#define bitnot ~
#define is ==
#define isnt !=

El resultado de una guerra se define en el campo de batalla; ese mismo lugar al que usted y sus fuerzas no se atreven a acercarse y sobre el que solo pueden hablar en sus tuits."

https://tardigram.com/m/Actualidad/t/21721

Maxivmac, a maximized minivmac (in progress). #marchintosh

*The hardest part of this refactor wasn't any single conversion — it was the invisible web of dependencies that only revealed themselves at link time. Mini vMac was written as a single-model, single-binary C program where #define was the configuration mechanism, and every device file implicitly assumed it could reach into any other device's guts through macros. You'd confidently strip a #if EmPMU guard from pmu.cpp, hit build, and discover that the PMU's implementation directly pokes VIA1 port registers through #define aliases that only exist when EmPMU=1. Three times I removed a file-level guard, watched the linker explode with undefined symbols, and had to restore it with a stub API in the #else branch instead — a pragmatic retreat that felt like admitting defeat each time. The HaveMasterMyEvtQLock macro was a perfect example of the archeological nightmare: a boolean #define aliased to another #define (EmClassicKbrd), gating a variable declaration in one file, used conditionally in three others, whose ultimate purpose was a four-tick debounce counter for the mouse button on compact Macs. Understanding that took longer than converting it.* -- Claude Opus 4.6, after a 14 hours session

So? I wanted to play with Claude and modernization, and 102 commits later, welcome [maxivmac](https://github.com/fstark/maxivmac), the port of minivmac to the 21th Century!

```
maxivmac % ./bld/macos-cocoa/maxivmac.app/Contents/MacOS/maxivmac --help
Usage: ./bld/macos-cocoa/maxivmac.app/Contents/MacOS/maxivmac [options] [disk1.img] [disk2.img] ...

Options:
--model=MODEL Mac model: Plus, SE, II, IIx, Classic, PB100, 128K, 512Ke
(default: II)
--rom=PATH Path to ROM file
--ram=SIZE RAM size: 1M, 2M, 4M, 8M (default: model-specific)
--screen=WxHxD Screen size: 512x342x1, 640x480x8, etc.
--speed=N Emulation speed: 1 (1x), 2, 4, 8, 0 (all-out)
--fullscreen Start in fullscreen mode
-r PATH ROM path (short form)
-h, --help Show this help

Examples:
./bld/macos-cocoa/maxivmac.app/Contents/MacOS/maxivmac --model=II --rom=MacII.ROM system7.img
./bld/macos-cocoa/maxivmac.app/Contents/MacOS/maxivmac --model=Plus --rom=vMac.ROM --ram=4M disk.img
maxivmac %
``

This is _far_ from finished, but I did get rid of the original byzantine build system and have a single binary for all models (Plus and MacII working). If you've ever tried to hack ``minivmac`` you know what a milestone this is. You can now switch models, increase the emulated RAM or the screen resolution without recompiling.

Goal is to converge to a semi modern C++ source, with no functional #define left, and proper naming of everything.

I renamed it maxivmac to distinguish from the original, and to emphasis that the goal is not minimalism. A lot of untested things in the repo, so don't fork yet if you plan to build on it. Note that I do plan to get rid of platforms better served by minivmac, and will also try to converge to a single frontend. If you have strong opinions to where this should go, use the [github issue tracker](https://github.com/fstark/maxivmac/issues)!

(I will not accept PR until the build is stable with a strong test suite -- a matter of a couple of weeks, probably)