News:

Stuttgart museum purchases 40 NeXT machines from Rob Blessin

Main Menu

Recent posts

#41
Software / Re: Programmatically Controlli...
Last post by marvin - Feb 02, 2026, 10:48 PM
Hi @tygre , please have a look at the freeware Journaler .app from 1994.

Attached are:
Journaler.NIHS.bs.tar.gz from next-ftp.peak.org
Journaler.NI.bs.tar.gz  from Peanuts.

From their Journaler.README  :
QuoteWhat does this program do?

This program records mouse and keystroke events that occur within any application (or applications) you want, allowing you to save these events, and play them back later, thus recreating the exact sequence of events you recorded.
Maybe you can find some inspiration from the included source code.
#42
Software / Programmatically Controlling P...
Last post by tygre - Feb 01, 2026, 10:32 PM
Hi there!

I've been developing AmiModRadio for Amiga computers, to download and play music from the Internet, and I'd like to learn NeXT programming by writing a similar program for my NeXTStation :)

I'm completely new to NeXT programming and it seems that NeXTStep doesn't have something like ARexx so I wonder if there's a way to control another program programmatically? Or maybe to control the mouse to mimic a user clicking here and there?

Cheers!
Tygre
#43
Virtualization / Re: What Needs to be done for ...
Last post by andreas_g - Jan 26, 2026, 06:09 AM
@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.
#44
Virtualization / Re: What Needs to be done for ...
Last post by marvin - Jan 25, 2026, 02:15 PM
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
#45
Virtualization / Re: What Needs to be done for ...
Last post by marvin - Jan 25, 2026, 01:36 PM
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
#46
Virtualization / Re: What Needs to be done for ...
Last post by andreas_g - Jan 23, 2026, 03:32 PM
@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)?
#47
Software / Re: Exploring the NeXT user in...
Last post by Rhetorica - Jan 23, 2026, 05:17 AM
Quote from: ZombiePhysicist on Jan 22, 2026, 09:27 PMYou mentioning Art Lebedev made me re-regret not getting that short lived OLED keyboard, the full one! I thought for sure there would be a version 2 (of the full version) etc. Could have would have should have.

https://www.artlebedev.com/optimus/maximus/

Yeah... I read a review once where the reviewer said that it was so huge and solidly-built that he would rather use his Optimus Maximus to defend against an intruder over a baseball bat. But I think the keys were so large that they were pretty awkward to use.
#48
Software / Re: Exploring the NeXT user in...
Last post by ZombiePhysicist - Jan 22, 2026, 09:27 PM
You mentioning Art Lebedev made me re-regret not getting that short lived OLED keyboard, the full one! I thought for sure there would be a version 2 (of the full version) etc. Could have would have should have.

https://www.artlebedev.com/optimus/maximus/
#49
Software / Re: Exploring the NeXT user in...
Last post by Rhetorica - Jan 21, 2026, 11:41 PM
Time to finally sit down and work on this! Starting with...

Imperfections in Icons and Other Image Assets

Most of NeXT's graphical assets were either created or reviewed by Keith Ohlfs using his image editor, which was a fork of Icon.app. This was divested as AppSoft Image during the great 3.0 demo purge. Its replacement, IconBuilder.app, is a much less capable tool than what Image became.

Keith was not only a talented graphics designer, but also a curious and imaginative programmer. He regularly pushed his self-made tools to their limit, as we'll discuss later in The most beautiful gradient in the world and the NS 3.0 tertiary palette. However, there are a few flaws in NeXT-made image assets that we can find, roughly groupable into four categories:

a) Images with stray pixels

disk-2.png

Probably the best-known imperfection in the NeXT interface, the color version of winchester.tiff has several stray pixels at the top of the image that appear to just be noise. These errors aren't present on all versions of the disk platter icon:

disk-roundup.png
...this reveals a genealogy of the icons: it was hard to remove (or re-do) the yellow ray once it was created for openWinchester.tiff, so every asset designed based on it (like mac_HD.openfs.tiff) was free of the yellow pixels. Probably DOS_HD.openfs.tiff (not shown, but free of the yellow pixels) was made before DOS_HD.fs.tiff, and then spliced together.

Since the most prominent pixels are yellow, I suspect the junk originated as an erased rough draft of the open ray that targeted a different part of the icon. Likely it was invisible against a pale transparent matte, perhaps aggravated due to the NeXT's unusually high gamma (2.2).

b) Images with baked gamma

Speaking of gamma, if you've used a NeXT machine for any time at all, you've certainly run across icons and other assets that look poorly lit on modern displays. These are almost entirely a third-party software problem, and they're usually caused by gamma conversion when importing a photo from a camera, but not always:

bad-gamma.png

However, notably, there are some NeXT assets that suffer, like the CD player:

bad-gamma-cd.png

A purposefully-designed "dark" interface on a modern display would not still have such bright highlights. The NeXT gamma curve was specifically chosen so that #555 (33%) would be 50% brightness and #aaa (67%) would be close to 75% brightness. This is actually a key source of the enduring appeal of NeXT assets—displaying them with a modern gamma makes the gradients seem brighter and richer than they were meant to be!

The biggest and most familiar error, though, is the login screen. Here's what it looks like:

login-bad-gamma.png

See how bad the "Name" and "Password" text looks? Clear evidence that the gamma is wrong! Here's a reconstruction of what it should probably look like, based on a 'modern' gamma:

login-good-gamma.png

(Unfortunately I had to replace the 'Name' and 'Password' asset, but the graphics are otherwise original. The Restart and Power glyphs are much less jarring now.)

c) Images with rough alpha edges

NeXT was a pioneer in using alpha channels in the interface, but there were always places where corners got cut. For whatever reason, most of the ugly specimens are part of, or adjacent to, Mail.app, which was unusually demanding in the number of color graphics it needed during the 3.0 color uplift:

alpha-icons.png

d) Bad digitizations

Most prominent in the Mailbox icon, whenever there's a photographic element or a 3D render being used as a NeXT asset, it generally has distracting pattern dithering applied to it. This has a multitude of causes ranging from inferior camera sensors to sloppy conversions to 12-bit RGB, but it will never not remind me of the muddy images produced by a GameBoy Camera...

dithering-roundup.png
I will also will never not be annoyed at the lazy lock icon—it violates Art Lebedev's law of perpendicular alignment, and is probably the single worst asset in NEXTSTEP, from a production perspective, even though it doesn't have a bad alpha edge.

The timezone selection map asset had an unusually long afterlife and was last seen (complete with bad dithering) in Mac OS X 10.1:

osx-macosx101-1-2.png

...but we'll talk more later (much later) about the gradual extinction of NeXT UIs in Rhapsody and OS X.
#50
Virtualization / Re: What Needs to be done for ...
Last post by marvin - Jan 21, 2026, 04:31 PM
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