NeXTcommunity

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 AM

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

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.

Hello all,

can someone do a test on real non-Turbo NeXT (Cube or Slab does not matter) to check behaviour of a specific register?

From ROM Monitor please type
eb 0201a000 (hit enter)
0 (hit enter)
. (hit enter)
eb 0201a000 (hit enter)
(hit enter)
(hit enter)
(hit enter)
. (hit enter)
eb 0201a000 (hit enter)
(hit enter)
(hit enter)
(hit enter)
. (hit enter)

The output will look like this, except that not all output is zero:
NeXT>eb 0201a000
201a000: 00? 0
201a001: 00? .
NeXT>eb 0201a000
201a000: 00?
201a001: 00?
201a002: 00?
201a003: 00? .
NeXT>eb 0201a000
201a000: 00?
201a001: 00?
201a002: 00?
201a003: 00? .
NeXT>
Please post the exact output here.

Hi @andreas_g ,

here are the values from my non-turbo NeXTcube, but please note that it has a Pyro-card installed, so the values may be not standard:

NeXT>eb 0201a000
201a000: 00? 0
201a001: 00? .
NeXT>eb 0201a000
0201a000:  a1?
0201a001:  01?
0201a002:  a0?
0201a003:  03?  .
NeXT>eb 0201a000
0201a000:  87?
0201a001:  01?
0201a002:  a0?
0201a003:  03?  .

Also checked the values from my "Color NeXT", before I realized that it is indeed a Turbo-Color machine. Will attach those values anyway, in the hope that they may proof useful somehow:

NeXT>eb 0201a000
201a000: 00? 0
201a001: 00? .
NeXT>eb 0201a000
0201a000:  00?
0201a001:  01?
0201a002:  e3?
0201a003:  ec?  .
NeXT>eb 0201a000
0201a000:  00?
0201a001:  0b?
0201a002:  2d?
0201a003:  f2?  .

My non-turbo Mono-Slab can currently not be started, sorry.

Pyro-cube.jpgColor-Slab.jpg

@marvin
Thank you very much for testing! The result on the non-Turbo machine is surprsing. I'll have to investigate this.

If it is not too much effort could you redo the test but replace eb 0201a000 with eb 0211a000 (everything else unchanged)?

Hi @andreas_g ,

here are the new values from my non-turbo NeXTcube (ROM monitor 2.1 v59) with Pyro-card installed, so the values may be not standard:

NeXT>eb 0211a000
211a000: 10? 0
211a001: ff? .
NeXT>eb 0211a000
211a000:  6d?
211a001:  6d?
211a002:  66?
211a003:  a3?  .
NeXT>eb 0211a000
211a000:  d6?
211a001:  d6?
211a002:  d1?
211a003:  01?  .
Here are the new values from my Turbo-Color slab (ROM monitor 3.1 v71) for the sake of completeness:

NeXT>eb 0211a000
211a000: 00? 0
211a001: 0a? .
NeXT>eb 0211a000
211a000:  00?
211a001:  0e?
211a002:  2e?
211a003:  a5?  .
NeXT>eb 0211a000
211a000:  00?
211a001:  01?
211a002:  e5?
211a003:  c9?  .
Color-Slab-2.jpgPyro-Cube-2.jpg

Can confirm Previous 4.0 (r1755) is running fine with Debian 12 (x86-64) and SDL3.

I had to install my own version of SDL3.

## unzip source code into src/ folder
cd /usr/local/Software/libs/x86_64/src/SDL3-3.4.0/

## https://wiki.libsdl.org/SDL3/README-cmake
cmake -S . -B build -DSDL_SHARED=ON -DSDL_STATIC=ON -DSDL_TESTS=ON
cmake --build build

mkdir /usr/local/Software/libs/x86_64/SDL3-3.4.0
cmake --install build --prefix /usr/local/Software/libs/x86_64/SDL3-3.4.0
Then compile Previous:

cd /usr/local/Software/Previous/previous-code-r1755-trunk/
setenv SDL3_DIR /usr/local/Software/libs/x86_64/SDL3-3.4.0/lib/cmake/SDL3/ ; ./configure
make

@marvin
Thank you very much for testing again! The values on the Turbo make sense while those on the non-Turbo are still strange. Pyro does not affect this.

The event counter is a mystery to me. I think it should reset to zero if being written but it is unclear if it continues counting immediately after write or only if read afterwards.

