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.
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.
> 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.
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.
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.
[1] https://images.launchbox-app.com/79861ce4-75ea-46dd-b46e-521...
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/
C64 was not a port. The C64 version is the original.
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.
I was running Sim City 2000 inside Win 3.1 on an 386 with 33MHz (I had 16MB of ram though). But it was virtually unplayable.
Sim City 2000 is a very different (and computationally more demanding) game than the original Sim City.
In my youth, people would quit Windows 3.1 to run games in DOS, because the overhead of the OS was too much.
Don’t know if that could be an explanation.
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.
It ran great on a Performa 475 (25 MHz Motorola 68LC040). I guess that settles that old debate!
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.
https://github.com/AntonioND/ucity/blob/master/docs/index.rs...
Bear in mind that the GBC is almost between high end NES graphics and SNES.
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.
> 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.
The implementation: https://github.com/SimHacker/micropolis/blob/master/micropol...
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.
https://gamesexplained.com/c64/shadowfire/#people
Even quicker solution, and on 7Mhz. Use an Amiga.