3 ms·
That is exactly how it works -- the implementation doesn't look much like an emulator for real hardware. Although there is a VM running underneath (a lightly mo
by lexaloffle 4y ago
That is exactly how it works -- the implementation doesn't look much like an emulator for real hardware. Although there is a VM running underneath (a lightly modified Lua 5.2 VM), it is not exposed to the user except for the purpose of counting cpu cycles (around 2 per vm instruction). Operations like drawing sprites subtract cycles from the same pool using over-simplistic rules e.g. 1 cycle per non-clipped pixel. There is a limit on Lua memory (2MB) which is similarly silly -- every time it is exceeded, an emergency garbage collection is issued to find out if an OUT OF MEMORY error is needed.
PICO-8 is driven more by the design goal of giving a strong impression of a machine rather than being a well-formed definition of one. It certainly takes liberties with what should be plausible when it suits, but most interactions with the lower level (e.g. poking pixels to video ram) are plausible enough that the fourth wall is not broken.
There are machines that go all the way down to the metal though, which gives them their own kind of allure:
uxn has its own tiny instruction set: https://100r.co/site/uxn.html https://100r.co/site/uxn.html
Mega68k runs on a Motorola 68000: https://twitter.com/Enichan/status/1463687787782324224 https://twitter.com/Enichan/status/1463687787782324224
CHIP-8 has its own vm & display format: https://en.wikipedia.org/wiki/CHIP-8 https://en.wikipedia.org/wiki/CHIP-8
OK Computer: MOS 6502 processor + SID + gfx: https://lemonspawn.com/ok64/ https://lemonspawn.com/ok64/
- tmountain 4y agoWow! I am honored that you took the time to provide such a comprehensive response. Thanks for all the work you’ve done with pico-8. It has brought a lot of people (myself included) a lot of joy!