chips-test

The actual emulator code lives here (all in STB-style headers): https://github.com/floooh/chips The chips-test repo has the 'integration' code which assembles the headers into executables: https://github.com/floooh/chips-test There's also a similar project in Zig (but less complete, it's more like an experiment what the same implementation ideas would look like in Zig) that might be a bit more readable and with everything in one place: https://github.com/floooh/chipz E.g. start reading the top-level emulator executables: https://github.com/floooh/chipz/tree/main/emus ...and then move your way down to the system implementations: https://github.com/floooh/chipz/tree/main/src/systems ...and finally to the chip emulators: https://github.com/floooh/chipz/tree/main/src/chips

Browsing the repo linked on the page: https://github.com/floooh/chips-test I see references to files in a "chips" directory. For example "chips/m6502.h". But those are missing? Where can they be found? Like the concept! Reminds me somewhat of simulating a design in a hardware description language (eg. Verilator). Or the concept of 'drivers' in MAME (dunno if those emulate cycle-by-cycle btw). So I'd welcome the opportunity to dive into how it's done on a code level.

Unless it's an arcade machine like Bombjack which has two Z80s and three AY sound chips ;) It's still possible to wrap all that as nested state in a single global, and it works just fine: https://github.com/floooh/chips-test/blob/613dbfe907104f4110... That's a single mutable global with all application state, but inside that global are nested structs and the code working on those structs takes essentially a 'this' pointer. This approach works well since it enforces a strictly hierarchical code and data structure with a single root-struct (and also a single root-source-file) at the top.

I tinkered a bit with sixel support for my "C64 emulator in the terminal" (https://github.com/floooh/docker-c64), but unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better). Here's the (abandondend) sixel-version source code, only with two colors, more color planes would drastically reduce the performance. https://github.com/floooh/chips-test/blob/master/examples/as... I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses). This would allow a lot of fun "terminal applications" (e.g. everything that used to run in VGA Mode 13h).

As far as I know not in a central place, but almost every popular home computer has extensive test suites which test emulator behaviour down to the clock cycle against how the real hardware behaves. For instance the Wolfgang Lorenz test suite for the C64 is almost legendary and quite hard to completely pass (this reproduces the behaviour of Wolfgang Lorenz's C64, but not necessarily of other C64s with different chip revisions): https://github.com/floooh/chips-test/tree/master/tests/tests... Most of those tests have been written in the 90's, so they are now historic artefacts themselves which need to be carefully preserved.

I was hoping this would provide framebuffer-like functionality in the terminal window instead of "just" a way to apply image posteffects. A proper pixel framebuffer terminal standard fast enough to be updated at refresh rate would allow a lot of interesting terminal applications which would live somewhere between Curses UIs and "proper" UI applications which require a whole window system! Current "render pixels to the terminal" standards like iTerm2's ability to display images, or the "Sixels" standard are unfortunately too slow to render colored images at display refresh rate (Sixels is just barely fast enough to render two colors). I've been playing around with running home computer emulators in terminal windows (for instance here's a "C64 in Docker" limited to rendering characters: https://github.com/floooh/docker-c64), imagine if this

Huh? Weird, it works on Windows and Mac for me (Alt-Tab on both, and Ctrl PageUp/Down on Windows, no such keys on my Mac keyboard to test though). I had to consume the browser key events in order to catch the function keys for the emulator (e.g. Chrome uses F1 on Windows for showing the help, but F1 is also needed in the emulators), maybe you're seeing a side-effect of this. Feel free to write a ticket here with reproduction steps: https://github.com/floooh/chips-test/issues

Yes, the sample's source code is here: https://github.com/floooh/chips-test/blob/sokol-app/examples... The pure 8-bit chip emulators are here: https://github.com/floooh/chips You can also start with the 'proper' emulator this is based on: https://github.com/floooh/yakc This has all the links to the underlying software.