A RP2040 based DECstation 3000 emulator that can run DECWindows
github.com
github.com
Many things we do today require more processing power, but many things do not. Writing, terminals (well SSH could be a problem), email, hn. We used to do raytracing on a DECstation, had to use a remote X window to view the finished image in colour.
You would think that a certain subset of people would quite like a simpler system today to work on, but I guess it's just easier to buy something modern with all the extra layers of complexity.
Maybe this is because today programming largely relies on having access to the accumulated knowledge of the internet, and a very complex web browser.
It was snappy enough running plain X11 or Athena (Xaw) applications, but Motif stuff slowed it down a bit. I had a tvtwm running a big virtual desktop, an Emacs with a bunch of frames, and a stack of Xterms.
We had a couple of 5000/25's with the multimedia peripherals, but they weren't really worth it. IIRC, our group's server was a 5000/240 (?)
Then we moved to Alphas (3000 AXP, then 4/255), then a Sun Ultra 10, and finally Linux PCs.
Just X over the network, or something fancier?
being DecStations though it might have been using the whole DCE/RPC ecosystem (which was later adopted by MS for MSRPC and hence NTLM and SMB/CIFS).
https://en.wikipedia.org/wiki/Project_Athena
Everything was encrypted through Kerberos and AFS. We had a mix of workstations running DEC Ultrix, SunOS, Solaris, HP-UX, SGI IRIX, IBM AIX, and Linux.
The computing center compiled every GNU utility and put those in the PATH first so the environment was basically the same and you rarely had to worry about what type of machine you were on. We could ask a student who worked in the computing center to compile some new X11 window manager and they would and install it for all the different architectures and using AFS @sys string it would transparently link to the specific binary for that platform so you didn't need to modify your PATH
We had Zephyr instant messaging and the .anyone file where you could put all your friends in a file and see who was logged in. We would send Zephyr messages on some broadcast groups and see who wanted to meet up for lunch. I made friends with people I didn't even know before through that.
This was all from 1993-97 and then I got a job and it was like the stone age with NFS / NIS groups and chmod permissions. We are now creating stuff like zephyr with Slack
It's definitely not for most people - it's a lot of sysadmin work for a homelab (though it does get you volume-level replication and shuffling, but you don't really get much out of that unless you have at least two machines as servers.) You're also going to need a personal kerberos realm (which isn't much work, it's just One More Thing.)
Then we have another internal command that we run in every new shell where we include the groups we want access to. It runs and if we run the "groups" command before and after we see the new groups. But there is a limit to the number of groups so it is a pain if you need to access multiple projects at the same time because libraries and stuff are in different project areas.
For anyone interested, it's still very worth visiting that link, as it describes the whole journey and technical details about how the original DECstation emulation code came to be.
Since I have you here, what is the "DMA Sniffer" that you mention in your doc? A very quick search on the Internet didn't reveal too much.
“ The PSRAM/HyperRAM PIO engine provides 42/32 MB/s (write/read) of memory bandwidth. Further, four PIO engines are used to provide four seperate read/write memory ports. This allows independent memory access for the emulated CPU, video DMA, and receive/send Ethernet traffic.”
They're like general-purpose Amiga Coppers. You can program them to control I/O lines and they will just do the I/O, independent of the CPU.
This emulator is probably just the beginning of really cool things that will be built with the Raspberry Pi Pico.
This is another great way to understand what computers getting faster by three decimal orders of magnitude means :-)
The VT320 (+ VT330) seem to also be supported, are also on that list, but not the VT340 mentioned in sibling post.
For ultimate expression of Digital's VT series I'd rather go for VT340+, which supported both SIXEL and ReGIS graphics in colour. VT525 has colour graphics, but I can't find any mention of either SIXEL or ReGIS support on it.
It's essentially a way to send custom "font" to terminal. You could push it to get certain level of graphics, but it's not the same as capability of sixel bitmap.
OSF/1 was such a departure. Nice, but different. Strange days.
edit: Emulators, of course!
Remember that OSF/1 was an attempt to win the UNIX wars.
The later versions of ULTRIX had lots of BSD4.3 features that really made the move to ACP based systems feel more like a silicon change than a new OS from an admin perspective, even if not mach based.
Anything that ran bind and pop was running a later version with the bsd4.3 TCP/IP stack.
rscott2049, you sir, have earned yourself a follower on GitHub!
And I'd love to follow you on other Social Media as well -- if you have any other Social Media accounts!
1. DECstation: MIPS CPU, running Ultrix, DEC's own traditional UNIX, despite CEO Ken Olsen's claim that "UNIX is snake oil."
2. VAXstation: VAX minicomputers in a workstation form-factor. Only later models had single-chip CPUs, I think: the earlier ones were multi-chip CPUs. The CISCiest of CISC processors in the 1980s/1990s. Could run VAX-VMS or various UNIXes as this is one of the original architectures Unix grew up on. So it can run Ultrix, or original BSD, or NetBSD, or older versions of OpenBSD, and others.
3. AlphaStation: 64-bit RISC microprocessor. Came in 2 firmware variants, one for VMS or OSF/1 Unix, and a different one for Windows NT.
The Alpha machines were an order of magnitude (or 2+ OOM) times more powerful than the DECstations, and there is no realistic hope of emulating them on an RP2040 or low-end Pi, machines considerably less powerful and capacious than the host.