Solving the halting problem with my PDP-11/44!

In the previous episode, we got the 11/44 up and running, and it looked like it was trying to go, but we kept running into a problem: we couldn’t halt the CPU. Which seems like a really weird thing to want to try to do, but PDP gonna PDP. At any rate, we need to get the CPU to halt so we can start trying to run stuff on it, as counterintuitive as that sounds. So, today, that’s what we’re going to tackle!

If you want to support the channel please hop over to Patreon:

Also, we now have some epic shirts for sale!

Come join us on Discord!

Intro Music adapted from:
Artist: The Runaway Five
Title: The Shinra Shuffle

Thanks for watching!

Chapters
0:00 Solving the unsolvable
1:16 Solving the real halting problem
3:51 Taking care of the basics first
6:26 A little board swap and some progress!
8:40 Getting some help from the past
11:25 An introduction to PDP11GUI
14:22 Loading something from a simulated paper tape
18:02 The two avenues of media
21:28 Slow motion noms!

[haraldtscherne]

As others have already mentioned: your floppy controller is a 'quad' Unibus card, these always go to the FRONT of the BA11 box (rows C-F) -> if you leave the back rows (A & B) free in that slot then you have enough room for the floppy cable. Most likely the floppy controller uses DMA so you need to put it into a Unibus slot which does NOT have the NPG line shorted -> there must NOT be a wire from pin A1 to B1 in row C of that slot.
I would make sure the second from left slot (#13) does NOT have that jumper on the backplane, insert the floppy controller in that very slot, and then try a 'B DX' (for RX01) or 'B DY' (for RX02) command. At least your floppy drives should show some signs of life, clicking, seeking maybe, ....
... I used to repair PDP 11s back in the 80s .... your videos bring back glorious memories, thank you so much!

[rwdplz]

10:45 I've done that before - Googled a troubleshooting question, found a post from myself 15 years ago with the answer.

[Photo_CB]

My PDP/LSI knowledge is old (like 40 years and counting) and limited. While I used PDP-44s as a student I certainly did not maintain or operate them. I did get deep into various LSI-11s, -03, -23 and -73. What I do remember is that while the I/O system was flexible and extendable it was absolutely NOT plug and play. Everything was done by dip switches or, more often, wire-wrap links. You had to have the manual for the board you were working with and a good idea of how the machine as a whole was configured. IO devices were memory mapped into the top 8K of the base 64K of memory, hence giving only 56K of actual memory available. All other memory was mapped and the MMUs varied from machine to machine. On LSIs the IO space could be halved, giving more memory for programs and code. Each type of IO device had a default location but IO controller could be reconfigured to use alternate, generally closely related IO addresses by wire-wrap links. This allowed, forexample several disk controllers on the same type to be used on the same machine. The console terminal was always the first DL11(?) serial device and was always at the same location. On the LSI-11s, which had Q-Bus cards, the DLV-11J was a four channel serial card, four independant serial ports just settable as a block to somewhere in the region of IO space allocated to DL-11 devices. Later machines, such as your LSI based PDP 11-83, had one or more serial ports built in, but they emulated the good old DL-11. I wpuld be surprised if the 11/44 did not have such an arrangement.

Third party IO controllers were very common, indeed in some situations they were the norm. On the 11/73s I ran only the processor card was DEC, everything else was third party. Such controllers generally emulated DEC device types, so your Fujitsu Eagle controller may well emulate a DEC RPO7. It may be that Mitch was trying to boot of the eagle. Often built in bootstraps would only boot off the first instance of a device type, i.e. the one at the default IO address for that device type. However I beleive that it was possible to boot off non-defaults in many machines if you knew the IO address of the particular device - i.e. you knew how the boards were configured. You just jumped to the relevant boot address in the monitor. The problem is that with a random collection of IO boards the IO addresses may have been configured all over the place and they may not play together or be easily bootable from.

Remember too that you are not talking to the processor itself when in console mode in the 11/44. You are talking to a console sub-processor, something like a 8085 I suspect, that has access to system memory and can, or in your case can't as the case may be, control the actual processor. For example, how can a halted processor send any messages? It can't of course, but a console sub-processor can. The "Console V3.40" message comes from and give the ROM issue of the sub-processor, not the main system which thanks to the console sub-processor effectively needs no ROM. Also it can almost certainly only boot from the DEC device type and then maybe only from the default instances of each type as it can't know the full configuration of the system.

In many system configuaration the console port was dedicated for system control/monitoring/system messages and aso on. They were often a printing terminal, even a Teletype on earlier systems, so that you had a hard copy of system messages. The LSI processors had ODT (Online Debugging Technique if I remember rightly) implemented in the processor to do essentally the same thing.

Even then the PDPs/LSIs were not plug and play. The operating systems - I am most familar with RSX-11 and RT-11 - generally had to be SYSGENed, i.e. configured for the particular system. This was a complex process that required the original distribution media, often tape (1/2" or latterly TU58, as was reportedly often used with the 11/44) or even floppies. It was a bit like the sysgen you do on the Centurion, but offline and much more involved. You genned the system telling the SYSGEN program the specific details, IO addresses and so on, of each and every board/controller. SYSGEN then would condtionally assemble a bespoke version of the operating system from source code. The result was a bootable system on, hopefully, the media of choice. It tended to take half a day even if you knew what you were doing and you had to take care of your system source distribution media.

I suspect the 8" floppies are not from a 11/44, they are probably some years earlier. By the time the 11/44 came out I beleive the normal floppies were the 5 1/4" RX02.


I suggest you get some manuals for your IO/controller boards and find out exactly how each are configured. Bare in mid that if the eagle is bootable, and I suspect it will have been, it wont be genned for the boards you have :-( Functionality may well be limited. Enjoy!

[a_funyun]

I can only picture the SECUR-T robots from WALL-E: "HALT!"

[leosmith]

Years ago I turned up to work to find a halted PDP/11.
Eventually its master guru arrived, and detected that someone had pushed some console key to halt it. He pushed another one and it resumed operation. We told the cleaning lady NOT to run her duster over the console keyboard, after that.

[RJTC]

(Can't post links).
The floppy interface goes to the left, looking from the front of the chassis.

This manual on bitsavers shows the full slot layout & which are the small peripheral controller slots;


See page 2:15 or pdf page 29.

Also get this one for more configuration info:
DSD-440 Flexible Disk Memory System User's Guide.pdf

They also give all the links, bootloader setup, registers etc.

[eldorado]

You finding a post from 1998 on a search engine is something we unfortunately won't be seeing with the wealth of knowledge present in closed platforms like discord when they eventually perish.

[adagioleopard]

I recieved a broken oscilloscope from my first job, and when I searched for solutions to the problem, I came past a forum post on the EEVBlog and in that post the OP posted a video. And I i. Imidiately recognized the arma in the video as my old colleague who gave me the scope. XD

[mcolville]

Man I love that you found Mitch's debug thread from like LITERALLY 25 years ago! That's amazing.

[JamesPotts]

I think there's a "Pdp vs NPdp" joke to be made here, but I'll leave it to someone else.

[Richardincancale]

I used to run an 11/44 back in the 80s. To boot I typed B DB (just B is enough). The DB was the boot ROM for the RM02 drive 0 - an 80Mb unformatted, 67 Mb formatted disk - I suspect a CDC drive. The disk name to boot is not the same as the boot loader name.

[wtfusernamecrap]

Excellent episode! I feel compelled again to emphasize that, while I have an affinity for computers and the kind of archaeology you perform, I'm mainly here because of your storytelling and presentation style, your personality, if you will. Keep it up, and thanks again for taking us on this journey with you. And the bunnies, of course. Never lose the bunnies! ❤️

[ChristopherHailey]

Love that this starts with a computer science joke. Worked with PDP-11s a lot in the 70s and 80s from 03 up to 70 models. Such classic machines.

[RichardBetel]

Let’s do some math!
Async serial at 8N1 sends 10 bits per character, so 9600bps is at most 960 characters per second. The command to load a byte looked something like “D + XX<cr>” and the response is “<lf><lf>>>> “ which is 13 characters total. Between execution and the laptop processing the response, let’s assume the equivalent of one character’s transmission time is used. 960/14 is 68.6 bytes loaded per second. That means a 16k program takes 4 minutes to load.
Is the console actually running at 9600bps? Also, the numbers are hard to read on my phone but it looks like it’s 6 digits per 16 bytes with leading zeros removed so probably less efficiently encoded than two hex digits. Programs like pdpgui often put delays into how fast they transmit rather than relying on flow control: it’s simpler to code so the transmission rate might be slower.
In conclusion, I don’t think you have a flow control issue. I think you have an inefficient data transfer system.

[FreihEitner]

My eyes just quickly caught a change in the HELLORLD output at 17:47 -- what's the line LHD! which flies by? I don't know PDP-11 software, maybe that's normal, but the program then continues with printing HELLORLD several more times.

[VorlonFrog]

Congrats on getting BASIC loaded and successfully running! Be thankful that's a UNIBUS system, and not an LSI-based Q-Bus backplane. Continuity, voltage, pretty much everything runs straight through (if my ancient memory isn't wrong). Unlike the Q-Bus where it's zig-zagged through the slots and backplanes. Getting the floppies talking is a good start, because it's pretty much the same thing getting the big Eagle drive going. The disk controllers are DMA devices (again, old memory in this aged noggin) and console commands like 'b dx' for 'boot dx01' tell it to hit bus address 17xxxx for the dx01 floppy drive controller board. The board has a boot ROM on it, wired at that controller address, and the ROM tells the CPU how to boot the drive.

[emilschw]

Nice to see that new tech can be used to resolve issues with old tech in ways we would never have imagined back in the day...

[Renville]

I just KNEW the minute that Basic was loaded into the PDP-11, what the next thing was going to be! 👍

[martandrmc]

Now that's what I call a fast click! Hooray more PDP!

[RobSchofield]

Are you sure CP isn't Console Program? Also, I seem to remember the peripheral controller board for the device you want to boot from needs a suitable ROM on the board, and you EXEC from the base address for the card ROM to start it. At the moment it sounds as if it doesn't have ANY controllers with boot code ROMs on them, so it just halts.