There's something beautiful (and slightly jarring) about a computer where the ethernet and VGA ports are each bigger than the entire CPU and RAM. For all that it may have slowed more recently, Moore's law really did hit it out of the park in the long run:)
People used to get productive work done on DECstations, they were big and expensive in their time. Now we can recreate them for just a few dollars (plus the cost of a screen and keyboard). Today almost everything we do relies on the internet, so a wifi driver would be useful as well.
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.
My PhD was done in a DECstation 3100. The physics lab was a VAX environment (everyone had VTxxx terminals in their desk) but someone had bought a 3100, not figured out how to use it, and it was sitting in a corner - normally switched off. I managed to persuade them I could put it to use when I joined the group, and about 6 months later everyone else in the group had Unix workstations too… we named them all after asterix characters, mine was getafix.
When I started college in the fall of 1993 we had hundreds of DECstations. A mix of 2100 black and white machines, 3100, and a few 5000 machines. That's where I learned C/C++, ran Spice and various logic simulators. DEC had already announced the Alpha but the college decided to move to Sun and HP-UX which was probably a good decision because there was more software available for those platforms.
It was great to be able to walk up to any DECstation on campus, log in, and immediately get your desktop setup exactly the way you like it, without having to carry anything around with you all day. Displaying apps from remote Sun or the sweet new Alpha machines, too. Good times.
> walk up to any DECstation on campus, log in, and immediately get your desktop setup exactly the way you like it, without having to carry anything around with you all day.
I had a similar experience in college. Centralized home directories and X11 went a _long_ way. I loved it (still do, and prefer Remote Desktop to local compute most times).
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
My school used AFS. It was great being able to use ACLs to give a specific student and no one else access to a directory in my account. Then we could make groups of students for group projects. Then I got a job in 1997 and it was back to traditional Unix groups where you need root or NIS admin access to create and modify groups. It's 2024 and I work at a company with 8,000 people and it still takes a few days to get multiple Unix group access for everything on a new project.
I've thought about trying out AFS; there are apparently open source server and clients available, and it seems to have some different design choices to let it work nicely over WAN compared to NFS. Less clear that the FOSS versions do the user/permission management stuff (though maybe they do), but that wouldn't matter as much for personal use.
Debian has the packages and some decent README's for setting up a server. OpenAFS is a later version than the IBM AFS you might have seen in the 90s and it has all of the user-management and ACL-related features - which are quite useful for personal use (sharing files with specific friends, instead of the entire internet; insert-only directories are also useful for that kind of thing.)
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.)
I'm not actually sure. We have a web page where we request group access and then I think it emails another project lead and they have to approve it but I don't know how it all works.
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.
I had a 3100 on my desk for several years, with an LK201 keyboard and a 19" color monitor, running Ultrix 4.2/3/4 iirc.
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.
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.
The DMA Sniffer is part of the RP2040 DMA engine. It can perform a variety of functions on the DMA'd data, including CRCs, accumulation, bit-reversal, etc. I use the accumulation function to increment the address contained in the HyperRAM command packet after each scan line is DMA'd from HyperRAM to the scan line buffer. This allows re-use of the HyperRAM command packet, eliminating the need for a per scan line packet (3 uint_32s per scanline). Important for the emulator, as it runs out of RP2040 RAM (vs. flash).
Thanks. This got me curious enough that I'm now reading the datasheet. It seems exciting enough that I may likely choose it for my next project that requires a microcontroller. (When I don't want to use FPGAs, which I tend to overuse because I'm a big fan of them, and because cost margins usually don't matter private projects.)
Maybe you'd like to help me get this over the finish line? I'm looking at a steep learning curve, trying to write a Lance chip emulator. I have been able to get LWIP to run on the DECstation HW. (Though Rev 2.1 does exhibit some packet drops which I'm looking at. Hopefully, there's some slight difference between the LAN8720a on the Waveshare boards, and the LAN8742 on rev 2.1 that needs some software...)
Wow! Really pushes the capability of the RP2040 to add a Memory Management Unit for the external RAM and incorporate DMA and a VGA display. The PIO on this chip is amazingly flexible.
“ 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.”
Well the RP2040 was released over 3 years ago... there have already been many interesting things that have been built with the capabilities. I wouldn't call this just the beginning.
My university was a DEC shop, 6000 and 8000 series in the machine room and DECstations and VAXstations in the lab, and a million vt320s for the masses in the terminal rooms. All †his project is missing as a candle that generates the smell of hot dust on CRT guns.
I know, really? It's hard to appreciate future shock until you bump into it. When cheap microcontrollers can emulate big-league workstations of the past, you know you're in the future. We long ago reached the point where you could emulate a PDP-11 faster than any real one ever built.
I run 3 IBM 4381's with Hercules (and two Altair Z80 machines, with SimH) out of a Docker Swarm cluster of four RPi Zero W's mounted inside an Ikea picture frame.
Related, but is there a way to emulate a VT520 on a Pi using opensource? Just want to have a replica that looks like the ultimate form of that extinct lineage.
As ex-owner of VT510, I'd say it's not really the ultimate form other than VT5xx being the last series from Digital.
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.
That's "custom character support", or properly DRCS - Dynamically Redefinable Character Sets, not full SIXEL graphics.
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.
I want to know if they have a patched version of Ultrix or a license file that allows more than two users? Ultrix on a MicroVAX was my first contact with a Unix system. Then briefly some SunOS 4.x and then extensively Ultrix on DECstation 3000. But while you can do some fiddly show and tell stuff without a license, only being able to have two process owners, one of which is root, is kind of limiting.
Interests me how little mention of Ultrix lies on the page. Pretty directly a BSD type, with some interesting twists, and the inclusion of DECnet support. the desktop was CDE?
OSF/1 was such a departure. Nice, but different. Strange days.
I would love to get one os these and run NetBSD it. NetBSD runs better than one might think on a system with 32 megabytes of memory and a relatively slow CPU.
RP2040 is a micro-controller and does not have an MMU. It cannot natively run any OS that relies on a MMU and that includes NetBSD. One can of course write an emulator that does and run that emulator on RP2040 and NetBSD on the emulator.
No. Misremembering naming and product changes from over 30 years ago.
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.
DEC had (at least) three workstation lines and they are very different beasts.
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.
