- Welcome to NeXTcommunity.
Recent posts
#51
Hardware / Re: NeXTDimension VRAM error
Last post by KennyPowers - Nov 07, 2025, 10:05 PMI finally got back around to looking at this board. Since the error noted a bad bit in the low-order byte at the first address in the framebuffer (0x2e800000), and the low-order byte is the "tag" byte in the ND's pixel layout (the upper 3 bytes store RGB color information), I was able to use the schematic linked above to identify the 8 VRAM chips that store the tag bytes across the framebuffer's address space:
However, I'm no longer thinking that I simply have a bad VRAM chip. I viewed the contents of VRAM using the method @andreas_g described. My board is passing the first test that fills the VRAM with 0xaaaaaa0a. It then immediately fails the second test, so the contents of VRAM *should* be this:
but when I read that same memory range at the NeXT> prompt, I get this:
It looks like there's some kind of aliasing going on, though I'm having trouble nailing down the pattern. 16-byte boundaries (every 0x10) are always wrong, though those aren't the only errors. It does look like some of the addresses at 16-byte boundaries are reporting the value that was supposed to be written to the previous 16-byte boundary. For example 0x2e800010 has 0x2e800000's intended value, and 0x2e800030 has ox2e800020's intended value, but that pattern doesn't always hold. Aliasing due to a bad address line(s) or something similar would explain why the first test that writes the same 32-bit word everywhere passes, though maybe it's also significant that the value the first test writes everywhere (0xaaaaaa0a) only ever sets even bits?
I also get the following strange behavior when writing 32-bit values into the VRAM:
Does anyone see a pattern or have any suggestions? Should I start trying to beep out address lines to the VRAMs?
However, I'm no longer thinking that I simply have a bad VRAM chip. I viewed the contents of VRAM using the method @andreas_g described. My board is passing the first test that fills the VRAM with 0xaaaaaa0a. It then immediately fails the second test, so the contents of VRAM *should* be this:
Code Select
2e800000: 00000001
2e800004: 00000102
2e800008: 00000203
2e80000c: 00000304
2e800010: 00000405
2e800014: 00000506
2e800018: 00000607
2e80001c: 00000708
2e800020: 00000809
2e800024: 0000090a
2e800028: 00000a0b
2e80002c: 00000b0c
2e800030: 00000c0d
2e800034: 00000d0e
2e800038: 00000e0f
2e80003c: 00000f00
2e800040: 00001001
2e800044: 00001102
2e800048: 00001203
2e80004c: 00001304but when I read that same memory range at the NeXT> prompt, I get this:
Code Select
2e800000: 00000000
2e800004: aaaa0102
2e800008: 00000203
2e80000c: 00000304
2e800010: 00000001
2e800014: 00000506
2e800018: 00000605
2e80001c: 00000708
2e800020: 00000001
2e800024: 0000090a
2e800028: 00000a09
2e80002c: 00000b0c
2e800030: 00000809
2e800034: 00000d0e
2e800038: 00000809
2e80003c: 00000f00
2e800040: 00000001
2e800044: 00001102
2e800048: 00001001
2e80004c: 00001304(Here's a photo of even more of the address space)It looks like there's some kind of aliasing going on, though I'm having trouble nailing down the pattern. 16-byte boundaries (every 0x10) are always wrong, though those aren't the only errors. It does look like some of the addresses at 16-byte boundaries are reporting the value that was supposed to be written to the previous 16-byte boundary. For example 0x2e800010 has 0x2e800000's intended value, and 0x2e800030 has ox2e800020's intended value, but that pattern doesn't always hold. Aliasing due to a bad address line(s) or something similar would explain why the first test that writes the same 32-bit word everywhere passes, though maybe it's also significant that the value the first test writes everywhere (0xaaaaaa0a) only ever sets even bits?
I also get the following strange behavior when writing 32-bit values into the VRAM:
Does anyone see a pattern or have any suggestions? Should I start trying to beep out address lines to the VRAMs?
#52
Software / Re: Window Maker Live (Linux d...
Last post by wmlive - Nov 06, 2025, 07:13 AMQuote from: jeffburg on Nov 06, 2025, 01:12 AMDid Debian trixie drop support for i686? And switch to 64 bit only?Yes, at least when it refers to the kernel and the installer. Here are the relevant details:
www.debian.org/releases/trixie/release-notes/issues.en.html#i386-reduced-support
From our hardware nostalgia point of view this certainly is a bit unfortunate, while understandable from the developer perspective.
Just like it is also the case for qemu, most Linux distributions are not aiming at supporting retro technology.
My theory is that a new generation of developers has grown up in a world already devoid of any of the hardware we older guys grew up with, and therefore there is no historic memory nor any nostalgia or interest regarding what us oldtimers constructed the open source world with. When i started with computers and Linux in 1995, the IT landscape was a completely different world from now. This is a memory all those youngsters never had a chance to gain.
#53
Software / Re: Window Maker Live (Linux d...
Last post by jeffburg - Nov 06, 2025, 01:12 AMDid Debian trixie drop support for i686? And switch to 64 bit only?
#54
Software / Re: Window Maker Live (Linux d...
Last post by wmlive - Nov 05, 2025, 02:13 PMGood news for users of old i686 Pentium class machines:
It is perfectly possible to build a Franken-wmlive for 32-bit with (almost) all the bells and whistles by combining the Bookworm installer/kernel with the current Debian/Trixie i386 software pool.
While a few packages (e.g., opensnitch) are not available, everything seems to work as usual.
So, unless a showstopper suggests otherwise by mid-November, there will also be an i386[1] version of wmlive.
[1] In Debian parlance, i386 refers to the generic CPU architecture, while the associated linux kernel and userland as a bare minimum require hardware with i686 CPU capabilities.
So, effectively, actual i386 and i486 machines are not supported anymore since long time already.
It is perfectly possible to build a Franken-wmlive for 32-bit with (almost) all the bells and whistles by combining the Bookworm installer/kernel with the current Debian/Trixie i386 software pool.
While a few packages (e.g., opensnitch) are not available, everything seems to work as usual.
So, unless a showstopper suggests otherwise by mid-November, there will also be an i386[1] version of wmlive.
[1] In Debian parlance, i386 refers to the generic CPU architecture, while the associated linux kernel and userland as a bare minimum require hardware with i686 CPU capabilities.
So, effectively, actual i386 and i486 machines are not supported anymore since long time already.
#55
Virtualization / Re: What Needs to be done for ...
Last post by wmlive - Nov 05, 2025, 11:43 AMTrying 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.
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.
#56
Virtualization / Re: What Needs to be done for ...
Last post by jeffburg - Nov 05, 2025, 02:32 AMAt 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.
#57
Virtualization / Re: What Needs to be done for ...
Last post by andreas_g - Nov 04, 2025, 06:03 PMThese 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.
#58
Virtualization / Re: What Needs to be done for ...
Last post by Rhetorica - Nov 04, 2025, 02:08 PMFor 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, 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.
#59
Software / Re: Window Maker Live (Linux d...
Last post by wmlive - Nov 03, 2025, 02:46 PMHere is a short demonstration video of the wmlive-trixie desktop options as seen from the perspective of the first login after installation.
Some details are still subject to change for the final release version.
https://vimeo.com/1133130552
Some details are still subject to change for the final release version.
https://vimeo.com/1133130552
#60
General Discussion / Re: NeXT history and folklore ...
Last post by ZombiePhysicist - Oct 29, 2025, 04:24 PMA great find of multiple interviews with ex-NeXT people by @jeffburg from this thread:
https://nextcommunity.net/forums/index.php?topic=55.0
https://nextcommunity.net/forums/index.php?topic=55.0