Resurrecting the MIT Weather Radar PDP-8/IX

[mainframetom]

I know that Intersil had these I/O chips. But I haven’t found any in my device.
So I hope(d) that at least the TTY output would have a standard address.

Some emulators/disassemblers have most or some even all possible instructions. I mainly use the commandline emu pdp8emu by mengstr, based on the one by Douglas W. Jones.
6007 is KK8-E: Clear all flags. 6415 DP8-EAEB: Read Status 1. 6414 Read Status 2, etc. These are my first appearing IOTs.

I have replaced 3 or 4 instructions with NOP. The emulator runs ending in a loop. Starting at 400, I have a longer RAM test. But also if skipping it, I have a loop, maybe waiting for a key input.
I have to do more tests from different starting addresses but I think I would have to change some values and I don’t know how/if this is possible. Maybe only when patching the code.

On my device I only have one visible output, the LCD display.
Also the data export to printer/TTY or audio cassette. And the export to RAM/EPROM cartridge. And I think export to the PLC.

Most IOTs are probably input for the keys, which are grouped in around 8 or 9 groups using hardwired TTL.

I don’t know how to simulate the input of my keys.
I think easiest would be to import via TTY some data (in the internal Festo code (I know)).

I have the full manual of my device but missing schematics. So some internals are unknown especially of the (optional PLC). There’s also a life-bit and another unknown EPROM.
I found many details including a special character encoding, many tables, an undocumented Festo BASIC instruction etc.

I also wonder why the emulator always missing the last digit. SR 200 PC=20. The instruction line is correct.

[mainframetom]

@oldben

VT78

I think SIMH only emulates a PDP8/E according the manual.
It might be possible to emulate a VT78 and or DECmate/II/III (latter ones have an Intersil 6120)

Running WPS-8 (Word Processing System) on the DEC(mate) PDP-8i and SIMH -...

I haven’t found any Intersil 6100 emulator (including the Intersil I/O chips).
The SBC6120 using emulator WINEIGHT. But I’ve already tested it, without success.
I tried several IOT definitions.

[mainframetom]

The main problem is the assignment of the IOTs and not 6100 CPU.
As a CMOS PDP-8 doesn’t have a control panel I would need other I/O and keys anyway.

• I could write a complete emulator emulating all keys, LCD display. TTY etc

• Adding I/O devices on SIMH should be possible either by changing the source or with this manual

simh_vmio.pdf

• Or I could patch my code replacing all IOTs to the standard TTY IOT

I found the code for a printout, but I first have to import data or change the code and test just to print a single character.

For testing my code, a command-line emulator is much better as it’s easier to display and change memory.
It’s all very time consuming.

[bill75]

I’m well on the way to getting near-realtime weather radar data to use in the resurrected PDP-8 RADAR system. I’ll be able to query any of NOAA’s 160 Nexrad 10 cm radars around the US, fetching level 2 azimuth/elevation scans. Getting here has been an interesting experience.

Reading documentation on the complex, compressed format is not how I want to spend my time, so I figured I’d just get some AI chatbot to write the code. We all constantly hear about how they are better programmers than humans and will replace us. I’m not buying the hype, but if it would save me from digesting documentation it would be great.

I tried Grok first, and after many hours it proved useless. It led me through a massive trial-and-error process, where it tried in vain to guess the format by tweaking the code, looking at hex output, and iterating. Finally it just crashed.

So I switched to Claude, supposedly the best at coding. It was only marginally better than Grok, and followed the same ultimately useless trial and error process over many hours of iteration. These chatbots know enormous amounts of stuff, but that doesn’t make them intelligent.

Then I realized my mistake. I asked for code in C#, because I know that language so well and the simulator is written in it. Then it occurred to me (but not to the AI)–the code doesn’t have to be in C#, it can be Python where mature libraries must exist because that’s what Python is famous for. And indeed nexrad readers do exist in Python. I don’t have much Python experience, so I asked Claude to write the code. It generated usable code in seconds, and ultimately took about an hour of adjustment to get it where I wanted–fetch data from any radar I select, parse and write an XML file for C# to read. The whole program is a little over 200 lines.

So yes, AI can write code but it couldn’t take a step back and realize that what it was trying to do was going nowhere. Even if it could guess the format on the test case we worked on, there was no guarantee (or likelihood) that it would work on a different nexrad dataset. It took a human to say STOP.

[NoLand]

@bill75

I have just recorded a 24-minute video demonstration of RADAR version 3.0

Thank you for doing this, well done!

[bill75]

I’ve got the PDP-8 using near-realtime weather radar data from anywhere in NOAA’s Nexrad network. Pick any of the 160 sites, specify a fetch time interval, and it runs everything I showed in the video demo.

Here is Nexrad map from a storm last week, rendered in my PPI display (same display you saw in the video):

This display was made from unmodified dbz values directly from the radar. When I processed the map with the PDP-8 RADAR system, I got this:

