What Needs to be done for a NeXT Emulator

[Rhetorica]

In case you want to see it on the bottom of the dock. [...]

It's surreal seeing a bland gray background behind dock tiles like that on a modern Apple product.  It's like there's a little gremlin at the company that keeps the UX department up at night making them feel insecure about how their icons aren't as cool as NeXT ones.

Do all old icons get that gray color, or does it vary based on the luminosity of the image?

[ZombiePhysicist]

Some interplay depending on the icon, but basically all grey.

[Rhetorica]

For those who want maximum overdrive on their simulated black hardware, @jeffburg posted his secret trove of Previous performance optimizations here. (Ignore the first one—that just removes the amd64 binary since he doesn't use it personally.)

@andreas_g, how hard would it be to add these as runtime options? Say, as toggles requiring a restart to enable or disable.

If it's impractical, how would you feel about "high-performance" builds of Previous being circulated on previous.nextcommunity.net—perhaps with a warning label about stability/accuracy/being unsupported?

I think there's real merit to having a high-performance virtualization solution readily available, even if it isn't as authentic, especially with the ongoing interest in accelerators for NeXT machines, as it will make the next68k environment more accessible for archival and development activities.

[andreas_g]

These optimisations only have a minor effect. Turning these into runtime options would sacrifice some efficiency for both modes and thus makes little sense. You get a much larger effect by editing the configuration file and setting nCpuFreq to a greater number.

[jeffburg]

At some point I will do an A/B comparison to see how many MHz I can get with it on and off. But I remember it being significant. Like 200MHz without the optimization and 300MHz with the optimization on the same computer. But yes, as @andreas_g said. In either case you need to quit Previous and then open the config file in a text editor and increase the speed manually by changing the nCpuFreq, then restart Previous. So it's quite tedious to dial in. Also, if the workload increases in the Virtual Machine the clock speed can drop significantly. So you need to spend time optimizing it for your specific host system.

[wmlive]

Trying with both these patches and also the manual interventions mentioned, i don't see any meaningful speed increase from the user's point of view.
Increasing the nCpuFreq to various levels between 80 and 300 mostly results in an avalanche of 'Events queue overflow!' messages for me on a Thinkpad T480 with i5-8350U CPU.
If there are any performance differences they are so marginal that its probably impossible to perceive them without specific measurement tools.

I remember having tried this before based on www.nextcomputers.org/forums/index.php?action=post;quote=32895;topic=5745 with similar assessment results.