Tiny Emulators(floooh.github.io)
floooh.github.io
Tiny Emulators
https://floooh.github.io/tiny8bit-preview/index.html
29 comments
Sokol is the best, thank you for your ongoing work :) And please open a patreon or something!
Unrelated, but thanks for your chips project! We've used it in BizHawk as part of our CPC emulator core.
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.
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.
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
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
Thx for those links!
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)
-[0]: https://en.wikipedia.org/wiki/0x10c
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 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?
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'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 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.
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.
> modular components with explicit conformance requirements would allow people to not care what happens inside the black box
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'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.
Libraries rypicly have an interface of function calls.
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.
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.
that mangled word is 'typically' btw.
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.
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 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)
(did not release the pin-level code yet, wait a week)
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 have been aware of this for some time, I come from an age before frameworks.
This isn't something realised, so much as seeing a further supporting argument.
This isn't something realised, so much as seeing a further supporting argument.
Extremely cool. Loading up these games in a split seconds used to take eons as a kid with the tapes.
Bruce Lee on ZX spectrum was my jam!
Bruce Lee on ZX spectrum was my jam!
How do I play Boulderdash on C64? Stuck at the title screen..
See bottom of help page:
https://floooh.github.io/tiny8bit/help.html
TL;DR: first press F1, then Space.
https://floooh.github.io/tiny8bit/help.html
TL;DR: first press F1, then Space.
I hit a bunch of random keys until it loaded ¯\_(ツ)_/¯
Needs more Oric:
https://oric.games/
https://oric.games/
Please update the url to https://floooh.github.io/tiny8bit/ (as is linked officially and in previous submissions, noted last year by the dev even https://news.ycombinator.com/item?id=43821756)
where'd you get this preview one from OP? linked somewhere?
where'd you get this preview one from OP? linked somewhere?
just want to mention that some of these have the volume turned up a bit higher than I expected, which you don't notice until you click on the game
It's at least 8 years old
https://hn.algolia.com/?query=Tiny%20Emulators&type=story&da...
https://hn.algolia.com/?query=Tiny%20Emulators&type=story&da...
It would be nice if there were a UI feature on the site to adjust the volume. Some of the game sounds are way too loud.
C=64 !!!
nice!
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/.