When I saw the difference I assumed I had some sort of bug, and spent hours looking for it. But it’s no bug. The Nexrad radars are way more sensitive than what we had in back in the day. WR66, as the name implies, is 1966 technology. Nexrad can detect incredibly low signals at great distances, where the inverse square law attenuation is well beyond the reach of the old radar sets.

Those purple shades are below 10 dbZ at 250 km from the radar. Looking carefully at the PDP-8 code I estimated that at that distance, signals below around 30 dbZ are undetectable by the old sets. Remember that 30 dbZ is 100 times more received power than 10 dbZ.

So why am I sure that this is not a bug, and is explained by sensitivity? I looked at the one dbZ map preserved from the old days, the one presented at the 17th Conference on Radar Meteorology in 1976, and sure enough the lowest recorded value at 200 km was 28 dbZ.

[bill75]

Note that in the two images, the differences inside the 50 km range ring are due to different settings of the range covered by the display, which I wasn’t paying close attention to when I made it.

[bill75]

Here is a B-Scan made by the PDP-8 of a slice of a storm right now on the North Carolina coast. Azimuths are 0 - 20, so NNE of the radar. Range 20 - 60 nautical miles. Notice the small black areas in the 40 dbZ range, with peaks at 48 dbZ, which is pretty serious rain.

[bill75]

@bill75

Looking carefully at the PDP-8 code I estimated that at that distance, signals below around 30 dbZ are undetectable by the old sets.

What I meant by that is there are a couple of hardwired calibration constants in the code, for each radar, that effectively set the lower limit of detectability as a function of range. I’m considering modifying the constants for one of the two radars to try to mimic the Nexrad sets. I think I’ll try WR66, like Nexrad a 10 cm (S-band) set, and with much more transmitted power than WR73.

[bill75]

I could indeed change the two WR66 hardwired calibration constants to mimic a radar with much more sensitivity, and the result is that the PDP-8 can closely replicate the weak Nexrad values at long ranges without changing the previously detected values. But I couldn’t just change the defined constants and reassemble–some two’s complement hacking was required.

The problem was that the changes meant that previous values that were assumed to be positive could now be negative. Those values are divided by a positive constant, but the PDP-8/I doesn’t have hardware signed divide so the existing EAE code wouldn’t work. I know how to do half-signed divide in software, but that felt like too much alteration.

Furthermore, the 128-word memory page on which the code sits has zero free words. So any alteration would need to use no more words, or serious reorganization would be needed.

But since I can pick somewhat arbitrary constants, I made the positive divisor be a power of two, meaning I could use the arithmetic shift right instruction to do the half-signed divide. With proper consideration of dynamic range for 12-bit fixed point values, it works just fine.

Many people, even some textbooks and computer manufacturer’s manuals, believe that ASR is equivalent to signed divide by a positive power of two. It is not. Conventionally defined divide and ASR treat quotient and remainder differently for negative dividends, and this has caused trouble over the years, as described in 1976 by Guy Steele (co-author of the original C reference manual).

One advantage of ASR over divide for twos-complement fixed point arithmetic is that signed roundoff is much easier. Old fixed-point hackers know this, but I don’t think it’s taught anymore, if it ever was.

[bill75]

According to online specs from NOAA, Nexrad uses WSR-88D radars (Weather Surveillance 1988 Doppler). In what they call short pulse mode (1.5 us pulses, similar to the MIT setup). minimum sensitivity is -9.5 dbZ at 50 km. So at 250 km that would be -9.5 + 20 log(250/50) = 4.5 dbZ, consistent with what I’m seeing and a good 25 db (~300x) more sensitive than MIT’s WR66.

Since this is a retro-computing site, not retro-radar, I’ll note that, according to what I found online, Nexrad “product generation” (formatting and sending data) is done on a Pentium 2, a thirty-year-old x86.

[NoLand]

Regarding hacking constants, may I remind of Steve Russell’s Spacewar-trick of having a table of constants just at the beginning of the code, at well known addresses? (This should allow to change/adjust/hack them via the console more easily.)

[bill75]

There has been a bug in the RADAR code since the beginning–if you do any command to print or display a recorded map (LIST, BSCAN, PPI) and give it an invalid map number, it just crashed. I just fixed it. I had to reverse engineer a lot of code to see how things worked, where to get the requested map number, and where to get the number of maps available.

What I discovered is that I had implemented an addressing scheme somewhat like the PDP-11. 8 registers, R0 - R7, are defined, all relative to the index register and private per process (thread). Fetch and store subroutines take one or two arguments following the JMS. The first specifies a base register, a bit specifying whether or not the second argument is a displacement off the base register, and an auto-increment bit. The second argument is given only if the displacement bit is set. R0 reads as 0 for addressing, so you can have just displacement.

All of the display code is reentrant. The calling conventions are IOF, JMS, because JMS stores the return address in memory. The subroutine copies the return address to a stack-like portion of process-private memory and turns interrupts back on. There is no actual stack pointer, the programmer has to know just where to save the return address. Very brittle, total kludge, but not a lot of options on that machine.

[oldben]

