So over on Modular Circuits, Andras had posted a promising ‘UNICOS Update‘ which had detailed that 2 CD-ROM’s of Unicos had surfaced on archive.org cray-cd1 & cray-cd2. Along with posting the updated source to github, so I had no choice to replicate the experiment!
First the install is INSANELY slow. It requires you to setup a Linux (or unix) machine with rsh. Surprisingly there is a rsh-server package for Ubuntu 22.04. Basically it boils down to following the instructions. Although with WSLv2 I ended up making the bridge manually with:
brctl addbr craybr ip tuntap add mode tap tap1 ifconfig tap1 up brctl addif craybr tap1 ifconfig craybr 172.16.0.1 netmask 255.255.255.0
It’s coded in the example configs to use tap1, but there you go. It’s a pretty straightfoward install but the decompression on the cray side takes the installation hours. As an experiment I changed the commands from rcp to remsh to gzip -dc the files locally on my PC, which had the benefit of of being much faster, and not taking up space.
I went ahead and uploaded both of my installs for anyone wanting to play OS tourist enough to check out UNICOS but not wanting to sit through the install.
The C compiler is.. ancient. and very touchy. You’ll need to add /usr/gen/bin to the path, and explicitly add the path for the linker like this:
/usr/gen/bin/cc zap.c -L/usr/gen/lib
Although the breakage is.. pretty epic. I had pretty much no luck bringing over any of my favorites. There should be a much better / modernish C compiler and Fortran compiler, although I’m not sure if it’s on these CD-ROM’s or I’m just massively ignorant of UNICOS, because I never got a chance to be anywhere near a legit supercomputer.
(this is a guest post by Antoni Sawicki aka Tenox)
Pleased to announce WRP version 4.6! After almost two years of no updates due to dependency issues I finally resolved everything. More frequent work should resume now.
The main improvement visible to users is the new GIF encoding. I have been struggling with poor GIF performance for quite a while. This was mostly manifested on lower end machines running WRP such as Raspberry PI or these micro instances in the cloud.
Thanks to invaluable work of Hill Ma we now have blazing fast GIFs. Probably order of 100x improvements! This comes at a cost of quality, especially of color palette and dithering. However worse quality of imagery has a surprise improvement of font/text quality which is what a lot of people wanted.
Note that by default WRP uses GIF with 216 “web safe” colors. We choose this not so much for number of colors but rather activation of the super fast GIF encoding.
When switching to 256 color mode the image look much better, however it takes around 25x longer to encode (7ms vs 170ms).
When using PNG this is of course not a problem.
0 height mode, which renders tall images of full page length has also been improved and is now more stable. Be careful when using very old machines with little memory as the images can be pretty big.
I hope that WRP will help you use your vintage computers more 🙂
I don’t know how the other various linux distros handle this but I found this by accident:
Nov 17 12:04:25 ukweb pppd: Using interface ppp0
Nov 17 12:04:25 ukweb pppd: Connect: ppp0 <--> /dev/pts/0
Nov 17 12:04:25 ukweb pptpd: GRE: Bad checksum from pppd.
Nov 17 12:04:25 ukweb systemd-udevd: Using default interface naming scheme 'v249'.
Nov 17 12:04:25 ukweb pppd: peer from calling number 188.8.131.52.1 authorized
Nov 17 12:04:25 ukweb pppd: MPPE 128-bit stateless compression enabled
Nov 17 12:04:27 ukweb systemd-networkd: ppp0: Link UP
Nov 17 12:04:27 ukweb systemd-networkd: ppp0: Gained carrier
Nov 17 12:04:27 ukweb pppd: found interface br0 for proxy arp
Nov 17 12:04:27 ukweb pppd: local IP address 192.168.0.1
Nov 17 12:04:27 ukweb pppd: remote IP address 192.168.23.10
Nov 17 12:05:28 ukweb systemd: Stopping PoPToP Point to Point Tunneling Server...
Nov 17 12:05:28 ukweb pppd: Terminating on signal 15
Nov 17 12:05:28 ukweb pppd: Connect time 1.1 minutes.
Nov 17 12:05:28 ukweb pppd: Sent 0 bytes, received 6937 bytes.
Nov 17 12:05:28 ukweb systemd-networkd: ppp0: Link DOWN
Nov 17 12:05:28 ukweb systemd-networkd: ppp0: Lost carrier
With the emphasis on “local IP address 192.168.0.1”. Which is *NOT* in my config. I went as far as adding a bridge to satisfy the proxy arp! Netplan is some yaml thing and yeah not a big fan.
And then I found it after doing what i should have done, and grep around to find out that pptpd.conf should actually live in /etc
Yeah that’s right, there is 2 of them although they should be the same. A symlink and a restart later, and now I get this:
Nov 17 12:19:56 ukweb kernel: [ 112.718861] PPP MPPE Compression module registered
Nov 17 12:19:56 ukweb pppd: MPPE 128-bit stateless compression enabled
Nov 17 12:19:58 ukweb systemd-networkd: ppp0: Link UP
Nov 17 12:19:58 ukweb systemd-networkd: ppp0: Gained carrier
Nov 17 12:19:58 ukweb pppd: found interface br0 for proxy arp
Nov 17 12:19:58 ukweb pppd: local IP address 192.168.23.1
Nov 17 12:19:58 ukweb pppd: remote IP address 192.168.23.10
MUCH much better. I don’t know if this is anything worth wriging about, but if I can save someone else an hour of wondering why the config isn’t working and why their pptp is always defaulting to 192.168.0.1 and why it’s wreaking havoc with any default home router, where here it is.
While trying to build some old stuff I ran into this weird issue where YYLESX is undefined:
gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../.. -I../.. -I../../include -g -O2 -Wall -c cs_grammar.c cs_grammar.y: In function ‘cs_parse’: cs_grammar.y:1074:58: error: ‘YYLEX’ undeclared (first use in this function) 1074 | yychar = YYLEX; | ^~~~~ cs_grammar.y:1074:58: note: each undeclared identifier is reported only once for each function it appears in make: *** [Makefile:334: cs_grammar.o] Error 1
Notice it’s all UPPERCASE, but you can find plenty on the lowercase issue where its not being linked correctly. And yeah turns out YYFLEX should define out toe yyflex
# ifndef YYLEX
# define YYLEX yylex()
Add that in the top of whatever source is complaining and you’re golden.
With the collapse of my vpsland archive, Neko has become lost once more again. Thankfully I had some fragment backups so I have been able to bring Neko back from the grave. again.
First I dumped everything I had over on sourceforge. With a bit more digging I found the old RISC versions as well. I even found the Itanium version, although I lost the ARM version. Im not sure I have an 8gb pi4 anymore, but I’d like to get one when/if prices stop being insane. Anyways I also uploaded the source to github, since it’s more hip and acceptable for zoomers. I do have to say the git mirror command was everything I’d hoped it’d be.
You’ll need to have the ethernet driver handy, or better loaded. Since I had disabled the NIC on install it’s not loaded. And since I’m still using a cellphone for internet I extracted the file somewhere else and copied in some patches. I’ve managed to reproduce this twice now, so I guess it’s good to go. Apparently, this just works in later versions, but this is very touchy.
Change the directory to /pcnet , and let it run It will give errors but thats okay. All being well it won’t crash AIX, otherwise you’ll want to restore your hardisk. You did make a backup beforehand right?!
I don’t think it matters but I run this afterwards:
odmchange -o CuAt -q "name=ent0 and attribute=busio" /cdrom/lance_ch.asc odmget -q "name=ent0 and attribute=busio" CuAt shutdown -h now
As tempting as it is to kill the emulator, wait for it to complete. Otherwise you may have to do the whole thing agian.
For me the value attribute was never preserved, so we get to do it again on reboot/restart:
odmget -q "name=ent0 and attribute=busio" CuAt mount /cdrom odmchange -o CuAt -q "name=ent0 and attribute=busio" /cdrom/lance_ch.asc rmdev -l ent0 mkdev -l ent0 ifconfig en0 10.0.2.15 ping -c 1 10.0.2.2
If everything went well this time you should get a ping reply! Great! Now to configure the system for real.
smitty -> communication -> tcpip -> minimum -> en0
As always I configure my system for slirp. We’re almost there! Now to pad the DNS records for slirp:
I had gone over the install a while ago, but I wanted to re-install on a newer machine. And going from GCC 7 to 11, well a number of things changed. And I found with experience that letting Qemu select as much as it wants leads to numerous dependencies that end up being problematic.
Another fun think is that there is submodules from other servers, and it seems their certs have expired.. Which also means it’s inevitable at some point this will become impossible to build. Be sure to set this environment variable in order to build:
As always Qemu will try to sneak a few things in there that we don’t need like audio support. As an example here is what I trimmed from config-host.mak:
and with that all in place we can compile a simple hello world!
# cat mt.c
printf("hi from C\n");
# xlc -v mt.c -o mt
hi from C
xlC is also capable of building a running GNU Chess. And I updated the git so that book building works. Not that I expect anyone to care.
Chess book Compiling book, please wait… 186 games added, 3384 positions added, 3383 total positions in book
It has the same desire to move pieces back and forth for thousands of moves, but it’s doing a heck of a lot more than any modern C compiler.
Since we don’t have any networking, Everything is on the console. I’ve found making CD-ROM images being a much easier way to get data in, and I’m still using uuencode to get data out from the console. I guess I should setup Z-modem at some point but that’s very futuristic. Or just break down and learn how to use C-kermit.
I am not much of a chess player. That said one thing that has annoyed me to no end is GNU Chess 1.2. Over on bitsavers is this fun directory:
And despite being a treasure trove of ancient GNU software, I have never been able to get GNU Chess to do much of anything. At best it’ll give the Chess prompt, and then it’ll either crash (good!) or worst case it just exits silently with no reason given.
I have put only minimal effort into debugging it, and really got nowhere. I don’t know why this is such a tough beast to deal with, or why I even care. As I mentioned above, I’m not much of a chess player.
But for some reason this time around I thought I’d try the earliest release quality Visual C++ to build it. I wasn’t expecting much, however for some reason this ancient version seems to run.
I had to enable a few things such as the RANDOM & HASH to make it look like it wants to play. I ended up having to make some changes after a draw or victory as the ‘self playing mode’would keep going. Not sure what’s going on there, and I added a line at the end of the logic loop to always print the board, so at least you can see what is going on if you have it playing itself.
With that said this is the most ridiculous thing I’ve seen:
Given I don’t have any good rusage emulation going on (I know its in MinGW at some point, and I probably can find it, and get it running on MSVC but I don’t see that as important) an 8 move victory seems pretty… unlikely?
Maybe it’s a good test of other C compilers to see if they produce anything. Or maybe it’s all a red herring? I haven’t tested with much but GCC 1.40 can’t even run it on x86. Watcom 10 can build, but it crashes during a self game.
It’s one of those mysteries, that I’m sure there is some fundamental lesson, but I’m not sure what it is.
Other than it’s a long way down, standing on the shoulders of giants.
While on discord the topic came up of why there is no good/free C compiler for MS-DOS. Oh sure there is OpenWatcom but the 2 heavy hitters of the era, Microsoft C & Borland C are not open in the slightest.
There is DeSmet C, although it’s source is full of unnamed structs meaning that building it with anything sane would require a ‘lot of work ™’ which of course is not what I’m all that about. Instead, I remembered a directory up on TUHS /Applications/Portable_CC with a zip file 8086.zip Although this is a zip file, you’ll want to unzip on something Unix-y as there is a lot of case duplicate files. That said this is a PCC port to the 8086, which includes a libc, 8087 support, and is all expected to be built on a VAX-11/780 running 4.1BSD. Now this ended up being a stumbling block because I tried a *LOT* of things thinking that they were upwards compatible with 4.1, and the answer is USE 4.1!
So to effectively get going you’ll need a SIMH VAX780 and just follow my old steps on Installing 4.1BSD. As far as the zip file, I used Linux but had to create a tar file specifying the Unix v7 format with:
With that said it’s a very strange setup as it relies on the 4.1BSD Vax environment so much that there is assembly injected into the linker.
So this will not cleanly run. Just as it depends on many system a.out specifics on building for MS-DOS. It’s not so much a MS-DOS tool chain, rather it outputs to vax a.out and uses a slightly modified vax linker. The MS-DOS magic happens in the conversion of the final a.out into a com file.
That is right it’s a VAX specific cross compiler that only build’s COM files.
I’ve managed to build some trivial stuff, and they work. Sadly my attempt at building that InfoTaskforce of ’87 failed.
I haven’t dug that much further into the linker although I have to wonder if a GNU cross linker to make a.out could make something that the conversion program would be happy with. The assembler of course doesn’t work, perhaps it’s something with packing structs?
As always, the simple stuff looks trivial but it was a fair bit involved.
Since there is no real ‘cc’ it’s a script but the vauge steps are: