What does HackerNews think of chips?

I'm using a code generation approach both for 6502 and Z80, not as extreme and elegant as demonstrated here though.

Instead of a pure data description I have python scripts which generate C source code. The 6502 is perfect for code generation because instructions are very uniform, and the "interesting" part of instructions are the addressing modes which always run the same sequence of operations in front of the actual instruction-specific "payload". The Z80 instruction set has many more special cases, but it can be decoded "algorithmically" as well, see here:

http://www.z80.info/decoding.htm

My Z80 emulator basically implements this "recipe" in python, and generates a huge "unrolled" switch-case statement with one case-branch per instruction (ok not quite, the CB prefix instruction range is still decoded algorithmically to reduce the resulting binary code size a bit).

Complex instruction logic like DAA are still essentially hand-written C functions though, the code generation mainly helps with the "mundane" parts of an instruction, like opcode fetch, and regular memory load/store machine cycles.

One nice side effect of using code generation is that it is very easy to create variations of the emulator. For instance I created a cycle-stepped version of my 6502 emulator (versus the previous instruction-stepped version) with surprisingly few changes to the code-generation script.

PS: the whole stuff is here:

https://github.com/floooh/chips

PPS: an interesting approach (which I haven't tried) for 6502 emulation would be to use the 6502's decode ROM (aka PLA) as the "base-data" for code generation.

One idea I had in my own modular emulators a while ago was to reduce the "state that's passed around" to the input/output pins of the microchip emulators the higher level system emulator is built from. This pin-state often fits into a single 64-bit integer (at least for typical 8-bit home computers), and another advantage is that the emulator's code structure can be kept very close to the schematics of the real hardware (the wiring between chips can be mapped 1:1 to bits in 64-bit integers).

The emulators are written in C, not Rust, but I bet this approach would also work perfectly with Rust's borrow checker (since there's no shared state in memory the borrow checker shouldn't even "activate"). An emulator is essentially built from functions which take a 64-bit integer as input, and return another 64-bit integer.

https://github.com/floooh/chips

Thanks -- we use Emscripten/WASM mainly for running command-line compilers/assemblers (like cc65 and SDCC).

Right now the emulators are all in JavaScript (except for MAME) which makes integrating with the IDE's debugging tools a little easier. It's performant enough for now, since we only have 8-bit platforms at low clock speeds.

Integrating a C emulation library like https://github.com/floooh/chips should be doable, since it doesn't have any dependencies.

There's quite a few 8-bit CPU emulators that can be compiled to WASM. Static translation of 6502 (or Z80) machine code to WASM is tricky because a lot of 8-bit code was using self-modifying code, so you'd need at least some sort of JIT.

Shameless plug: I've started writing easy to integrate 8-bit chip emulators in standalone C headers a little while ago:

https://github.com/floooh/chips

For instance used in these WASM emulators:

http://floooh.github.com/tiny8bit

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.