• Please review our updated Terms and Rules here

TU58 XXDP on PDP-11/05 with 8KW?

Dare

Experienced Member
Joined
Dec 28, 2015
Messages
97
Now that I've gotten past my SCL issue, I've been trying to boot XXDP on my 11/05 and running into problems. I'm using tu58em and a minimal XXDP image I built using xxdpdir.

My 11/05 is pretty bare-bones at this point; just 8KW core and a DL11-W configured as unit 1 (176500/300, LTC disabled).

First thing I noticed is that the boot block on my tape image appears to be intended for a system more memory. Early on in the code it sets the stack pointer beyond the end of core (060000), which results in a double fault when the code attempts to push the stack.

If I patch the boot block to set the stack to 040000 I get further. The system loads blocks 9 though 27h from tu58em, but then halts with an illegal instruction trap. If I'm interpreting the contents of the stack correctly, the PC at the time of the trap was 1050, which disassembles as follows:

Code:
1032:   004767   ; JSR PC,1244
1034:   000206
1036:   004767   ; JSR PC,1300
1040:   000236
1042:   005302   ; DEC R2
1044:   016703   ; MOV 60,R3    <--- Instruction that produced trap?
1046:   177010
1050:   004767   ; JSR PC,1504  <--- PC on stack
1052:   000430
1054:   012403   ; MOV (R4)+,R3
1056:   004767   ; JSR PC,1504
1060:   000422

Interestingly, I've been able to reproduce these same failures in simh by configuring a TU58 (TDC0) device and depositing and running the bootstrap. This suggests its not a problem with my machine but rather an issue with the software I'm using.

Is there a special version of XXDP for smaller machines like the 11/05? Are there instructions somewhere on how to run XXDP on these machines?

Thanks in advance,
Jay
 
Interestingly, I've been able to reproduce these same failures in simh by configuring a TU58 (TDC0) device and depositing and running the bootstrap. This suggests its not a problem with my machine but rather an issue with the software I'm using.

Is there a special version of XXDP for smaller machines like the 11/05? Are there instructions somewhere on how to run XXDP on these machines?

Thanks in advance,
Jay

Urgh. This might become very complicated.
Yes, if you have the "latest" version of XXDP, there are actually two versions, and one is meant for small machines. However, the system by defaults boot up in the large monitor, and then you can switch to the small one. Which obviously is not what you'd really want.
I have never investigated how to set up the system to start in the small monitor. Also, I don't know if even the small monitor is small enough to work on your system.

But, as a starting point, "bootsm" is the command to switch to the small monitor if you're at the big one in XXDP.
 
I don't think you have enough memory to run the v2 XXDP monitor (the one which supports the TU58).
XXDPv2 will boot the SM and run in 24KB (12KW) but 16KB (8KW) is just not enough.

XXDPv1 monitor should be able to boot in 16KB (8KW) but there is no TU58 device support in that monitor.

So you need to find more memory or get an XXDPv1 compatible peripheral.
 
Yes, if you have the "latest" version of XXDP, there are actually two versions, and one is meant for small machines. However, the system by defaults boot up in the large monitor, and then you can switch to the small one. Which obviously is not what you'd really want.
Thanks for the info. I did some searching and discovered the BOOT.CCC file. If this file exists and contains "SM", the later version of XXDP will boot into the small monitor.

I tried this in simh but still got a stack exception. Digging in I discovered another place later in the boot process where the stack pointer was being set to a position beyond the end of core (045000).

Playing around in simh, I was able to set a break point right before the mov SP instruction, patch the address to a location within core and continue execution. This succeeded it getting me to an XXDP prompt. (simh script and output attached below).

All this tells me that there are hard-coded assumptions about minimum system memory in the version of XXDP I'm using (V2.6). I wonder if I need to track down an earlier version?

Jay

Code:
ECHO PDP-11/05 TU58 Boot Test

; Set CPU parameters - PDP-11/05 with 8kW (16kB) of core memory
SET CPU 11/05
SET CPU 16K

; Throttle CPU usage
SET THROTTLE 5%

; Disable devices that we don't need
SET HK DISABLE
SET DZ DISABLE
SET RL DISABLE
SET RX DISABLE
SET RP DISABLE
SET RQ DISABLE
SET TM DISABLE
SET TQ DISABLE
SET RK DISABLE

; Mount XXDP TU58 tape image
SET TDC ENABLED
SET TDC CONTROLLERS=1
ATTACH TDC0 xxdp-image-files/1105.DSK
SET TDC0 LOCKED