Hi all, first post here.
How do i get to the serial console(s) in previous? Is there any branch that has this functionality?
Thanks!

Quote from: ramalhais on Feb 19, 2026, 06:45 PMHi all, first post here.
How do i get to the serial console(s) in previous? Is there any branch that has this functionality?
Thanks!

Is this the one where at the login screen you use username "console" and it boots to the terminal and asks for your username and password?

Quote from: ptek on Feb 20, 2026, 07:26 PM

Quote from: ramalhais on Feb 19, 2026, 06:45 PMHi all, first post here.
How do i get to the serial console(s) in previous? Is there any branch that has this functionality?
Thanks!

Is this the one where at the login screen you use username "console" and it boots to the terminal and asks for your username and password?

i mean the emulator equivalent of the serial port on the back of a next machine  8)

Quote from: ramalhais on Feb 19, 2026, 06:45 PMHow do i get to the serial console(s) in previous? Is there any branch that has this functionality?
Thanks!

Unfortunately I have not yet been able to add this. The problem is that I have no idea how to connect the simulated serial port to the console or some other text input/output interface of the host.

The appended patch demonstrates serial console output but does nothing useful.

alt_cons.diff

Hello all,

I am happy to announce the release of Previous v4.1! I have updated the timing system. It should be a bit more efficient and much more accurate in variable speed mode.

It also includes some minor stability improvements and bug fixes.

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/560dcoqtbui3qphw6g9va/Previous_4.1.zip?rlkey=xf8a2atq29y58diif3klhfhgt&st=oognhze7&dl=0).

Have fun and feel free to report any issues.

Great! Confirmed that all the important stuff still works just fine:

previous-4.1.png

Sound playback is smoother than ever, and NFS works like a gem. And I think my cycle count is higher than usual (a more comfortable hovering around 75-80 MHz!)

The build posted above and a MinGW build from the same source are up on the Previous page here: https://previous.nextcommunity.net/

@andreas_g thanks! I can't wait to try performance improvements
@Rhetorica what is that little CPU monitor utility in the Dock you have there?

Quote from: jeffburg on Mar 02, 2026, 03:20 AM@Rhetorica what is that little CPU monitor utility in the Dock you have there?

That is KPerfMon 1.3C, which you can exhume from here (http://archive.nextcommunity.net/peak/apps/monitors/). It spawned a whole family of clones for WindowMaker and AfterStep (see here (https://www.dockapps.net/category/system)), but there were only really a couple noteworthy specimens of this proto-Rainmeter (https://www.rainmeter.net/) "display all the system status widgets!" trend on NeXT proper. Intriguingly its predecessor was likely written by a NeXT employee (based on a Sun widget...)

Quote from: jeffburg on Mar 02, 2026, 03:20 AM@andreas_g thanks! I can't wait to try performance improvements

The performance improvement is not that big. You can measure it but I don't think you will notice it under normal conditions. The update is more about improved accuracy.

The Previous packages at wmlive.rumbero.org/repo/pool/main/p/previous/ have been updated to version 4.1-r1777.
The binary packages were built for target release Debian/Trixie and CPU architectures i386, amd64, and arm64.

Quote from: wmlive on Mar 03, 2026, 11:02 PMThe Previous packages at wmlive.rumbero.org/repo/pool/main/p/previous/ have been updated to version 4.1-r1777.
The binary packages were built for target release Debian/Trixie and CPU architectures i386, amd64, and arm64.

Great! I've mirrored them as usual.

Quote from: andreas_g on Feb 28, 2026, 11:59 AMHello all,

I am happy to announce the release of Previous v4.1! I have updated the timing system. It should be a bit more efficient and much more accurate in variable speed mode.

It also includes some minor stability improvements and bug fixes.

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/560dcoqtbui3qphw6g9va/Previous_4.1.zip?rlkey=xf8a2atq29y58diif3klhfhgt&st=oognhze7&dl=0).

Have fun and feel free to report any issues.

The new timing system is giving me weird results in linux using ping, although it may be entirely my fault.
ping works fine on real hardware. Just wanted to let you know:

