Specifically, I think at least, (edit: some but not all) PowerPC CPUs natively supported using either endianness, though it started in in big endian mode by default.
Software rendered OpenGL! Honestly, even in this video, it looks to be faster than many Windows 95 computers ran it "back in the day" -- when they were on a 486 without a 3D accelerated card.
Great job with RISC NT here, thanks! I used to manage a Alpha server or station (pizza box style) with NT 3.51 running Lotus Notes Server 4.1 with IPX/SPX stack for local network and TCP/IP for a 64kbps link to a database and mail hub in NJ, back in 1997. We've upgraded with to NT4.0 with an SP, had to learn about ARC. With time, we moved into a Compaq boring tower server and moved away from SPX/IPX to only TCP/IP. Another companion Notes server (before they were named Domino) was a a 16-bit Notes Server 3.x running on OS/2 2.x with same SPX/IPX stack from Novell client. Fun times. I was extremely lucky that the flat network ran IPX with no issues and automatically. Unfortunately I was not allowed to inherit the retiring Alpha.
NT was decidedly *not* originated by the Microsoft/IBM venture, that would be OS/2. NT was a new OS developed by Dave Cutler, a lot of inspiration came from DEC's VMS operating system.
@@NCommander Maybe he means participation from IBM in the NTOS2 project was almost zero. And he's maybe right... Because the own IBM attempt to do their own "NT" sucks completely (Taligent and OS/2 for PPC). Now I'm aware some MS and IBM people worked together in the port of the Presentation Manager and Family API for the NT (Cruiser project) but that's almost all. According the novels and books in the respect, Cutler never let that team be near his Kernel team people.
been waiting for the return of longform videos, so happy to see you back posting again. You do the things other people think "wouldn't that be cool, wouldn't that be wierd" But they don't have the skills to make it happen, and you bring those things into reality, its so cool.
It's nuts how Windows NT at one point supported so many different RISC architectures.......only to drop it literally the next few versions or service packs.
This is the 90’s and Pentium 1 to 2 to 3 meant “Well there’s a clear winning price / performance architecture here…” And then they looked at adoption of the various architectures - they knew sales of MS office on MIPS or whatever
- To be fair... The whole PowerPC scene in the desktop was completely BAKED, with exception of the Apple PowerMacintosh platform (CHRP btw, with some Apple sauce like the PowerManagement controller and the SWIM). The OS/2 for PPC (IBM's version of NT with the Mach kernel and multiple OS personalities) never materialized, and the Solaris PPC only survived one release, with not even Sun made compilers (I guess them used Metaware ones). BeOS promised a lot, but fizzled soon after Apple went full NeXT. The whole platform was very picky and prone to hardware issues. -NT could run in CHRP as well, just not IBM's CHRP, and not the last CHRPs with memory controllers without endianess switch. Apart of the NewWorld Mac port done by the defunct Firmworks OpenFirmware provider in colaboration with MS and Apple, which never reached the public and never has leaked as well... In the NT4 CDROM there is support for the Canon/Firepower Powerized series. These are CHRPs with OpenFirmware, and the VEENER executable in the PPC directory of the NT4 CD is the proof it was running on them out of the box. - The Wx86 thunking emulator made by MS not only lives in the licensed products from Insignia (SoftWindows32 for NT) or Dec (FX!32). It still lives today in the WoW64 compatibility layer existent since Windows XP x32-64 and the ARM Win32 emulation on ARM versions of Windows. Even some of the symbols still retain the nomenclature Wx86* from the original techdemo back then. - The only CPU flavor of all the NT4 RISC builds which received the full six SPs was the Alpha version. It even got an special Terminal Services build with the WinFrame Kernel code which MS got from Citrix. The rest died prematurely, with MIPS being the first to be ditched, and then followed by the PPC build. Supposedly the NT4 port for the Macintosh NewWorld was SP3, but since never got leaked, is hard to tell if that was true at all.
@@NJRoadfan Yeh, but in the state it was released it looks more like a Beta than a RTM build. For example, the DOSVDM was in a pretty good state, but the multimedia and networking was almost unfinished. The Multiple OS personalities was cut, and only you got the OS/2 and the DOSVDM ones. I guess there was no finished WinOS2 too as well. That said, one of the things which made debut in this OS build was the GRADD display driver model, which was backported later to OS/2 v4. According the OS/2 guys, is a good driver model and actually helped the ARCA guys with their OS/2 UEFI port (still unreleased, only a few video demos available here in yt).
Edit: I've watched the video, but this is still relevant. So I see the thumbnail, having not watched the video, and see Chocolate Doom. You know, that port that strives for accuracy to the original above all else, often trading performance for quality in the process? But, I know of another open source port, NTDOOM. Literally built *for* Windows NT, in the days when having decent performance was still a big deal. I wonder if you messed with that - or even know of its existence. Because, I bet it'd run better than Chocolate Doom on these old machines *by a mile.* Also, Rairii, aka Wack0, was the one responsible for the gigaleak, which if you know, you know.
I use a modded s3 trio64 that I flashed with the GXT110P rom on my rs/6000 43p-140. I had to replace the rom chip with a 64k one, but those are pretty cheap on ebay and thanfully the chip was socketed. It's probably the cheapest card that will work in both the firmware and NT, with a little effort. It works in AIX too, but I had to upgrade the video memory to 4mb, otherwise the display was garbled. Also fun fact: openfirmware apple video cards will work for getting video in the firmware on the 43p-140(and other openfirmware rs/6000's i'd assume). When I was messing around with linux on my 43p, I used an apple rage128gl for the video, and it worked in both the os and firmware.
I liked the splash screen of VC 4 and 4.1 back in the day, where it shows you 4-5 products (the 5th was added when you installed Visual J++) in a transparent way and then made those opaque (="active") that you had installed as seen at 08:34. Useless, but I liked it ;)... I think they replaced it with a static one in VC 4.2.
NT was really a great move by Microsoft, a small team of highly experienced engineers created a solid foundation. I stopped using 98 when I installed 2000.
Technically Windows for ARM is a RISC Port OF NT but it will pretty much share no "DNA" with the Original RISC ports other than being NT. NT had a lot of changes moving from 4.0 up to 6.0, even the boot loader completely changed getting rid of ARC paths in the process, a modern Hal will have little in common to the old ones not that you'd expect a Modern ARM system to have much of anything in common with 90s RISC systems.
ACPI and UEFI solved a lot of the problems that ARC was created to solve. Might as well go with the cross-platform standard since IA64 also had EFI and ACPI, and all future platforms can reasonably support it, which really does simplify a lot.
UEFI and ACPI are the spiritual but direct successors of the ARC firmware and ARC device tree. No wonders, as MS worked with Intel and other vendors from the OnNow initiative to do it. As for the bootloader, BootMGR still maintains the same arragement than the old NT ARC bootloader. You have a firmware or a firmware emulator (TianoCore, the STARTROM 16Bit module prepended in the BootMGR executable for PCAT), while the loader itself is a PE executable which can be compiled in the platforms with no changes to its core. This allowed for example, the port to the RPi without the need to flash the thing with a different firmware, as it can load it from the disk, and then boot the standard UEFI loader (compiled for the ARM, ofc).
Looks like some endianness problems in the Choco icon. Hopefully you can get a copy to Rairii for his cursed ports of NT to Wii and PowerMac, I'm sure he'll be appreciative. Sooo.... when are you going to cover POSIX subsystem on PowerPC NT?
The RS/6000 43P Type 7248 Model 132 has an onboard AMD PCnet-PCI II. This machine is on the NT4 HCL so everything, including the onboard NIC, works fine as you'd expect - no BSODs or other instability so far.
Bug check 0x80 means the hardware is triggering an NMI (which is an automatic bugcheck on windows nt), I almost wonder how much “proper” hardware would’ve improved stability (or not)
It might be possible to rewite an inf for a different card basicly use the inf to lie to windows about the card installed. I've done that to get unsupported hardware into different systems. Ive also used it to generate fixed frequency monitor timing in the past. There I attached the unspported monitor to a second Matrox MilleniumII card and used that card's advanced 2D pixel timing to work out the monitor's signal timing for different resolutions and the wrote my own monitor.inf for rhe model.
great video as always! do you know by any chance if there's opensource or recreation project for NT kernel? it would be great to have it running on sparc for ultimate cursed experience...
The ReactOS kernel would probably be the closest thing to an open source Windows kernel recreation, although it's more modern (Server 2003 level) and afaik currently only runs on x86 and x64
@@moki5796 ReactOS is too reliant these days on ACPI, but more important, on modern compilers to get it running. You would need a GCC toolchain more or less updated targeting these old PPC processors to compile it at least. Good thing is their stuff is pretty crosscompiler compatible, so you can do it from your everyday desktop on Windows or Linux, proving there is a working and GCC modern crosscompiler targetting the CPUs.
For 233 MHz, that Doom performance seems rather poor (granted, could be GDI overhead or similar; or overhead within SDL, ...). For my own makeshift ISA that can run on an FPGA at 50 MHz, I can get around 20-30 fps in Doom. Quake puts up a much bigger challenge though, only rarely breaking out of single-digit territory On my own ISA, I changed focus mostly to GLQuake, as ironically my OpenGL implementation is faster than Quake's software renderer. The CPU can also run RISC-V (RV64G) via an alternate instruction decoder (as a 2-wide superscalar), but on the RV64 ISA software Quake is faster (though mostly because my OpenGL implementation performs rather poorly in this build; RV64 is pros/cons). I had recently also gotten a Quake 3 port working on my ISA, but at 50 MHz I wouldn't really call it "playable"... (Would likely need closer to 200 MHz). Performance relative to older PCs is more difficult to determine (and varies wildly depending on task). Could go into specifics, but I have found/suspect, most people don't care. Is is basically an ISA with variable-length LIW bundles and 64 GPRs with FPU and SIMD mapped into GPR space; for RV64G mode it splits the register space in half, using the high 32 registers as FPRs.
NT was notoriously kinda shit in graphics performance. NT 3.51 struggles to draw Space Cadet Pinball over on period correct hardware if you copy it from NT4. DirectX made it better, but this is using GDI under the hood, and I probably had other things to do to make it work better.
@@NCommander I am old enough that I was running WinNT4 back when I was in middle school (but jumped to Win2K in high school; shortly before WinXP came out). Didn't remember graphical performance anywhere near that bad, could run WinQuake and similar without much issue, ... But, this was on a 500MHz x86 PC. Do remember though that at the time a lot of games would refuse to run on NT4. I was mostly running it because I was a programming nerd and wanted an OS that didn't crash all the time (a bit of an issue with Win 9X). But, yeah, in any case, that level of poor graphical performance seemed unreasonably bad...
Running NT on Power Macs proved that it's possible to switch the endianness on Apple hardware. Maybe it's also possible to compile and run a little-endian Linux distro on a Mac, to fix the graphics issues when using an ATI graphics card, which are caused by big-endian🧐
Only PowerMacs with the "Grackle" chipset. Uninorth Macs (like the iBook and onwards) don't allow endianness switching in the chipset, only in the CPU, and G5 Macs can't be switched to LE at all.
13:05 I knew that it works in little endian because I'm not sure that NT even supports big endian mode to begin with. At least, I never heard of big endian NT ports before.
Also, I wonder if my project, xash3d-fwgs, will compile for this obscure platform. We recently moved to C99, and old Microsoft compilers are notorious for ignoring any C standards.
It's kind of sad when all the modern young youtubers call it pile of garbage from the experience on an unsupported "too-new" machine (the same now with all the G3 Mac NT testers). I have experience with PowerPC Windows NT on a supported machine (66MHz PPC 603) and it is rock solid and surprisingly fast. No BSODs except when I added a supported PCI 3D accelerator (it crashed in early boot) but even then I found that the issue was in the too new firmware in the card. When downgraded to the original version, everything went so smooth that NT4 configured the driver immediately without noticing the user that there is new hardware.
I have actual supported hardware (I got it shortly after this video was filmed); the experience is much the same. NT 4 SP 2 was garbage on x86 as well.
Visual Studio, and the MS C compilers in general used to be steaming TRASH before VS2003, and only became good enough in VS2008. No wonders why tons of software were built with anything but Visual Studio. Borland, Watcom/Sybase, Metaware, Symantec/DigitalMars, Metrowerks, etc... Them were big names in enterprise because Visual Studio was truly hard hot garbage. I wonder how many NT4 bugs would be fixed if NT4 was recompiled with at least VS2003. You would also gain access to better PDB symbols instead the COFF DBG ones.
It likely has to do with Windows coming from x86 and thus starting off as LE, so Microsoft wanted to keep Windows NT Little-Endian for PPC as well, so any code using binary data files wouldn't have to be rewritten for BE.
It’s interesting because most PowerPC platforms at the time were big endian.
I thought that PowerPC was big-endian only
Specifically, I think at least, (edit: some but not all) PowerPC CPUs natively supported using either endianness, though it started in in big endian mode by default.
@@redstone0234nope! IIRC only the very first iterations couldn't run in either big or little endian
edit: Couldn't run in big AND little endian and switch between the two. MIPS could do that too
Newbie question - is it because of the specific cpus that NT runs on being little endian, or its a choice made in software?
today I learned the 3D Maze screensaver runs on PReP hardware at about the same framerate as it runs on powerpc macs
Yes, that was painful to watch...
Software rendered OpenGL!
Honestly, even in this video, it looks to be faster than many Windows 95 computers ran it "back in the day" -- when they were on a 486 without a 3D accelerated card.
Great job with RISC NT here, thanks! I used to manage a Alpha server or station (pizza box style) with NT 3.51 running Lotus Notes Server 4.1 with IPX/SPX stack for local network and TCP/IP for a 64kbps link to a database and mail hub in NJ, back in 1997. We've upgraded with to NT4.0 with an SP, had to learn about ARC. With time, we moved into a Compaq boring tower server and moved away from SPX/IPX to only TCP/IP. Another companion Notes server (before they were named Domino) was a a 16-bit Notes Server 3.x running on OS/2 2.x with same SPX/IPX stack from Novell client. Fun times. I was extremely lucky that the flat network ran IPX with no issues and automatically. Unfortunately I was not allowed to inherit the retiring Alpha.
YES FINALLY AAAAAAA
NT was decidedly *not* originated by the Microsoft/IBM venture, that would be OS/2. NT was a new OS developed by Dave Cutler, a lot of inspiration came from DEC's VMS operating system.
It started life as Portable OS/2 3.0, and very early NT builds refer to itself as NTOS2.
@@NCommander Maybe he means participation from IBM in the NTOS2 project was almost zero. And he's maybe right... Because the own IBM attempt to do their own "NT" sucks completely (Taligent and OS/2 for PPC).
Now I'm aware some MS and IBM people worked together in the port of the Presentation Manager and Family API for the NT (Cruiser project) but that's almost all. According the novels and books in the respect, Cutler never let that team be near his Kernel team people.
the NT port to PowerPC, however, that was VERY MUCH done by IBM
been waiting for the return of longform videos, so happy to see you back posting again. You do the things other people think "wouldn't that be cool, wouldn't that be wierd" But they don't have the skills to make it happen, and you bring those things into reality, its so cool.
It's nuts how Windows NT at one point supported so many different RISC architectures.......only to drop it literally the next few versions or service packs.
They don't tend to marry ideologically to the projects they launch. Check what happened to Windows RT and Phone. No money earns, no support.
This is the 90’s and Pentium 1 to 2 to 3 meant “Well there’s a clear winning price / performance architecture here…”
And then they looked at adoption of the various architectures - they knew sales of MS office on MIPS or whatever
Lol at 6:11 you can see a Y2K glitch in the top right. It says its 1923
- To be fair... The whole PowerPC scene in the desktop was completely BAKED, with exception of the Apple PowerMacintosh platform (CHRP btw, with some Apple sauce like the PowerManagement controller and the SWIM).
The OS/2 for PPC (IBM's version of NT with the Mach kernel and multiple OS personalities) never materialized, and the Solaris PPC only survived one release, with not even Sun made compilers (I guess them used Metaware ones). BeOS promised a lot, but fizzled soon after Apple went full NeXT. The whole platform was very picky and prone to hardware issues.
-NT could run in CHRP as well, just not IBM's CHRP, and not the last CHRPs with memory controllers without endianess switch. Apart of the NewWorld Mac port done by the defunct Firmworks OpenFirmware provider in colaboration with MS and Apple, which never reached the public and never has leaked as well... In the NT4 CDROM there is support for the Canon/Firepower Powerized series. These are CHRPs with OpenFirmware, and the VEENER executable in the PPC directory of the NT4 CD is the proof it was running on them out of the box.
- The Wx86 thunking emulator made by MS not only lives in the licensed products from Insignia (SoftWindows32 for NT) or Dec (FX!32). It still lives today in the WoW64 compatibility layer existent since Windows XP x32-64 and the ARM Win32 emulation on ARM versions of Windows. Even some of the symbols still retain the nomenclature Wx86* from the original techdemo back then.
- The only CPU flavor of all the NT4 RISC builds which received the full six SPs was the Alpha version. It even got an special Terminal Services build with the WinFrame Kernel code which MS got from Citrix. The rest died prematurely, with MIPS being the first to be ditched, and then followed by the PPC build. Supposedly the NT4 port for the Macintosh NewWorld was SP3, but since never got leaked, is hard to tell if that was true at all.
OS/2 for PowerPC was indeed released.
@@NJRoadfan Yeh, but in the state it was released it looks more like a Beta than a RTM build. For example, the DOSVDM was in a pretty good state, but the multimedia and networking was almost unfinished. The Multiple OS personalities was cut, and only you got the OS/2 and the DOSVDM ones. I guess there was no finished WinOS2 too as well.
That said, one of the things which made debut in this OS build was the GRADD display driver model, which was backported later to OS/2 v4. According the OS/2 guys, is a good driver model and actually helped the ARCA guys with their OS/2 UEFI port (still unreleased, only a few video demos available here in yt).
Edit: I've watched the video, but this is still relevant.
So I see the thumbnail, having not watched the video, and see Chocolate Doom. You know, that port that strives for accuracy to the original above all else, often trading performance for quality in the process?
But, I know of another open source port, NTDOOM. Literally built *for* Windows NT, in the days when having decent performance was still a big deal.
I wonder if you messed with that - or even know of its existence. Because, I bet it'd run better than Chocolate Doom on these old machines *by a mile.*
Also, Rairii, aka Wack0, was the one responsible for the gigaleak, which if you know, you know.
Totally amazed how you get this software to run on these obsolete devices.
I use a modded s3 trio64 that I flashed with the GXT110P rom on my rs/6000 43p-140. I had to replace the rom chip with a 64k one, but those are pretty cheap on ebay and thanfully the chip was socketed. It's probably the cheapest card that will work in both the firmware and NT, with a little effort.
It works in AIX too, but I had to upgrade the video memory to 4mb, otherwise the display was garbled.
Also fun fact: openfirmware apple video cards will work for getting video in the firmware on the 43p-140(and other openfirmware rs/6000's i'd assume). When I was messing around with linux on my 43p, I used an apple rage128gl for the video, and it worked in both the os and firmware.
I liked the splash screen of VC 4 and 4.1 back in the day, where it shows you 4-5 products (the 5th was added when you installed Visual J++) in a transparent way and then made those opaque (="active") that you had installed as seen at 08:34. Useless, but I liked it ;)... I think they replaced it with a static one in VC 4.2.
NT was really a great move by Microsoft, a small team of highly experienced engineers created a solid foundation. I stopped using 98 when I installed 2000.
NCommander more like NTCommander! Another great video, thank you
hello, I am here to comment about little endian being kind of crazy for the time and it being a nightmare for me and my old projects :3
That's crazy, amazing job!
Happy to see you're back ^^
microsoft trying not to be intrinsically bound to x86 impossible challenge
When I see a new ncommander video POG
Technically Windows for ARM is a RISC Port OF NT but it will pretty much share no "DNA" with the Original RISC ports other than being NT. NT had a lot of changes moving from 4.0 up to 6.0, even the boot loader completely changed getting rid of ARC paths in the process, a modern Hal will have little in common to the old ones not that you'd expect a Modern ARM system to have much of anything in common with 90s RISC systems.
Kind of what you'd expect when there's no real good RISC hardware for nearly a decade.
ACPI and UEFI solved a lot of the problems that ARC was created to solve. Might as well go with the cross-platform standard since IA64 also had EFI and ACPI, and all future platforms can reasonably support it, which really does simplify a lot.
UEFI and ACPI are the spiritual but direct successors of the ARC firmware and ARC device tree. No wonders, as MS worked with Intel and other vendors from the OnNow initiative to do it.
As for the bootloader, BootMGR still maintains the same arragement than the old NT ARC bootloader. You have a firmware or a firmware emulator (TianoCore, the STARTROM 16Bit module prepended in the BootMGR executable for PCAT), while the loader itself is a PE executable which can be compiled in the platforms with no changes to its core. This allowed for example, the port to the RPi without the need to flash the thing with a different firmware, as it can load it from the disk, and then boot the standard UEFI loader (compiled for the ARM, ofc).
I just got done doing a sourceport myself to modern wayland linux from scratch just a little exercise. I love seeing your experiments with this also
yay new Ncommander, comfy! (i have no attention span for streams sadly)
Looks like some endianness problems in the Choco icon. Hopefully you can get a copy to Rairii for his cursed ports of NT to Wii and PowerMac, I'm sure he'll be appreciative.
Sooo.... when are you going to cover POSIX subsystem on PowerPC NT?
unrelated to the video but i just wanted to let you know that i finally beat blood cancer
heck langerhans cell histiocytosis, it can do die in a fire
Congrats!
Congrats
GG
Congratulations
Awesome and a lot of blessings!
8:12 That piece of software was made by the same company that made SoftPC for NeXTSTEP and the Apple Macintosh.
yay new video
Oh hey I’m someone interested in that endianness detail 😊
The RS/6000 43P Type 7248 Model 132 has an onboard AMD PCnet-PCI II. This machine is on the NT4 HCL so everything, including the onboard NIC, works fine as you'd expect - no BSODs or other instability so far.
then its something specific to this machine
I know running DOOM on everything is a long-running joke, but this one is particularly cursed, bravo
Thanks for this video. Been missing your content! 😅🫀
Sweet. Now do DooM on Plan 9 bare metal.
I was still surprised.
I am potentially the one person who found the little endian quip interesting.
I’ve spotted at least 2 others!
@@kaitlyn__L there must be a half dozen of us. He underestimated our power(pc).
Bug check 0x80 means the hardware is triggering an NMI (which is an automatic bugcheck on windows nt), I almost wonder how much “proper” hardware would’ve improved stability (or not)
my general impression is does not
I understood the "Showstopper" reference.
The long awaited sequel
It might be possible to rewite an inf for a different card basicly use the inf to lie to windows about the card installed. I've done that to get unsupported hardware into different systems. Ive also used it to generate fixed frequency monitor timing in the past. There I attached the unspported monitor to a second Matrox MilleniumII card and used that card's advanced 2D pixel timing to work out the monitor's signal timing for different resolutions and the wrote my own monitor.inf for rhe model.
At the mention of IBM AIX, a flood of fond memories involving 4Front/OSS4 came rushing back.
You should watch the AIX version of this video (its an hour long), I got OSS sorta working, although OSS3. I even bought a license.
Never thought to see the day an age where running doom on a fridge was easier than running it on an actual computer. 😅
Where I can found the full video that shows the compiling with visual studio?
There are livestreams. Click my channel, then click Live. They're from a year ago, although the final part of getting DOOM running was done offline.
a video above which i commented in
great video as always! do you know by any chance if there's opensource or recreation project for NT kernel? it would be great to have it running on sparc for ultimate cursed experience...
The ReactOS kernel would probably be the closest thing to an open source Windows kernel recreation, although it's more modern (Server 2003 level) and afaik currently only runs on x86 and x64
@@moki5796 ReactOS is too reliant these days on ACPI, but more important, on modern compilers to get it running. You would need a GCC toolchain more or less updated targeting these old PPC processors to compile it at least. Good thing is their stuff is pretty crosscompiler compatible, so you can do it from your everyday desktop on Windows or Linux, proving there is a working and GCC modern crosscompiler targetting the CPUs.
the files comes together they does
For 233 MHz, that Doom performance seems rather poor (granted, could be GDI overhead or similar; or overhead within SDL, ...).
For my own makeshift ISA that can run on an FPGA at 50 MHz, I can get around 20-30 fps in Doom.
Quake puts up a much bigger challenge though, only rarely breaking out of single-digit territory
On my own ISA, I changed focus mostly to GLQuake, as ironically my OpenGL implementation is faster than Quake's software renderer.
The CPU can also run RISC-V (RV64G) via an alternate instruction decoder (as a 2-wide superscalar), but on the RV64 ISA software Quake is faster (though mostly because my OpenGL implementation performs rather poorly in this build; RV64 is pros/cons).
I had recently also gotten a Quake 3 port working on my ISA, but at 50 MHz I wouldn't really call it "playable"... (Would likely need closer to 200 MHz).
Performance relative to older PCs is more difficult to determine (and varies wildly depending on task).
Could go into specifics, but I have found/suspect, most people don't care. Is is basically an ISA with variable-length LIW bundles and 64 GPRs with FPU and SIMD mapped into GPR space; for RV64G mode it splits the register space in half, using the high 32 registers as FPRs.
NT was notoriously kinda shit in graphics performance. NT 3.51 struggles to draw Space Cadet Pinball over on period correct hardware if you copy it from NT4. DirectX made it better, but this is using GDI under the hood, and I probably had other things to do to make it work better.
@@NCommander I am old enough that I was running WinNT4 back when I was in middle school (but jumped to Win2K in high school; shortly before WinXP came out).
Didn't remember graphical performance anywhere near that bad, could run WinQuake and similar without much issue, ... But, this was on a 500MHz x86 PC.
Do remember though that at the time a lot of games would refuse to run on NT4. I was mostly running it because I was a programming nerd and wanted an OS that didn't crash all the time (a bit of an issue with Win 9X).
But, yeah, in any case, that level of poor graphical performance seemed unreasonably bad...
Running NT on Power Macs proved that it's possible to switch the endianness on Apple hardware. Maybe it's also possible to compile and run a little-endian Linux distro on a Mac, to fix the graphics issues when using an ATI graphics card, which are caused by big-endian🧐
Only PowerMacs with the "Grackle" chipset. Uninorth Macs (like the iBook and onwards) don't allow endianness switching in the chipset, only in the CPU, and G5 Macs can't be switched to LE at all.
iirc there were beta builds of windows 2000 for ppc, mips and alpha.
Just Alpha, which lasted to Windows 2000 RC1
13:05 I knew that it works in little endian because I'm not sure that NT even supports big endian mode to begin with. At least, I never heard of big endian NT ports before.
Also, I wonder if my project, xash3d-fwgs, will compile for this obscure platform. We recently moved to C99, and old Microsoft compilers are notorious for ignoring any C standards.
I'm stretching things a bit, but the Xenon CPUs in the Xbox 360 were big-endian, and it used an NT derived kernel.
@@jamesweatherley7764 that's a good point.
Action Retro and MichaelMJD could try your Doom I guess in their G3
If something properly written in K&R C was to ever fail to compile, just walk away. 😂
It's kind of sad when all the modern young youtubers call it pile of garbage from the experience on an unsupported "too-new" machine (the same now with all the G3 Mac NT testers). I have experience with PowerPC Windows NT on a supported machine (66MHz PPC 603) and it is rock solid and surprisingly fast. No BSODs except when I added a supported PCI 3D accelerator (it crashed in early boot) but even then I found that the issue was in the too new firmware in the card. When downgraded to the original version, everything went so smooth that NT4 configured the driver immediately without noticing the user that there is new hardware.
I have actual supported hardware (I got it shortly after this video was filmed); the experience is much the same. NT 4 SP 2 was garbage on x86 as well.
What a legend, using Visual Code on NT with PPC can't have been very fun haha
Visual Studio, and the MS C compilers in general used to be steaming TRASH before VS2003, and only became good enough in VS2008. No wonders why tons of software were built with anything but Visual Studio. Borland, Watcom/Sybase, Metaware, Symantec/DigitalMars, Metrowerks, etc... Them were big names in enterprise because Visual Studio was truly hard hot garbage.
I wonder how many NT4 bugs would be fixed if NT4 was recompiled with at least VS2003. You would also gain access to better PDB symbols instead the COFF DBG ones.
@@hyoenmadanI know C++ is a beast of complexity and VC++ didn’t handle templates properly for a while. But was their C product just as messy?
We need a port of MinGW so i can support PPC and MIPs
I wonder where's the comment that explains why Windows NT for PPC running in little-endian is an interesting topic.
It likely has to do with Windows coming from x86 and thus starting off as LE, so Microsoft wanted to keep Windows NT Little-Endian for PPC as well, so any code using binary data files wouldn't have to be rewritten for BE.
The correct way to deal with the demo gods is to hope they don't notice you, for the demo gods are arbitrary and capricious.
nice video thanks man
Ah, soft windows. I mostly remember it for Macs. I also remember when Direct X came out and how a big pile of poo compared to open gl it was.
DOS, rhymes with floss, not DAHZ. 😂
(this user has not heard of the cot-caught merger)