; Deposit the DEC TU58 bootstrap
DEPOSIT 1000 012701
DEPOSIT 1002 176500
DEPOSIT 1004 012702
DEPOSIT 1006 176504
DEPOSIT 1010 010100
DEPOSIT 1012 005212
DEPOSIT 1014 105712
DEPOSIT 1016 100376
DEPOSIT 1020 006300
DEPOSIT 1022 001005
DEPOSIT 1024 005012
DEPOSIT 1026 012700
DEPOSIT 1030 000004
DEPOSIT 1032 005761
DEPOSIT 1034 000002
DEPOSIT 1036 042700
DEPOSIT 1040 000020
DEPOSIT 1042 010062
DEPOSIT 1044 000002
DEPOSIT 1046 001362
DEPOSIT 1050 005003
DEPOSIT 1052 105711
DEPOSIT 1054 100376
DEPOSIT 1056 116123
DEPOSIT 1060 000002
DEPOSIT 1062 022703
DEPOSIT 1064 001000
DEPOSIT 1066 101371
DEPOSIT 1070 005007

; Break before jumping to boot block
BREAK 1070

ECHO Running TU58 bootstrap
GO 1000

ECHO Patching stack address in boot block
EXAMINE 106
DEPOSIT 106 40000
EXAMINE 106

NOBREAK 1070

; Break before instruction that sets SP
BREAK 1046

ECHO Continuing
CONTINUE

ECHO Patching stack address in XXDP startup code
EXAMINE 1050
DEPOSIT 1050 40000
EXAMINE 1050

NOBREAK 1046

ECHO Continuing
CONTINUE

Code:
PDP-11 simulator V4.0-0 Current        git commit id: c8f73155
PDP-11/05 TU58 Boot Test
Disabling XQ
/home/jay/Remote/olsen-fileserver/jay/Projects/Retrocomputing/pdp11/software/tu58-boot-test.ini-24> ATTACH TDC0 xxdp-image-files/1105.DSK
TDC: buffering file in memory
Running TU58 bootstrap

Breakpoint, PC: 001070 (CLR PC)
Patching stack address in boot block
106:    060000
106:    040000
Continuing