(https://i.postimg.cc/PxqwYstq/Capture.png)

Quote from: ramalhais on Mar 04, 2026, 11:47 PMThe new timing system is giving me weird results in linux using ping, although it may be entirely my fault.
ping works fine on real hardware. Just wanted to let you know:

Thank you for the report! How did this look like in Previous v4.0?

Quote from: andreas_g on Mar 05, 2026, 06:32 AM

Quote from: ramalhais on Mar 04, 2026, 11:47 PMThe new timing system is giving me weird results in linux using ping, although it may be entirely my fault.
ping works fine on real hardware. Just wanted to let you know:

Thank you for the report! How did this look like in Previous v4.0?

With less precision, but no weird times:

(https://i.postimg.cc/HWc67WQr/Capture.png)

It looks very much like an underflow. Can you try if the appended patch fixes it?

systemtimer.diff

Quote from: andreas_g on Mar 05, 2026, 09:24 PMIt looks very much like an underflow. Can you try if the appended patch fixes it?

systemtimer.diff

It's perfect now! Thank you!

(https://i.postimg.cc/kXtxv9vf/Capture.png)

Great! I'll update the code in the repository later today.

Short explanation: I was a bit too optimistic when adding support for the system timer downcounter. As it turned out, tiny inaccuracies could cause the counter to underflow (wrap to maximum value). The patch protects it against underflow.

Sorry for the delay. The patch (in an extended and slightly modified version) is online.

Sorry, I have little off-topic question: is it possible to access the source code repo for previous on sourceforge via git?

I tried the URLs mentioned on https://sourceforge.net/p/forge/documentation/Git/ (replacing "PROJECTNAME" with "previous" and "REPOSITORY" with "code" or "trunk") with git clone, but it always results in a "not found" error.

I'm not familiar with subversion and use git for a lot of other projects (for example hatari), therefore it would be great if the source code for previous was available via git as well.

@don_apple yeah, you need to make sure you have a package on your system called git-svn, and then you can clone the source forge repo into a git repository. But branching between the 2 systems works completely differently so you will find its pretty odd to work with. but it does work.

I actually maintain a fork in a git... although it doesn't have the newest changes. I update it like once every 2 months or so

https://github.com/jeffreybergier/Previous-Fork

Quote from: jeffburg on Mar 09, 2026, 01:11 AM@don_apple yeah, you need to make sure you have a package on your system called git-svn, and then you can clone the source forge repo into a git repository. But branching between the 2 systems works completely differently so you will find its pretty odd to work with. but it does work.

As far as I understand from the link I mentioned, it should also be possible to enable direct git access to the code repo on sourceforge. Maybe @andreas_g or somebody else who has admin access to the repo on sourceforge could check if this is enabled or not.

Quote from: don_apple on Mar 10, 2026, 10:54 AMAs far as I understand from the link I mentioned, it should also be possible to enable direct git access to the code repo on sourceforge. Maybe @andreas_g or somebody else who has admin access to the repo on sourceforge could check if this is enabled or not.

I don't think I can enable something here. The linked instruction describes how to set up a git repository, but Previous uses a subversion repository.

Quote from: ramalhais on Feb 19, 2026, 06:45 PMHi all, first post here.
How do i get to the serial console(s) in previous? Is there any branch that has this functionality?
Thanks!

I don't know if this is what you are trying to do, but if you just want to login to the emulator from your host computer you can run "telnet localhost 42323" from the terminal.  Previous has port forwarding setup by default.

Hello all,

I am happy to release Previous v4.2 to the public! The new version is about improved mouse behaviour. You might have to re-configure your mouse acceleration settings in Previous but you should be able to get better results than before. Also the mouse options dialog should be a bit more user friendly.

Another way to get better mouse experience is to use Previous' new tablet input. It can be enabled in the mouse options dialog as an alternative method of input. It will translate the mouse movement of the host to drawing tablet events which allows for input of absolute coordinates.

Unfortunately this feature is a bit inconvenient because the tablet driver must be re-installed inside NeXTstep after every (re-)boot. Note that tablet input is only supported by NeXTstep 2.0 and later. Absolute tablet input only works properly if you enable one single screen in NeXTstep.

Tablet implementation is minimalistic to work as mouse replacement. If you know of any software that makes use of tablet input on the NeXT I can try to make that work too.

As usual I am providing a binary for macOS 10.13 and later (Intel and Apple Silicon) here (https://www.dropbox.com/scl/fi/tlc4wz81tterow3xg49od/Previous_4.2.zip?rlkey=2m7jfmt135y86y00paolvtqvp&st=gy83ppc2&dl=0).

Feel free to report any problems. I'll do my best to fix them.

Great! I don't have time to test the tablet features thoroughly, but it sounds amazing @andreas_g! I've made both softfloat and filesharing builds for Windows and put them up, along with your macOS build, in their usual place of honour on previous.nextcommunity.net. Awaiting Linux builds from @wmlive!

Quote from: Rhetorica on Apr 21, 2026, 02:49 AMAwaiting Linux builds from @wmlive!

Available now for Debian/Trixie amd64/arm64/i386 at wmlive.rumbero.org/repo/pool/main/p/previous/ (https://wmlive.rumbero.org/repo/pool/main/p/previous/).

Anyone thought of just doing an .AppImage version? Might be much easier for everyone.

Quote from: wmlive on Apr 21, 2026, 11:24 AM

Quote from: Rhetorica on Apr 21, 2026, 02:49 AMAwaiting Linux builds from @wmlive!

Available now for Debian/Trixie amd64/arm64/i386 at wmlive.rumbero.org/repo/pool/main/p/previous/ (https://wmlive.rumbero.org/repo/pool/main/p/previous/).

Mirrored!

@Adam_Hall I admit, I had to google .AppImage to understand what it is. Seems pretty cool. Of course I should have figured that the Linux community had still not settled on a portable application binary format. Of course, I could see why given the incredible variety of linux distros and versions in use.

I'm not too familiar with it beyond using it in the background regularly — many of the programs I use come in that format. Honestly, I find it easier to work with than Flatpak.
I built Previous from source, so it runs fine on Debian 12 (I haven't moved to Debian 13 yet). I did have Claude AI walk me through creating an AppImage for another program I built from source. It was a bit of a blur since I'd never done it before, but it only took about five minutes and I ended up with an AppImage that runs on any Linux distribution.
I first became familiar with AppImage when GDoom switched to it from Flatpak, and later discovered I already had quite a few programs on my system using it.

I've got a little teaser for you. It has been requested many times and finally it will arrive. Check back soon.

multiscreen.png

OMG OMG OMG

HURRAY!

Now do all 4! :D

OMG!

Hello all,

finally it is time to release Previous v4.3. As already shown in the teaser above it has a new display feature. It is now possible to group multiple screens within a single window. This improves usability of multi-screen setups. The new version also includes improved window sizing on small screens.

The new display mode is available through the Graphics dialog when selecting "Show display: All". Because I had to rework the screen drawing code I also had to introduce new setting parameters and replace old ones. Therefore you might need to re-configure your screen settings.

I am providing a binary for macOS v10.13 and later (Apple Silicon and Intel) here (https://www.dropbox.com/scl/fi/zyeos5zqtru7a0yfenxnd/Previous_4.3.zip?rlkey=ksrvkq27yrx2276fzqpa4xv2m&st=x3fa7k3s&dl=0). I hope you like the new feature.

Because the new feature adds quite some complexity to the code please be prepared for some UI bugs but the emulation core of Previous is still stable. Please report any issues you might experience.

Compiles and runs fine on ubuntu 26.04
Thanks @andreas_g !

The Debian/Trixie based previous packages for amd64/arm64/i386 at wmlive.rumbero.org/repo/pool/main/p/previous/ (https://wmlive.rumbero.org/repo/pool/main/p/previous/) have been updated to release Previous v4.3.

@wmlive @andreas_g
All of the above builds, plus Windows SDL2 and SDL3, have been posted to the Previous website (https://previous.nextcommunity.net/). I have not had an opportunity to verify that the Windows builds work as expected beyond simply compiling and briefly looking at the boot monitor; I hope to find the time to do this soon.

Hey @andreas_g — build r1828's DSP-recording feature sounds really cool. Is there any chance this could be used to produce high-quality audio recordings of the early DSP demos? I've been in love with Velvet since I first heard it, but have never been able to capture output as good as what Previous generates in real-time. (I know I'm not alone in my fondness for Velvet, since verdraith used it as the intro tune to his NeXT OSNerd videos.)

Recording has been possible since Previous v2.9. With shortcut-R (see keyboard options dialog) you can start the recording process. When pressing shortcut-R again it will save all sound output that has occurred since you started recording to a file in AIFF format. You find the file in the printer output directory.

The content of the file matches what is sent to the Soundbox for playback. There is no compression or other loss of data. It just skips over periods without sound output (when there is nothing sent to the soundbox, not even silence).

I had no idea. That's wonderful. Time to make some recordings!

Question on sound recording: At the moment Previous records sound after volume adjustment and the experimental (and not very accurate) low-pass filter is applied. Do we want to keep this behaviour or do we prefer saving sound before these adjustments?

In other words: Better save what is heared from Previous or better save the pure data?

IMHO it's always better to capture the unmolested data. filters can easily be applied later if desired.

This makes sense for me too. Volume can be adjusted easily during playback to the recorded data itself. Filters can also be applied and the current low-pass filter does not match real hardware anyway.

But one issue remains: The Soundbox accepts 44,1 and 22,05 kHz audio streams. Depending on setup it performs upsampling of 22,05 kHz data using sample repetition or zero-filling. Probably this step should be taken before saving the sound?

Yes, just export 44.1 kHz. If someone truly needs to recover the 22050 Hz audio they can always resample it in an editor.

Thank you for the response. So I'll change recording to save the data before applying volume and filter. This change will be available in the next version of Previous.

Are there any audio experts in here? While trying to find out how to improve the low-pass filter I realized that in fact I need a de-emphasis filter for CD-standard emphasised sound. In real hardware the filter (analog implementation) is included in the Philips SAA7323 DAC inside the Soundbox. It is enabled via the DEC pin of the chip.

Does anyone have an idea how to implement de-emphasis for CD standard emphasised audio at 44,1 kHz?

I'm not expert.

I just asked some AI and it suggested what follows which may be garbage:


But maybe

• [color=rgba(0, 0, 0, 0.96)]JUCE (C++)
  [/color]
  
  • [color=rgba(0, 0, 0, 0.96)]Cross‑platform, integrates with Core Audio on macOS. Use dsp::IIR::Coefficients anddsp::IIR::Filter (or dsp::ProcessorChain) for SOS processing; ready for plugin or standalone app.[/color]

[color=rgba(0, 0, 0, 0.96)]Ready-to-use coefficient approach (44.1 kHz)[/color]

• [color=rgba(0, 0, 0, 0.96)]Use two first-order sections (cascade) converted via bilinear transform for τ = 50 µs and 15 µs.Implement as two 1st-order IIRs or combine into one biquad (SOS recommended).[/color]

[color=rgba(0, 0, 0, 0.96)]One combined biquad (Direct Form I, a0 = 1) for 44.1 kHz (use these in JUCE/vDSP/AudioUnit IIR APIs as b0,b1,b2 ; a0,a1,a2):[/color]
[color=rgba(0, 0, 0, 0.96)]b0 = 0.730944081 b1 = -1.432852847 b2 = 0.701908766 a0 = 1.000000000 a1 = -1.421865094 a2 = 0.711709612[/color]
[color=rgba(0, 0, 0, 0.96)]Implementation notes[/color]

• [color=rgba(0, 0, 0, 0.96)]Use SOS/biquad routines (JUCE dsp::IIR, vDSP_biquadm, AudioUnit DSP code) to ensure numericstability.[/color]
• [color=rgba(0, 0, 0, 0.96)]Normalize or verify 1 kHz reference gain if needed.[/color]
• [color=rgba(0, 0, 0, 0.96)]Test with sweep and reference emphasis test tones.[/color]

Below is a minimal JUCE 7+ example demonstrating how to apply the de‑emphasis biquad in a standalone or plugin processor using JUCE's dsp::IIR::Filter. It loads the provided biquad coefficients into dsp::IIR::Coefficients and processes audio in processBlock.

Paste into your AudioProcessor's header/cpp or into a minimal JUCE Console/Audio plugin project.
Key points:

• Sample rate must be 44100 Hz (coefficients precomputed for 44.1 kHz).
• The coefficients are Direct Form I (a0 = 1) as b0,b1,b2 ; a0,a1,a2.

AudioProcessor.h (excerpt)

#pragma once

#include <JuceHeader.h>

class DeEmphasisProcessor  : public juce::AudioProcessor
{
public:
    DeEmphasisProcessor();
    ~DeEmphasisProcessor() override;

    void prepareToPlay (double sampleRate, int samplesPerBlock) override;
    void releaseResources() override;
    void processBlock (juce::AudioBuffer<float>&, juce::MidiBuffer&) override;

    // usual AudioProcessor boilerplate...
private:
    juce::dsp::IIR::Filter<float> deEmphasisFilter;
    JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (DeEmphasisProcessor)
};

AudioProcessor.h (excerpt)
#pragma once
#include <JuceHeader.h>

class DeEmphasisProcessor  : public juce::AudioProcessor
{
public:
    DeEmphasisProcessor();
    ~DeEmphasisProcessor() override;

    void prepareToPlay (double sampleRate, int samplesPerBlock) override;
    void releaseResources() override;
    void processBlock (juce::AudioBuffer<float>&, juce::MidiBuffer&) override;

    // usual AudioProcessor boilerplate...
private:
    juce::dsp::IIR::Filter<float> deEmphasisFilter;
    JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (DeEmphasisProcessor)
};

AudioProcessor.cpp (excerpt)
#include "AudioProcessor.h"

DeEmphasisProcessor::DeEmphasisProcessor()
{
    // constructor...
}

DeEmphasisProcessor::~DeEmphasisProcessor() = default;

void DeEmphasisProcessor::prepareToPlay (double sampleRate, int samplesPerBlock)
{
    juce::dsp::ProcessSpec spec;
    spec.sampleRate = sampleRate;
    spec.maximumBlockSize = static_cast<uint32> (samplesPerBlock);
    spec.numChannels = static_cast<uint32> (getTotalNumOutputChannels());

    deEmphasisFilter.reset();
    deEmphasisFilter.prepare(spec);

    // Ensure sample rate is 44.1 kHz (coeffs provided for 44100)
    if (std::abs(sampleRate - 44100.0) > 1.0)
    {
        // You can recompute coefficients for other rates; here we assert for clarity.
        jassertfalse;
    }

    // Coefficients (Direct Form I, a0 = 1)
    const double b0 = 0.730944081;
    const double b1 = -1.432852847;
    const double b2 = 0.701908766;
    const double a0 = 1.0;
    const double a1 = -1.421865094;
    const double a2 = 0.711709612;

    // JUCE expects coefficients as (b0,b1,b2,a0,a1,a2) for IIR::Coefficients::makeDirectFormI
    auto coeffs = juce::dsp::IIR::Coefficients<float>::makeDirectFormI(
        (float)b0, (float)b1, (float)b2, (float)a0, (float)a1, (float)a2);

    *deEmphasisFilter.state = *coeffs; // load coefficients into filter state
}

void DeEmphasisProcessor::releaseResources()
{
    deEmphasisFilter.reset();
}

void DeEmphasisProcessor::processBlock (juce::AudioBuffer<float>& buffer, juce::MidiBuffer&)
{
    juce::dsp::AudioBlock<float> block (buffer);
    juce::dsp::ProcessContextReplacing<float> context (block);

    // Process in-place (same coefficients used for all channels)
    deEmphasisFilter.process(context);
}





[color=rgba(0, 0, 0, 0.96)][color=var(--ds-text-primary)]Notes and suggestions[/color][/color]

• [color=rgba(0, 0, 0, 0.96)][color=var(--ds-text-primary)]For different sample rates, recompute coefficients via bilinear transform or design an IIR from theanalog poles/zeros for the new sample rate.[/color][/color]
• [color=rgba(0, 0, 0, 0.96)][color=var(--ds-text-primary)]For better numeric stability use an SOS cascade of first‑order sections (two 1st‑order filters) —implement as two dsp::IIR::Filter instances in series.[/color][/color]
• [color=rgba(0, 0, 0, 0.96)][color=var(--ds-text-primary)]In plugins, ensure processing is real‑time safe and avoid heavy allocations inprepareToPlay/processBlock.[/color][/color]

[color=rgba(0, 0, 0, 0.96)][color=var(--ds-text-primary)]If you want, I can generate:[/color][/color]

• [color=rgba(0, 0, 0, 0.96)][color=var(--ds-text-primary)]the two 1st‑order section coefficients and an example chaining two dsp::IIR::Filter instances, or[/color][/color]
• [color=rgba(0, 0, 0, 0.96)][color=var(--ds-text-primary)]code that recomputes coefficients at runtime for arbitrary sample rates. Which would you prefer?[/color][/color]

Thank you, but I generally do not use AI. It produces only garbage anyway. Previous is free from AI generated code.

Back to my question:
Does anyone know how to implement de-emphasis for CD standard emphasised audio at 44,1 kHz?

You can find some info about CDDA de-emphasis here (https://wiki.hydrogenaudio.org/index.php?title=Pre-emphasis). Maybe it can lead in the right direction. SoX has a de-emphasis filter for example.

@Protocol 7
Thank you very much for the link. I had a look at cdda2wav and it seems to confirm my findings. I'll do some testing during the weekend.