I love the pin level emulation model of this. The self contained modular behaviour of components has real flexibility.
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.
Things (hardware, software) have been designed since the epoch to be treated as black boxes. Not all things, mind you, but most things do strive for modularity. I find it amusing that this idea is being realized by more people in an effort to satisfy the AIs.
I was able to get my Amstrad CPC emulator to pin-level for all chips... but then in this mode it does run at full speed... if you have a M2 or faster CPU :')
so I also added a "soldered" mode that speeds things up a little by being less modular (no taking the CRTC out!), and a fast mode after all. Pin-level, however, gave me an excellent oracle to verify correctness at all times, which is a benefit on it's own.
Now I'm tempted to make a USB-connected extension port so you could use all real hardware with it :)
(did not release the pin-level code yet, wait a week)
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.
I don't know about anyone else, but this really reminds me of 0x10c [0]
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)
I wrote a basic zachtronics style puzzler based around 0x10c, its one of my favourite concepts that's always stuck with me. I also strongly feel like it'd have a player base (at least initially, while everyone's coding) of maybe a few hundred people worldwide, which makes it a terrible decision financially
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?
Would you mind sending me an email, I'd genuinely be interested in collaborating in this if you're interested, even if it's only brainstorming / discussing
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 :)
I didn't really get around to work on the project since around 2023 though (and before that I worked on it mainly as a 'vacation project' over the Christmas break), I mostly just updated the sokol and Dear ImGui dependencies since then.
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.
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 everything is in a single repo:
29 comments
[ 1.0 ms ] story [ 30.5 ms ] threadFor 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.
This isn't something realised, so much as seeing a further supporting argument.
(did not release the pin-level code yet, wait a week)
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.
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.
https://hn.algolia.com/?query=Tiny%20Emulators&type=story&da...
Maybe at least include the date
https://oric.games/
Bruce Lee on ZX spectrum was my jam!
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)
-[0]: https://en.wikipedia.org/wiki/0x10c
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?
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 :)
The proper and uptodate URL is:
https://floooh.github.io/tiny8bit/
I didn't really get around to work on the project since around 2023 though (and before that I worked on it mainly as a 'vacation project' over the Christmas break), I mostly just updated the sokol and Dear ImGui dependencies since then.
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.
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 everything is in a single repo:
https://github.com/floooh/chipz
https://floooh.github.io/tiny8bit/help.html
TL;DR: first press F1, then Space.