The proper and uptodate URL is:
https://floooh.github.io/tiny8bit/
Apart from the 'pin-emulation' the other interesting feature is that the CPUs are 'cycle stepped', e.g. the CPU no longer has a special 'controller role' in the system but is just 'ticked along' with all the other chips. This blog post describes how that works for the Z80 emulation (the instruction decoder is still a big switch-case, but with one case-prong per instruction cycle instead one prong per whole instruction: https://floooh.github.io/2021/12/17/cycle-stepped-z80.html)
I didn't really get around to work on the project since 2023 though (and before that I worked on it mainly as a 'vacation project' over the Christmas breaks), I mostly just updated the sokol and Dear ImGui dependencies since then, and sometimes added new scene demos appearing on https://www.pouet.net/ and https://csdb.dk/.
Bruce Lee on ZX spectrum was my jam!
My favourite demo in the list : https://floooh.github.io/tiny8bit/cpc.html?file=cpc/phx.dsk&...
where'd you get this preview one from OP? linked somewhere?
I'm still fascinated by the idea of a setting with virtual mini computers, I've designed a couple as thought exercises based on it/space travel as well as cyberpunk mixing in a little Zach like flavour for some of the chip design, even figured out a fantasy variant
Not sure why, but I've not been able to convince myself that it's anything other than ultra niche, so if you're interested in this and want to talk about it, chime in here or drop me an email (in profile)
For a long time I have wondered if extremely thin but explicitly defined interfaces are an under-explored domain for interoperability.
Beyond simple chip emulation, any set of values that are sampled on each side of the interface at defined times, and a small set of signals to provided temporal access. Be it pins, a small set of registers, or a memory mapped region, it seems like an excellent target for conformance testing.
Perhaps in a world of AI generated code, modular components with explicit conformance requirements would allow people to not care what happens inside the black box, provided it cannot be made to violate it's behaviour requirements.
https://hn.algolia.com/?query=Tiny%20Emulators&type=story&da...
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.
I feel like you're stuck between a rock and a hard place with that game. Do people really want to build their whole own OS just to interact with the hardware of their spaceship? Should it be a game where you have an ingame software market, for people to buy/sell software to use in your spaceship controls? Is a player REALLY going to build windows 3.1 for the DCPU for free?
I'd love to make it work, there was an open source game that was going for a while, but it went all the way down to the BIOS level which is just.. way too technical for most people. Who wants to get involved with an API/ABI for just making their spaceship move?
(did not release the pin-level code yet, wait a week)
https://floooh.github.io/tiny8bit/help.html
TL;DR: first press F1, then Space.
That's the whole idea of software libraries, no AI needed for that ;)
It just takes some disciplines and not listening to the DRY crowd too much to create actually self-contained libraries.
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:
I've been looking at a new fun thing to focus on for a bit and this could be a great contender
No worries if you don't feel like it, this is still a positive indicator :)
Maybe at least include the date
This isn't something realised, so much as seeing a further supporting argument.
That is different from an interface of set of polled values with a few signals.
Any library that can write to memory through provided pointers, or can return non primitive data has a potentially unlimited interface.
but while I'm here I should point out I wasn't thinking you need AI for this. I was thinking maybe you need this for AI. As a testable way to insulate yourself from AI overreach.