MattisLind
Veteran Member
I am investigating why IOX-11 sometimes get stuck. This is part of my SPACEWAR project where I have gotten the old SPACEWAR code that Bill Seiler wrote in 1974 running on a PDP-11 with a AR11 card.
The background is that I though it would be useful to have a single binary that could be loaded from XXDP or CAPS-11 which would make it much easier to load. The first part of this was to make IOX-11 to assemble using PAL11-S instead of PAL11-A. With that fixed I could link the IOX object with all the SPACEWAR objects and thus creating a single absolute binary which can be loaded and run.
The binary would load and run in SIMH correctly if loaded using the LOAD command in SIMH. However if I add the binary to a TU58 diskimage with a DDDP system executing a RUN SPCWAR it just hangs and nothing is printed on the console. It seems that it sits in a loop inside the IOX library waiting for something. If I at this point do a RESET command in SIMH and then restart SPACEWAR at address 1000 it starts up correctly and prints the SPACEWAR greeting prperly. So the loading is correct but there is this RESET needed.
I think I have seen something similar on real hardware that it sometimes get stuck in the IOX-library. What could be the cause of this? Anyone care to have a look?
Here is the TU58 DDDP image.
Here is the source for IOX-11.
Here is the part where it gets stuck:
(Unfortuantely CODE formatting doesn't look that great)
When it seems to work it is not taking the branch "BNE I.BRX" while when it get stuck it takes the branch and does a RTS R4 without the CMP (R4)+,(R4)+. In the former case it ends up returning on one instruction further. At that point it will loop back and do everything over again.
I cannot really figure out what the I.CONFLC table is supposed to do and why it seems to be causing this. The Paper Tape Software manual covers it in section 7.9 but it doesn't make it clear to me unfortunately.
The code that is calling IOX-11 is the PARM.PAL module and it looks very much like the example in the Paper Tape Software manual chapter 7 which deals with IOX-11 programming.
I haven't added a RESET instruction as the first instruction, perhaps that could solve it? On the other hand there are already a RESET instruction executed as part of the IOX-11 RESET operation so I would think that has already been done.
Thoughts on this appreciated!
The background is that I though it would be useful to have a single binary that could be loaded from XXDP or CAPS-11 which would make it much easier to load. The first part of this was to make IOX-11 to assemble using PAL11-S instead of PAL11-A. With that fixed I could link the IOX object with all the SPACEWAR objects and thus creating a single absolute binary which can be loaded and run.
The binary would load and run in SIMH correctly if loaded using the LOAD command in SIMH. However if I add the binary to a TU58 diskimage with a DDDP system executing a RUN SPCWAR it just hangs and nothing is printed on the console. It seems that it sits in a loop inside the IOX library waiting for something. If I at this point do a RESET command in SIMH and then restart SPACEWAR at address 1000 it starts up correctly and prints the SPACEWAR greeting prperly. So the loading is correct but there is this RESET needed.
I think I have seen something similar on real hardware that it sometimes get stuck in the IOX-library. What could be the cause of this? Anyone care to have a look?
Here is the TU58 DDDP image.
Here is the source for IOX-11.
Here is the part where it gets stuck:
Code:
I.IOWAIT: MOV #I.TOCNT,I.TMP ;CLEAR COUNTER BEFORE TESTING
; FOR LSR
CLR (I.TMP)+ ; CLEAR COUNTER
CLR @I.TMP ; CLEAR T.O. FLG
BITB I.CONSIT(I.RDEV),I.CONBYT ; DEV BUSY?
BNE I.WLSR ; YES....DO T.O. CK ON LSR
BITB I.CONFLC(I.RDEV),I.CONBYT ; NO....IS THERE A CONFLICT?
BNE I.BRX
; I.NBRX:
CMP (R4)+,(R4)+ ; NOT BUSY RETURN....DIDDLE RTN ADR
I.BRX: RTS R4 ; RETURN(Unfortuantely CODE formatting doesn't look that great)
When it seems to work it is not taking the branch "BNE I.BRX" while when it get stuck it takes the branch and does a RTS R4 without the CMP (R4)+,(R4)+. In the former case it ends up returning on one instruction further. At that point it will loop back and do everything over again.
I cannot really figure out what the I.CONFLC table is supposed to do and why it seems to be causing this. The Paper Tape Software manual covers it in section 7.9 but it doesn't make it clear to me unfortunately.
The code that is calling IOX-11 is the PARM.PAL module and it looks very much like the example in the Paper Tape Software manual chapter 7 which deals with IOX-11 programming.
I haven't added a RESET instruction as the first instruction, perhaps that could solve it? On the other hand there are already a RESET instruction executed as part of the IOX-11 RESET operation so I would think that has already been done.
Thoughts on this appreciated!