Breakpoint, PC: 001046 (MOV #45000,SP)
Patching stack address in XXDP startup code
1050:   045000
1050:   040000
Continuing



BOOTING UP XXDP-SM SMALL MONITOR


XXDP-SM SMALL MONITOR - XXDP V2.6
REVISION: E0
BOOTED FROM DD0
 8KW OF MEMORY
UNIBUS SYSTEM

RESTART ADDRESS: 032010
TYPE "H" FOR HELP

.
 
You may be able to get the XXDPv2 monitor to kludge boot into an 8KW system, but I don't think you will be able to run any of the XXDP tools (like PIP, etc). So the monitor will be basically useless.
 
AK6DN said:
I don't think you have enough memory to run the v2 XXDP monitor (the one which supports the TU58).
XXDPv2 will boot the SM and run in 24KB (12KW) but 16KB (8KW) is just not enough.

XXDPv1 monitor should be able to boot in 16KB (8KW) but there is no TU58 device support in that monitor.

So you need to find more memory or get an XXDPv1 compatible peripheral.

You may be able to get the XXDPv2 monitor to kludge boot into an 8KW system, but I don't think you will be able to run any of the XXDP tools (like PIP, etc). So the monitor will be basically useless.
Fascinating. Thanks for the info, Don. Mine is a small-box 11/05, so without an external box (or maybe RAM that runs in a SPC slot?) I'm maxed out at 8KW.

I wonder if I should be investigating booting from simulated paper tape. I've seen very little instruction on how to do this, though.

Jay
 
I remember that I ran XXDP+ on an 11/04 with 8kW memory.

Don’t have much details. Here is how I how worked with my 11/04.

http://www.datormuseum.se/computers/digital-equipment-corporation/pdp-11-04


Just tried with SimH from RL02. This is working:

sim> set cpu 11/05 8kb
sim> set rl enabled
sim> set rl0 rl02
sim> attach rl0 xxdp+.rl02
sim> boot rl0


CHMDLC1 XXDP+ DL MONITOR
BOOTED VIA UNIT 0
8K UNIBUS SYSTEM

ENTER DATE (DD-MMM-YY): 01-JAN-88

RESTART ADDR: 032010
THIS IS XXDP+. TYPE "H" OR "H/L" FOR HELP.


Also XXDP2.2 boots.

sim> attach rl0 xxdp22.rl02
sim> boot rl0

CHMDLD0 XXDP+ DL MONITOR
BOOTED VIA UNIT 0
8K UNIBUS SYSTEM



xxdp2.5. crashes with "stack push abort."
 
I wonder if I should be investigating booting from simulated paper tape. I've seen very little instruction on how to do this, though.
That brings up memories: I've two 11/05 with minimal core too. To work with these I plugged a M9312 Boot ROM (from 11/34) into them, booted into the "console emulator", and downloaded papertapes with PDP11GUI then. The internal UART was disabled by jumper, a DL11-W (also from 11/34) was used then to run at 9600.

Now they're pimped with UniBone to 56K mem and RK/RL controllers.

Joerg
 
Wow! Thanks for all the help, guys! Mattis's XXDP+ image was especially helpful. Using that, I have succeeded in booting XXDP on my system, which I'm super excited about!

As Mattis's image was built for an 11/04, none of the tests on the image were applicable to the 11/05. And it seems that few if any of the tests in the 1988 Diagnostic Handbook are prepared to work on an 11/05 with so little memory. (BTW, thanks, Jörg, for the OCR of the handbook!)

So I used the excellent xxdpdir tool to add the MAINDEC-11 D0* tests to Mattis's image and now my system is running the first branch test (D0AA0). (Looks like this is going to take quite awhile--up to 246 minutes!)

If anyone knows of any other tests that would be appropriate for my system, please let me know.

Thanks again to everyone. It's great having access to a community of people with so much knowledge!

Jay
 
That brings up memories: I've two 11/05 with minimal core too. To work with these I plugged a M9312 Boot ROM (from 11/34) into them, booted into the "console emulator", and downloaded papertapes with PDP11GUI then. The internal UART was disabled by jumper, a DL11-W (also from 11/34) was used then to run at 9600.

Yep. I've been pining for a way to boot the machine without using the switches. Not that I don't enjoy it--but I worry that their MTBF is bound to be up if I keep on hammering on them.

Trick is, of course, that M9312's are not super easy to come by. There is one on ebay I've been eyeing...

Now they're pimped with UniBone to 56K mem and RK/RL controllers.
This is absolutely my plan! However I want verify the system was running correctly before introducing more hardware.

One question: Can you use the UniBone to autoboot an 11/05 without an M9312 or equivalent?

Jay
 
What timing! I'm getting my 'small' 11/05 up and running and have just run into the same problem with the 8KW limitation, would it be at all possible to get a copy of the XXDP you made for your 11/05?

I was fortunate enough to have a M792 diode bootstrap board, though the de-soldering and soldering of new diodes to make up the TU58 bootstrap did almost drove me mad! My memory constraint plan is to use a MS11E I have spare and re-wirewrap the unused slot 6 A-B into a MUD which would give me 24KW in total. Though failing that, I will likely head down the UniBone path also.

I look forward to seeing your future posts, it appears you've managed the fill the gaps where my knowledge of the software had reached its limit, though reading through what you have posted makes complete sense now.
 
Happily, everything seems to be working great.

Took me a bit, but I found a relatively early version of the PDP-11 instruction exerciser test (MAINDEC-11-DZQKC-E-PB), which I added my XXDP image. I used the alternate entry point (0204) to specify relocation limits within the available memory on my system (020000 to 040000) and it proceeded to run and pass.

Rather serendipitously, I managed to blow the breaker on my power strip, which brought the machine down in the middle of the test. When I restored power, it said "POWER FAILED" and proceeded to restart the test. Gotta love core!

Next up I may try running the core memory Worst Case Noise Test and check the various preventative maintenance items described in the manual.

Jay

Some pics for those like me who can't get enough...

attachment.php


attachment.php
 
One question: Can you use the UniBone to autoboot an 11/05 without an M9312 or equivalent?

Yes. Development of a M9312 seemed not necessary, as UniBone can preload RAM memory with some bootloader code and define vector 24.

The boot loaders code are MACRO11 source code taken from
http://www.ak6dn.com/PDP-11/M9312/
and modified to run stand-alone at lower memory addresses.
The UniBone "demo" application can read the resulting MACRO11 listings files directly and DEPOSIT them into memory.

Bootloaders for RK05, RL02 and MSCP already exist as dk.lst, dl.lst and du.lst files, see attachement.

If an ACLO/DCLO cycle is injected after that by UniBone with the "pwr" command, the CPU should boot.
The CPU would fetch the start address from 24 and start execution.

So M9312 autoboot can be implemented with a UniBone "demo" script.

As enhancement it would be really nice to have the whole M9312 console emulator ("@" prompt) as standalone MACRO11 program, with all the device bootloaders integrated.
Source codes are printed in the "M9312 Field Maintenance Print Set" Oct 1978, MP00617.

Anybody feels challenged?

Joerg
 

Attachments

  • 5_boot.zip
    14.2 KB · Views: 1
Yes. Development of a M9312 seemed not necessary, as UniBone can preload RAM memory with some bootloader code and define vector 24.

The boot loaders code are MACRO11 source code taken from
http://www.ak6dn.com/PDP-11/M9312/
and modified to run stand-alone at lower memory addresses.
The UniBone "demo" application can read the resulting MACRO11 listings files directly and DEPOSIT them into memory.

Bootloaders for RK05, RL02 and MSCP already exist as dk.lst, dl.lst and du.lst files, see attachement.

If an ACLO/DCLO cycle is injected after that by UniBone with the "pwr" command, the CPU should boot.
The CPU would fetch the start address from 24 and start execution.

So M9312 autoboot can be implemented with a UniBone "demo" script.

As enhancement it would be really nice to have the whole M9312 console emulator ("@" prompt) as standalone MACRO11 program, with all the device bootloaders integrated.
Source codes are printed in the "M9312 Field Maintenance Print Set" Oct 1978, MP00617.

Anybody feels challenged?

Joerg

There might be a case for still implementing the M9312. There are software that traps system crashes and does a reboot by jumping to the known address of the M9312. Your solution of instead writing data to RAM will not work in that environment.

Not to mention that it would also possibly be a total misery for anyone with core, or battery backed memory, who turn the machine off and on again, at which stage the OS might already have something setup at vector 24 to resume operation. In which case actual booting still happens from the M9312, but resume operations happens with whatever is in memory. And machines like the 11/70 with an M9312 and battery backed memory might actually do either a resume operation, or boot, depending on if the memory is still valid or not.
 
There might be a case for still implementing the M9312. There are software that traps system crashes and does a reboot by jumping to the known address of the M9312.
Indeed. One of my first unsatisfactory interactions with simh was going 7773000G and getting garbage instead of either a ROM monitor or bootstrap. This is something that would be nice to fix for the PiDP-11.

Back on hardware, since almost all of the -A9 ROMs for the M9312 are known (I think one of the oddball sets like DMR11 network boot is still lost), it should be possible to pre-load every single ROM into the UniBone and then make them selectively available at the 4 possible device ROM locations.

Note that the DEC ROMs are marvels of efficiency to fit into 32 bytes (IIRC). Even when in regular EPROM (like on the 11/23 quad module) they relied on some undocumented tricks. For example, the TK25 tape subsystem will rewind and read the first block into location 0 of memory if you write "MS" to the CSR (I think that's the one, it has been a long time). I actually did a rewrite of the bootstrap for an OEM because their "compatible" 3rd-party controller didn't implement that particular quirk.
 
The M9312 boot proms DEC used were 512x4 devices, but they only ever used half of the device (the other half is not even addressable). So a 256x4 PROM works just as well (of which I stlll happen to have close to 1000, in case anybody needs a BOOT PROM). 256x4 translates into 64W or 128B worth of boot code.

Most all PROM images are available on my site (https://www.ak6dn.com/PDP-11/M9312/) for download. Source files, listing files, and hex PROM files.

A few are still MIA (RS for RS11/64, CR for CR11, XE for DECNET ethernet DELUA/UNA, plus the XU/XW/XL DECNET DDCMP files).
MU for TMSCP TK50/TU81 is also missing on my site, but I have heard Jack Rubin has a physical device, but he is hoarding it until the end of time, I believe :).

Don
AK6DN
 
The M9312 boot proms DEC used were 512x4 devices, but they only ever used half of the device (the other half is not even addressable). So a 256x4 PROM works just as well (of which I stlll happen to have close to 1000, in case anybody needs a BOOT PROM). 256x4 translates into 64W or 128B worth of boot code.
My memory isn't what it used to be, and doesn't even have parity, let alone ECC.

Most all PROM images are available on my site (https://www.ak6dn.com/PDP-11/M9312/) for download. Source files, listing files, and hex PROM files.

A few are still MIA (RS for RS11/64, CR for CR11, XE for DECNET ethernet DELUA/UNA, plus the XU/XW/XL DECNET DDCMP files).
MU for TMSCP TK50/TU81 is also missing on my site, but I have heard Jack Rubin has a physical device, but he is hoarding it until the end of time, I believe :).
I might have MU (E39) squirreled away somewhere. I have my old office PC from when I was at SPC stashed in my basement (but it hasn't been powered on in 25 years or so, so the hard drive may be dead) which should have a copy of my "ROM burner PC" files, which was the system I used for [E]PROM programming. It should have lots of things if I can find the time to get it resurrected. There are also a couple other places they might be archived, such as PCSA containers backed up to DAT media (I took a complete set of backups when I left SPC).

I expect the XE ones are pretty rare, since they were probably used only in OEM applications. That probably explains the missing DDCMP ones as well. I didn't even know you could boot from a CR11 - never mind the encoding, how did bootable media get created? What DEC operating systems supported the CR11 as a boot device, anyway - once you got "block 0" read in, what was supposed to happen next? And for standalone operation in an OEM environment, I'd take mylar "paper" tape over cards any day.
 
Back
Top