This is a good revelation but is a technique that is old as the hills. My first post university programming job was working for CAE Electronics, a Flight Simulator company. The simulations ran on a variety minicomputers of the era, primarily DEC Vax 780 and successors or Gould SEL during my time there.
If memory serves me correctly the simulation ran like a super loop on a microcontroller every 50ms or 33ms. On each loop the dispatcher would run a selection of the core simulation functions some every loop, some at every 2nd, 4th or more loops. The system was called banding. The dispatch table was redone to optimize the needs of that particular simulator.
There were various optimization outside of the main cpu as the peripheral devices did computation as well. Also as the systems got faster there was time left over for the normal OS to run low priority function with non real-time requirements.
The technique was not new in my time and had been used on the previous generation of Xerox systems about a decade earlier.
I worked on machines of the articles vintage - I would expect this technique to be common the further you go back due to the lack of power. Just a variant of CPU slicing.
> The original SimCity for example lists Intel’s 386SX as the CPU in it’s system requirements.
Not sure where that comes from. The original release box art [1] says it will work on any PC with 512KB of ram. So that's an 8088 running at just 4.77 MHz.
But that's far from the lowest spec port of the game. The Commodore 64 version might have been missing quite a few features (like stadiums, police/fire stations and railways), but the main city simulation loop was there in just 64KB of ram and a 1MHz 6502.
And the BBC Micro/Acorn Election port was even more impressive. Had basically all the features of the full Amiga/PC/Mac version, only missing Music/Sound/Animation. With a 2Mhz 6502 (or 1Mhz on the Election) and just 32KB of ram.
And I was expecting a lot more detail from the OP article considering it made the HN front page, but it pretty much comes down to, the game works on a 16-frame cycle, where 1 cycle it may handle crime stuff, another frame handles fire and disaster stuff, etc. No more details about what happens within 1 of those frames, or anything else, beyond 5 cycle function names. And the source is at https://www.donhopkins.com/home/micropolis/
The original release was for Amiga and Mac. The C64 version followed around the same time as the PC version, though apparently the C64 version was the original.
Definitely that was often a solution, but the version I had didn't run on DOS. Not sure whether this was a windows only version I had. Often the problem was ram, extended memory often didn't really work on DOS.
One had to do some significant hand tuning of config.sys and autoexec.bat to optimize conventional.memory usage for a lot of games in that era (ie. relocating device drivers to extended memory), at least until later versions of MS Dos included the memmaker utility to partially automate the process.
This was tricky enough that folks would pay my barely adult self a consultant's hourly rate to do this for them.
This reminds me of microcity which is a Simcity Clone for the Game Boy Colour.
The author has some great in-depth docs about the design, and how they managed to make a fairly lively-seeming simulation fit into a machine with an 8 MHz 8-bit processor.
> Even the cheapest CPUs have at least 4 cores nowadays, running billions of operations per second.
It's ironic that modern programs often have latency and response times in the 10s and 100s of milliseconds. I know the reasons why, but it's still a bit ridiculous to think about it. Just the tons of layers of abstractions we introduce.
We have all of this running on a 16 MHz machine, yet on todays computers with 32GB RAM we have highly memory intensive desktop apps that use java and even electron.
Even a text editor today written in javascript using Electron will take 1GB+ without considering the user could open multiple documents which can increase the RAM usage.
Where I live there is plentiful water. A drought essentially never occurs. I will never have to worry about concerning myself with whether I take a 5 minute or 15 minute shower. You can imagine then, that people that live here generally don't worry about water usage as you might in a severe desert environment where water is a scarce resource.
And that's why so many applications today are giant chonks of resource waste. For a long time now we've had it to spare.
Disregarding the moral debate about resource wasting of course. That's a different discussion. The why is: we have had the resources to burn, so they do. Resource usage is as tight as it has to be very generally speaking.
For more detail than the article gives, Chaim Gingold drew the whole loop for his book "Building SimCity: How to Put the World in a Machine" (MIT Press, 2024), and kindly let us put his diagrams in the MicropolisCore repo.
This "micropolis" repo is mainly for historical purpose, and it's probably better to use the newer MicropolisCore repo for development.
I rebooted micropolis into the fresh new MicropolisCore repo, without all the old X11/TCL/Tk stuff.
MicropolisCore is a C++ rewrite/refactor/cleanup of the original C code into a simulation engine that's independent of the user interface.
The full lineage of the code is C64 => Mac => SunOS/NeWS/HyperLook => Unix/X11/TCL/Tk + multiplayer => Linux/X11/TCL/Tk + multiplayer => OLPC/X11/TCL/Tk (single player) => C++ MicropolisCore => C++/SWIG/Python/PyGTK => C++/SWIG/Python/TurboGears/AMF/Flash/OpenLaszlo => C++/Emscripten/Embind/TypeScript/SvelteKit.
Now it compiles with emscripten/embind into WASM, and it's possible to run it "headless" in node, or with any kind of user interface in the browser.
So if you're making something new, you should use MicropolisCore, but if you're into retrocomputing and want to renovate the TCL version, or even the old PyGTK or Python/TurboGears/AMF/Flash/OpenLaszlo version, then this repo's got what you need!
O huh. I just learned that SHADOWFIRE on the C64 is able to simulate 50 different characters, by only updating one of them per frame.
So the limit is 50 to fit the refresh rate of a PAL TV.
If memory serves me correctly the simulation ran like a super loop on a microcontroller every 50ms or 33ms. On each loop the dispatcher would run a selection of the core simulation functions some every loop, some at every 2nd, 4th or more loops. The system was called banding. The dispatch table was redone to optimize the needs of that particular simulator.
There were various optimization outside of the main cpu as the peripheral devices did computation as well. Also as the systems got faster there was time left over for the normal OS to run low priority function with non real-time requirements.
The technique was not new in my time and had been used on the previous generation of Xerox systems about a decade earlier.
First modern 32 bit CPU with MMU.
Not sure where that comes from. The original release box art [1] says it will work on any PC with 512KB of ram. So that's an 8088 running at just 4.77 MHz.
But that's far from the lowest spec port of the game. The Commodore 64 version might have been missing quite a few features (like stadiums, police/fire stations and railways), but the main city simulation loop was there in just 64KB of ram and a 1MHz 6502.
And the BBC Micro/Acorn Election port was even more impressive. Had basically all the features of the full Amiga/PC/Mac version, only missing Music/Sound/Animation. With a 2Mhz 6502 (or 1Mhz on the Election) and just 32KB of ram.
[1] https://images.launchbox-app.com/79861ce4-75ea-46dd-b46e-521...
Don’t know if that could be an explanation.
This was tricky enough that folks would pay my barely adult self a consultant's hourly rate to do this for them.
The author has some great in-depth docs about the design, and how they managed to make a fairly lively-seeming simulation fit into a machine with an 8 MHz 8-bit processor.
https://github.com/AntonioND/ucity/blob/master/docs/index.rs...
It's ironic that modern programs often have latency and response times in the 10s and 100s of milliseconds. I know the reasons why, but it's still a bit ridiculous to think about it. Just the tons of layers of abstractions we introduce.
Even a text editor today written in javascript using Electron will take 1GB+ without considering the user could open multiple documents which can increase the RAM usage.
And that's why so many applications today are giant chonks of resource waste. For a long time now we've had it to spare.
Disregarding the moral debate about resource wasting of course. That's a different discussion. The why is: we have had the resources to burn, so they do. Resource usage is as tight as it has to be very generally speaking.
https://github.com/SimHacker/MicropolisCore/blob/main/packag...
Chaim Gingold wrote a book all about "Building SimCity":
https://mitpress.mit.edu/9780262547482/building-simcity/
He answered questions about it in this HN discussion:
https://news.ycombinator.com/item?id=40698442
For more detail than the article gives, Chaim Gingold drew the whole loop for his book "Building SimCity: How to Put the World in a Machine" (MIT Press, 2024), and kindly let us put his diagrams in the MicropolisCore repo.
Chaim Gingold's "SimCity Reverse Diagrams":
https://github.com/SimHacker/MicropolisCore/tree/main/images...
Simulation Loop (Simulate):
https://github.com/SimHacker/MicropolisCore/blob/main/images...
Map Data Flow:
https://github.com/SimHacker/MicropolisCore/blob/main/images...
Maps:
https://github.com/SimHacker/MicropolisCore/blob/main/images...
Map Scan:
https://github.com/SimHacker/MicropolisCore/blob/main/images...
Make Traffic:
https://github.com/SimHacker/MicropolisCore/blob/main/images...
Animation Characters:
https://github.com/SimHacker/MicropolisCore/blob/main/images...
From the micropolis repo README:
NOTE: Please See: MicropolisCore
https://github.com/SimHacker/MicropolisCore
This "micropolis" repo is mainly for historical purpose, and it's probably better to use the newer MicropolisCore repo for development.
I rebooted micropolis into the fresh new MicropolisCore repo, without all the old X11/TCL/Tk stuff.
MicropolisCore is a C++ rewrite/refactor/cleanup of the original C code into a simulation engine that's independent of the user interface.
The full lineage of the code is C64 => Mac => SunOS/NeWS/HyperLook => Unix/X11/TCL/Tk + multiplayer => Linux/X11/TCL/Tk + multiplayer => OLPC/X11/TCL/Tk (single player) => C++ MicropolisCore => C++/SWIG/Python/PyGTK => C++/SWIG/Python/TurboGears/AMF/Flash/OpenLaszlo => C++/Emscripten/Embind/TypeScript/SvelteKit.
Now it compiles with emscripten/embind into WASM, and it's possible to run it "headless" in node, or with any kind of user interface in the browser.
So if you're making something new, you should use MicropolisCore, but if you're into retrocomputing and want to renovate the TCL version, or even the old PyGTK or Python/TurboGears/AMF/Flash/OpenLaszlo version, then this repo's got what you need!
https://gamesexplained.com/c64/shadowfire/#people