It still seems safer compared to a modern system, that could crash a stack or heap at any time.
I like the PDP 8 since it has it very easy to learning curve, like a few hours and i/o is well tested. Modern stuff seems take years to learn with very poor doc’s. That is one reason I have never followed micro-controllers after the 6809.

[bill75]

I was curious about whether any records exist from the Air Force Hurricane Hunters project on the PDP-8 MIT got from them. So I asked Gemini: “I’m interested in the history of the Air Force Hurricane Hunters use of PDP-8s in airborne weather radar systems. Late 1960s, early 1970s.”

Gemini wrote a 688-word piece in response. It is in its entirety a summary and paraphrase of the series of posts I wrote here over the last few months. Gemini embedded a link to retrocomputingforum seven times.

Gemini writes in the authoritative tone common among LLMs. It uses retrocomputingforum as its primary source and either accepts its reliability or doesn’t question it. Other chatbots will do likewise and retrocomputingforum becomes the official history. I’m not sure I like how easy it is to create history.

More details, my primary sources, and the complete chat here.

[EdS]

Yes, there’s a real danger here - if people paste chats to a forum, the output looks rather like forum content and is likely to resurface as if it has some authenticity.

It’s great that this forum contains good stuff, for which we must all thank each other, and very handy that the forum comes up in search results. Moderately good that the chatbots also find and use the forum content… the best thing though is when people (real actual people) find the forum and come here to add their own experiences and findings.

This is all a bit parenthetical…

[bill75]

Those who’ve been following this story from the beginning may recall that “WR73 was somewhat portable and would later travel to Africa and Malaysia”. I’ve told at some length my experiences with WR73 in Africa. My time in Malaysia was much briefer but rather more dramatic.

Here is WR73 in Bintulu, Malaysia, on the northern tip of Borneo.

All of the electronics, and the transmitter, is in that gray enclosure, with the dish on top. In the foreground is Speed on the right. Next to him is Dr. Frank Marks, who later served for 20 years as director of NOAA’s Hurricane Research Division, flying weather radars into hurricanes over 500 times.

MIT was part of the 1978 Winter Monsoon Experiment (W-Monex), another international undertaking like GATE, but not quite as big. Bintulu was (is?) a small fishing village reachable only by air–no roads, no port suitable for ships. Our equipment, including a diesel generator, was dropped at the airport (one runway, where dogs had to be shooed off before planes could take off and land).

Bintulu, however, was not a primitive place. At one point we needed an electronic component that was not among our extensive kit of spares. The local electronics shop had just what we needed.

In 1978 I was in grad school, only at Weather Radar in the summer. During Thanksgiving with my family in NJ I got a frantic call from Polly. The MIT engineer responsible for setting up the digital electronics had an emergency and had to go home. Speed handled the radar and analog side, but was not familiar enough with the digital interfaces. The project was in trouble. Could I go to Bintulu and help? Could I leave in 48 hours?

The MIT travel office handled all the details. I flew Boston to Kuala Lumpur via NYC and Hong Kong, then a small hop to Bintulu. Got everything working. Introduced the locals to Frisbee.

MIT had scheduled my return via Singapore. I landed at the airport with hotel reservations for the night, flying out the next morning. At passport inspection I was informed that it was illegal for a man to have long hair, and if I wanted entry I’d need a haircut first. I politely declined.

My passport was confiscated and I spent a terrifying night in the airport transit lounge. Uniformed, armed officers patrolled the lounge and eyed me suspiciously. In the morning my passport was nowhere to be found, and Pan Am treated me with suspicion, like a criminal. Finally at the last minute the passport was located and I got on the plane. I’ve never been back.

Here is my passport photo at the time. Would you have let me in?

[bill75]

For anyone out there running (gasp) Windows, I’ve just added release 4.0 to GitHub. This is the standalone exe that you can run without any installation of dependencies. It includes all of the facilities for fetching near-realtime weather radar data from any of NOAA’s 160 Nexrad radars across the US. Use it with the latest RADARX.LS in the docs directory.

It includes the changes to WR66 calibration constants appropriate for Nexrad’s high sensitivity compared to the original radars. With Nexrad and WR66, the PDP-8 can now detect, record, and display negative dbZ values (generally found at close range). WR73 still has the original sensitivity, and WR66/WR73 comparisons on the same data are interesting.

Updates to the RADAR User’s Guide in docs explains how to use it. All of the source code, including the Python program that reads and parses Nexrad datasets, is in the repository.

The release is huge (~200 MB) due to the standalone Python executable (~140 MB), which also requires no dependencies to be installed. Don’t know why it’s so big. You don’t have to run it, it’s run as needed by the C# executable PDP-8.exe.

[oldben]

Can you run it with a pre-installed Python? I got Python 3.12.5 that goes with some hardware I have.

[bill75]

There are a lot of dependencies that have to be installed. In the GitHub repository, look at library install instructions.txt, and the source code in NexradParser.py. I had a lot of help from Claude getting the installation correct. The C# executable requires a standalone Python exe that it can invoke.