On August 16th 2010 a user named cjbriare started a thread with the same title in another forum. This is where the story of the first NeXT Computer emulator "Previous" began. During the next 15 years that thread was the home of all kinds of discussions about the development of Previous. Many NeXT enthusiasts posted their findings from real hardware and made it possible to transfer the functionality of black hardware to software.
Unfortunately in 2025 the thread with all its valuable informations got lost. But today I would like to pick up the thread again and continue the discussion in this new home - raising from the ashes like a Phoenix!
I suggest all general discussions on the development of Previous to take place here. Maybe we can open a separate thread on compilation issues and another one on questions about using Previous.
I am looking forward to all kinds of exciting new developments!
Thank you for starting it up again
@andreas_g ! I loved your thread and do love Previous.app too!
Super looking forward to what you do NeXT! (PUN DEF INTENDED!)
:D
Nothing makes me so happy as seeing this thread come back—and cheekily enough with its original and confusing name! :D
For anyone coming across this thread and wondering where to download Previous, our current best sources are:
The (semi-official, semi-WIP) Previous release page (for binaries): http://previous.nextcommunity.net/
The extremely official Previous SourceForge project page (for source): https://sourceforge.net/projects/previous/
And eagle (unixdude)'s collection of older builds: https://previous.unixdude.net/download.html
Hopefully we'll eventually have the release page up at https://previous.sourceforge.net/ — but for now it redirects to the project page.
In the future we'll have a site collating mcCoy's impressive repertoire of pre-installed disk images, but for the time being they can be found on mega.nz (https://mega.nz/file/F0Q22KKb#WiceqJA2LIhPbWJZvR6CmJstPZwOdZrun8gYo1e-Row) if you're looking for a system starter.
It's back!
The thread on which past and future of NeXT hangs is back. And indeed, what a curious delight to see it appear under its strangely spelled original name.
Thanks,
@andreas_g
Quote from: Rhetorica on Sep 08, 2025, 05:15 PMbut for the time being they can be found on mega.nz (https://mega.nz/file/F0Q22KKb#WiceqJA2LIhPbWJZvR6CmJstPZwOdZrun8gYo1e-Ro) if you're looking for a system starter.
link's broken (missing "w" at the end).
https://mega.nz/file/F0Q22KKb#WiceqJA2LIhPbWJZvR6CmJstPZwOdZrun8gYo1e-Row
Quote from: mikeboss on Sep 09, 2025, 08:07 AMQuote from: Rhetorica on Sep 08, 2025, 05:15 PMbut for the time being they can be found on mega.nz (https://mega.nz/file/F0Q22KKb#WiceqJA2LIhPbWJZvR6CmJstPZwOdZrun8gYo1e-Ro) if you're looking for a system starter.
link's broken (missing "w" at the end).
https://mega.nz/file/F0Q22KKb#WiceqJA2LIhPbWJZvR6CmJstPZwOdZrun8gYo1e-Row
Right! Corrected.
So,
@andreas_g, what do you have planned so far for the big 4.0? I recall some vague ideas about a possible UI overhaul.
Quote from: Rhetorica on Sep 09, 2025, 12:58 PMSo, @andreas_g, what do you have planned so far for the big 4.0? I recall some vague ideas about a possible UI overhaul.
I am a bit short on time at the moment. I do not plan big UI changes but might check how the current icon works with macOS 26. It might be time for a new one. From the drafts I saw in the past I liked the look of the "PREVIOUS EMULATOR" packaging box the most.
Just a heads up
@andreas_g that revision r1725 didn't build for me; the log is attached.
The problems seem to have started in r1716 ("some cleanups"), as that fails with the same errors.
@Rhetorica Compilation should be fixed. Maybe we should open a separate thread to discuss this kind of issues.
Can someone using macOS Tahoe make a screenshot on how Previous' icon looks like in the dock?
Here you go.
CleanShot 2025-09-22 at 12.34.16.jpg
Vertical layout and its with version 3.9
In case you want to see it on the bottom of the dock.
CleanShot 2025-09-22 at 12.35.46.jpg
Thank you very much! At least it does not look broken.
Just an FYI. I am SUPER PSYCHED waiting on Previous 4.0!
Quote from: ZombiePhysicist on Sep 22, 2025, 05:37 PMIn 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?
Some interplay depending on the icon, but basically all grey.
For those who want maximum overdrive on their simulated black hardware,
@jeffburg posted his secret trove of Previous performance optimizations here (https://github.com/jeffreybergier/Previous-Fork/pull/3/files). (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.
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.
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.
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 (https://www.nextcomputers.org/forums/index.php?action=post;quote=32895;topic=5745) with similar assessment results.
Hello all,
I am happy to announce the release of Previous v4.0! This release comes with an improved version of the command line utility "ditool" (disk image tool). ditool is now able to read a wider range of disk images and has improved error handling.
Previous itself has also improved: It is now possible to hide the title bar using shortcut-T and Previous identifies SCSI CD-ROM and floppy drives as known real devices instead of PreviousCD-ROM and PreviousFLOPPY. There are also some bug fixes and under the hood improvements included.
Please note that with the release of Previous v4.0 I have updated trunk to SDL3. If for some reason you cannot use SDL3 please compile branch_softfloat instead of trunk.
As usual I have compiled a binary for macOS v10.13 and later (Intel and Apple Silicon). You can load the binary here (https://www.dropbox.com/scl/fi/h0nquufqi93295nvlak7k/Previous_4.0.zip?rlkey=2yzw372br55up6nbygam5mosc&st=4c4bti18&dl=0).
Have fun and feel free to report any issues.
Thanks for the new year's update Andreas!
I just built the trunk and ran into a minor issue. The build (on linux) fails on dns.c but suggests the fix: adding #include <ctype.h> after #include "ctl.h". This fixed the build for me.
Speaking of ditool, would it be possible to add support for Rhapsody (and maybe OS X Server 1.x images)? Rhapsody is particularly annoying as the Intel and PPC filesystems are incompatible with each other. Having a way to extract files from the CDs would be great.
Quote from: andreas_g on Jan 01, 2026, 01:45 PMHello all,
I am happy to announce the release of Previous v4.0! This release comes with an improved version of the command line utility "ditool" (disk image tool). ditool is now able to read a wider range of disk images and has improved error handling.
Previous itself has also improved: It is now possible to hide the title bar using shortcut-T and Previous identifies SCSI CD-ROM and floppy drives as known real devices instead of PreviousCD-ROM and PreviousFLOPPY. There are also some bug fixes and under the hood improvements included.
Please note that with the release of Previous v4.0 I have updated trunk to SDL3. If for some reason you cannot use SDL3 please compile branch_softfloat instead of trunk.
As usual I have compiled a binary for macOS v10.13 and later (Intel and Apple Silicon). You can load the binary here (https://www.dropbox.com/scl/fi/h0nquufqi93295nvlak7k/Previous_4.0.zip?rlkey=2yzw372br55up6nbygam5mosc&st=4c4bti18&dl=0).
Have fun and feel free to report any issues.
Wow, what a super way to start off the year! Happy happy new year
@andreas_g and to all! So psyched to see your amazing project continue to improve. Thank you so much for all your dedication and amazing work!
Quote from: andreas_g on Jan 01, 2026, 01:45 PMHello all,
I am happy to announce the release of Previous v4.0! This release comes with an improved version of the command line utility "ditool" (disk image tool). ditool is now able to read a wider range of disk images and has improved error handling.
Previous itself has also improved: It is now possible to hide the title bar using shortcut-T and Previous identifies SCSI CD-ROM and floppy drives as known real devices instead of PreviousCD-ROM and PreviousFLOPPY. There are also some bug fixes and under the hood improvements included.
Please note that with the release of Previous v4.0 I have updated trunk to SDL3. If for some reason you cannot use SDL3 please compile branch_softfloat instead of trunk.
As usual I have compiled a binary for macOS v10.13 and later (Intel and Apple Silicon). You can load the binary here (https://www.dropbox.com/scl/fi/h0nquufqi93295nvlak7k/Previous_4.0.zip?rlkey=2yzw372br55up6nbygam5mosc&st=4c4bti18&dl=0).
Have fun and feel free to report any issues.
Great stuff! I've updated http://rhetori.ca/next/ with a Windows build and http://previous.nextcommunity.net/ with both Windows and macOS builds. I keenly await new .deb files from
@wmlive for Linux 4.0 coverage.
A while ago you said you'd gotten full control at last over the Sourceforge repo. Is it possible to get the "Previous Web Site" link on https://sourceforge.net/projects/previous/ updated to point to the nextcommunity subdomain? EDIT: The alternative-system site is notable as a historical artifact but it's not an ideal introduction to the emulator overall.
Quote from: Protocol 7 on Jan 01, 2026, 02:07 PMI just built the trunk and ran into a minor issue. The build (on linux) fails on dns.c but suggests the fix: adding #include <ctype.h> after #include "ctl.h". This fixed the build for me.
Thank you for reporting! This should be fixed now.
Quote from: Protocol 7 on Jan 01, 2026, 02:07 PMSpeaking of ditool, would it be possible to add support for Rhapsody (and maybe OS X Server 1.x images)?
I just checked a Rhapsody disk image. It seems to have the same disk label as NeXTstep, but uses the BSD4.4 variant of UFS instead of BSD4.3, which is used by NeXTstep. Those two different variants are incompatible. Therefore it would be necessary to re-write the core of ditool (which was not created by me). I'm afraid this is a bit beyond my capabilities.
Quote from: Rhetorica on Jan 01, 2026, 06:06 PMA while ago you said you'd gotten full control at last over the Sourceforge repo. Is it possible to get the "Previous Web Site" link on https://sourceforge.net/projects/previous/ updated to point to the nextcommunity subdomain?
Thank you for updating the page! I have now changed the link on sourceforge to point to the NeXTcommunity subdomain for Previous.
The previous packages at wmlive.rumbero.org/repo/pool/main/p/previous/ (https://wmlive.rumbero.org/repo/pool/main/p/previous/) have been updated to its current 4.0-r1747 version.
The builds are based on libsdl3 version 3.2.10 as offered in Debian/Trixie, which is the target release these packages have been built for.
As usual, packages for i386, amd64, and arm64 have been provided.
There will be no further builds for Debian/Bookworm, as it doesn't include any libsdl3 support packages.
Quote from: andreas_g on Jan 02, 2026, 08:58 AMThank you for updating the page! I have now changed the link on sourceforge to point to the NeXTcommunity subdomain for Previous.
Excellent! Here's hoping we'll no longer have to contend with YouTubers and others getting the darn site wrong!
Quote from: wmlive on Jan 02, 2026, 10:09 AMThe previous packages at wmlive.rumbero.org/repo/pool/main/p/previous/ (https://wmlive.rumbero.org/repo/pool/main/p/previous/) have been updated to its current 4.0-r1747 version.
The builds are based on libsdl3 version 3.2.10 as offered in Debian/Trixie, which is the target release these packages have been built for.
As usual, packages for i386, amd64, and arm64 have been provided.
There will be no further builds for Debian/Bookworm, as it doesn't include any libsdl3 support packages.
I've put these builds up on previous.nextcommunity.net and moved the 3.9 packages to the legacy builds section, marked as "Linux SDL2 (.deb)"—I'm guessing that's enough information to get the target platform across to visitors, but let me know if it needs more qualifiers.