MSCP Controller with SD-Card, need some help

[cbscpe]

Hi,

finally I got into the mood to start developing an MSCP card for the Q-BUS64 of my PDP-11/Hack. The hardware is pretty similar to my RLV12 emulators, which als exists as a real Q-BUS version as well. Which means it is an MSCP Controller with diskimages stored on a SD-Card either as partitions of a MBR formatted SD-Card or as disk image files in a FAT-32 formatted partition on the SD-Card (both are possible at the same time)

So far the hardware seems solid and the firmware is at a stage, where I can boot RT-11 from the MSCP controller, create copies of the disks, create new boot disks, etc.
However when I try to boot RSX-11M+ the boot process ends with the following message

        SAV -- Booted device cannot be brought online
131626
@

Obviously something goes wrong. I started to compare the boot process of my MSCP controller with the boot process, using the same disk image, in SIMH. I started with debugging output on the rq0: controller, but in fact I would need much more detailed information on what is going on to be able to compare, preferably a SIMH debugging output which dumps the MSCP messages and responses or at least the responses. But my C-Coding skills are near non-existant and I have no clue how I would do that in the pdp11_rq.c. So my question is if someone would be willing to help me to add such a debugging output, or knows if there exists a possibility in simh to get more output then just the debugging output .

I'm using the disk image which was previously here ftp://ftp.trailing-edge.com/pub/rsxdists/rsx11mplus_4_6_bl87.dsk

Perhaps it is important to note, that when I boot RSX-11M+ from my RLV12 emulator I can access the diskimage

>dev
VF0:     Offline Loaded Type=unknown
VF1:     Offline Loaded Type=unknown
CO0:     TT0: Offline Loaded
TT0:     [200,200]   [200,200] - Logged in  Loaded
TT1:     Offline Loaded
TT2:     Offline Loaded
TT3:     Offline Loaded
TT4:     Offline Loaded
VT0:     Offline Loaded
RD0:     Loaded
DL0:     Offline Loaded Type=unknown
         Seek_Optimization=Nearest:0.

DL1:     Offline Loaded Type=unknown
         Seek_Optimization=Nearest:0.

DL2:     Public Mounted Loaded Label=HACK11 Type=RL02 
         Seek_Optimization=Nearest:10.

DL3:     Offline Loaded Type=unknown
         Seek_Optimization=Nearest:0.

DU0:     Mounted Loaded Label=RSX11MPBL87 Type=  00 
NL0:     Offline Loaded
TI0:
CL0:     TT0:
SP0:     DL2:
LB0:     DL2:
SY0:     DL2:
>dir du:


Directory DU0:[200,200]
30-MAR-1982 00:05

SYSGEN.CLB;1        1270.   C  18-DEC-1998 02:46
BLDLAINIT.CMD;1     12.        18-DEC-1998 02:46
SGNBLDBLD.CMD;1     57.        18-DEC-1998 02:46
SGNKLAB.CMD;1       71.        18-DEC-1998 02:46
SGNPREFIX.CMD;1     12.        18-DEC-1998 02:46
SYSGEN.CMD;1        3.         18-DEC-1998 02:46
RSXMC0.MAC;1        16.        18-DEC-1998 02:46
WRKEXECOP.TXT;1     7.         18-DEC-1998 02:46
WRKMASSCO.TXT;1     2.         18-DEC-1998 02:46
WRKMASSDR.TXT;1     4.         18-DEC-1998 02:46
WRKUNIBCO.TXT;1     3.         18-DEC-1998 02:46
WRKUNIBDR.TXT;1     4.         18-DEC-1998 02:46
SYSGENSA1.CMD;1     10.        03-NOV-1999 13:47
SGNSYM1.CMD;1       2.         03-NOV-1999 13:49
SYSGENSA2.CMD;1     11.        03-NOV-1999 13:49
SGNSYM2.CMD;1       1.         03-NOV-1999 13:58
SYSGENSA3.CMD;1     1.         03-NOV-1999 14:03
SYSGENSA1.CMD;2     9.         03-NOV-1999 14:04
RSXMC1.MAC;1        19.        03-NOV-1999 14:04
SGNSYM1.CMD;2       2.         03-NOV-1999 14:04
SGNPARM.CMD;1       1.         03-NOV-1999 14:04
SYSGENSA2.CMD;2     11.        03-NOV-1999 14:04
RSXMC2.MAC;1        2.         03-NOV-1999 14:04
SYSTB.MAC;1         28.        03-NOV-1999 14:04
VMRTTY.CMD;1        1.         03-NOV-1999 14:09
SGNSYM2.CMD;2       1.         03-NOV-1999 14:10
RSXMC3.MAC;1        21.        03-NOV-1999 14:10
RSXBLD.CMD;1        1.         03-NOV-1999 17:39
RSXASM.CMD;1        15.        03-NOV-1999 14:11
DRIVERS.ASM;1       1.         03-NOV-1999 14:11
CODRVASM.CMD;1      1.         03-NOV-1999 14:11
TTDRVASM.CMD;1      5.         03-NOV-1999 14:11
VTDRVASM.CMD;1      1.         03-NOV-1999 14:11
RDDRVASM.CMD;1      1.         03-NOV-1999 14:11
DLDRVASM.CMD;1      1.         03-NOV-1999 14:11
DUDRVASM.CMD;1      1.         03-NOV-1999 14:11
MUDRVASM.CMD;1      1.         03-NOV-1999 14:11
NLDRVASM.CMD;1      1.         03-NOV-1999 14:11
SYSGENSA1.CMD;3     10.        03-NOV-1999 16:45
RSXMC1.MAC;2        19.        03-NOV-1999 16:45
SGNSYM1.CMD;3       2.         03-NOV-1999 16:45
SGNPARM.CMD;2       1.         03-NOV-1999 16:45
SYSGENSA2.CMD;3     11.        03-NOV-1999 16:45
RSXMC2.MAC;2        2.         03-NOV-1999 16:45
SYSTB.MAC;2         28.        03-NOV-1999 16:45
VMRTTY.CMD;2        1.         03-NOV-1999 16:46
SGNSYM2.CMD;3       1.         03-NOV-1999 16:47
RSXMC3.MAC;2        21.        03-NOV-1999 16:47
DSP11M.CMD;1        2.         03-NOV-1999 17:39
RSXASM.CMD;2        15.        03-NOV-1999 16:47
DRIVERS.ASM;2       1.         03-NOV-1999 16:47
CODRVASM.CMD;2      1.         03-NOV-1999 16:47
TTDRVASM.CMD;2      5.         03-NOV-1999 16:47
VTDRVASM.CMD;2      1.         03-NOV-1999 16:47
RDDRVASM.CMD;2      1.         03-NOV-1999 16:47
DLDRVASM.CMD;2      1.         03-NOV-1999 16:47
DUDRVASM.CMD;2      1.         03-NOV-1999 16:47
MUDRVASM.CMD;2      1.         03-NOV-1999 16:47
NLDRVASM.CMD;2      1.         03-NOV-1999 16:47
RSXMC.MAC;3         36.        03-NOV-1999 17:38
DIRCOM.CMD;1        18.        03-NOV-1999 17:39
DR2COM.CMD;1        16.        03-NOV-1999 17:39
DR3COM.CMD;1        10.        03-NOV-1999 17:39
DR4COM.CMD;1        4.         03-NOV-1999 17:39
VECCOM.CMD;1        64.        03-NOV-1999 17:39
RSX11M.CMD;1        8.         03-NOV-1999 17:39
DIR.CMD;1           0.         03-NOV-1999 17:39
DIR11M.CMD;1        2.         03-NOV-1999 17:39
DR211M.CMD;1        1.         03-NOV-1999 17:39
DR311M.CMD;1        1.         03-NOV-1999 17:39
DR411M.CMD;1        1.         03-NOV-1999 17:39
VEC11M.CMD;1        1.         03-NOV-1999 17:39
DCM11M.CMD;1        2.         03-NOV-1999 17:39
LDR11M.CMD;1        1.         03-NOV-1999 17:39
DRIVERS.BLD;1       1.         03-NOV-1999 17:39
CODRVBLD.CMD;1      1.         03-NOV-1999 17:39
TTDRVBLD.CMD;1      19.        03-NOV-1999 17:39
VTDRVBLD.CMD;1      1.         03-NOV-1999 17:39
RDDRVBLD.CMD;1      1.         03-NOV-1999 17:39
DLDRVBLD.CMD;1      1.         03-NOV-1999 17:39
DUDRVBLD.CMD;1      1.         03-NOV-1999 17:39
MUDRVBLD.CMD;1      1.         03-NOV-1999 17:39
NLDRVBLD.CMD;1      1.         03-NOV-1999 17:39
SYSVMR.CMD;1        15.        03-NOV-1999 17:39
SYSGENSA3.CMD;2     1.         03-NOV-1999 18:01
RT57MU.TAP;1        0.         03-NOV-1999 21:53
F77.TAP;2           2267.      03-NOV-1999 19:53
DNMP46EN.TAP;1      41822.     03-NOV-1999 20:43
TRACE.DOC;1         12.        25-JAN-1999 16:00
PMR.DOC;1           4.         25-JAN-1999 16:00
PMRLOG.DOC;1        8.         25-JAN-1999 16:00
VDV.DOC;1           7.         25-JAN-1999 16:00
VDV.HLP;1           7.         25-JAN-1999 16:00
FLOAT.CMD;1         9.         25-JAN-1999 16:00
UNSGEN.CMD;1        108.       25-JAN-1999 16:00
COBTRN.CBL;1        19.        25-JAN-1999 16:00
COBREC.CBL;1        15.        25-JAN-1999 16:00
COBAPP.CBL;1        20.        25-JAN-1999 16:00
COBRRW.CBL;1        23.        25-JAN-1999 16:00
FTNTRN.FTN;1        8.         25-JAN-1999 16:00
FTNREC.FTN;1        7.         25-JAN-1999 16:00
FTNAPP.FTN;1        10.        25-JAN-1999 16:00
FTNRRW.FTN;1        6.         25-JAN-1999 16:00
RUNABO.FTN;1        5.         25-JAN-1999 16:00
BASTRN.B2S;1        9.         25-JAN-1999 16:00
BASREC.B2S;1        8.         25-JAN-1999 16:00
BASAPP.B2S;1        11.        25-JAN-1999 16:00
BASRRW.B2S;1        11.        25-JAN-1999 16:00
SEN10.MAC;1         8.         25-JAN-1999 16:00
REC10.MAC;1         10.        25-JAN-1999 16:00
XTS.MAC;1           21.        25-JAN-1999 16:00
XTR.MAC;1           19.        25-JAN-1999 16:00
DLXRCV.MAC;1        49.        25-JAN-1999 16:00
LATORG.MAC;1        16.        25-JAN-1999 16:00
LATEX.MAC;1         17.        25-JAN-1999 16:00
TRGQNA.MAC;1        15.        25-JAN-1999 16:00
802TST.MAC;1        81.        25-JAN-1999 16:00
NETDUM.TSK;1        82.     C  25-JAN-1999 16:00
QAR.TXT;1           4.         25-JAN-1999 16:00
CEDGEN.CMD;1        27.        25-JAN-1999 16:02

Total of 46689./53920. blocks in 120. files

>

and here the "show memory"

RSX-11M-PLUS V4.6  BL87   (HACK11)  1024K  UP 000:00:07 30-MAR-1982 00:07:55
TASK=  *IDLE*                FREE=   SY0:602.
                                     DU0:172825.                     PARS
POOL=13172.:13194.:5.        SECPOOL=437.:512.:85%
     13172.:13194.:5.                437.:512.:85%                  SECPOL:P
                                                                    SYSPAR:D
IN:    D MRTDP.FFF . HR                                             DRVPAR:D
5      I CCTUM.C11 . RM                                             GEN   :D
34K    R RT::T.S11 . CD
OUT:   1 ..  .ARAA P .T
0      1 ..  .TECC I .0
0K     M ..  ..SPP P .
     !==!>]))>+!>+++<>>
0*******64******128*****192*****256*****320*****384*****448*****
EP-P-D----D-D---------------------------------------------------
----------------------------------------------------------------
512*****576*****640*****704*****768*****832*****896*****960*****

                                                                    ERRSEQ
                                                                    0.

Which makes me think that I'm not far from my first goal to have an MSCP Emulator for my PDP-11/Hack. The next step would be obviously to port the hardware to the real Q-BUS.

Regards

Peter

 

[Radix]

These are the two documents you need to implement:

Hard to help further without a link to where the image you are using IS, rather than WAS - lol

Robin

 

[cbscpe]

Yes indeed the image disappeared and I just used to have a copy, I was searching but couldn't find it again. I do also have the documents you attached and even some more, but they don't give any hints to what could have gone wrong. I have gone through them already several times. The issue is that RSX expects some specific values for an RD54 being returned by the ONLINE and GET UNIT STATUS responses, but I could not figure out which values, as the documents do not go into such detail as disk type specific values, only generic hints. I thought I could figure it out reading the pdp11_rq.c source code of simh, but as mentioned my C programming skills are not sufficient to figure this out from the code alone.

 

[Radix]

The SIMH code is hard going... If it works booted from RL02, it seems unlikely that would be the issue when booting directly - you are returning the same data I presume.

I implemented it returning a drive type of RA81, as that is often used by third party controllers - but have only used with RT-11 and TSX. It's likely a different order of ONLINE and SET_CTRL_CHARACTERISTICS commands

Can you upload / share the MSCP boot image somewhere?

Robin

 

[Radix]

What data are you returning for set controller characteristics words 11 - 13 and online words 14/15 and 18/19?

 

[Bitly]

Yes indeed the image disappeared and I just used to have a copy, I was searching but couldn't find it again.

https://ftp.trailing-edge.com/pub/rsxdists/rsx11mplus_4_6_bl87_dsk.zip

 

[Radix]

Hmm - not sure what hardware config that image requires - it is not happy with my fast 11/23 emulation:

Does it need an I&D space CPU?

Robin

 

[F11ACP]

I suppose that when you say, you try to boot RSX11-M-PLUS from that image file, you use the hardware bootstrap to load up the boot sector (LBN0) of that image and jump to it?
Meaning, you use the so called "saved system" bootup, in terms of RSX. The saved system is loaded by the SAV task (which is used to actually save the system after it was generated and brought up in memory for the first time -- that process usually includes writing the boot sector of the disk, with the /WB switch), and that assumes the saved system matches exactly the hardware you have. And that's where (most likely) SAV encounters the discrepancies and aborts the process.

Another way of bringing up the system is to try to boot it in a soft way from a file. Once booted from RL, locate your system image on the DU0: drive and try booting up the system with the BOO command using that file. The image that the boot sector boots from that drive is this:

RSX11M.SYS;1        (4315,6)       1026./1026.     C  03-NOV-1999 18:01:52 [1,54]   [RWED,RWED,RWE,R]

located in UIC [1,54].
Then once you booted up, you can try re-saving the system back into its file, by using the SAV command (and /WB switch). That may fix the bootloader in the boot sector. It may not work, either. So please save your work and keep backups handy ;-)
HTH

 

[cbscpe]

The Image requires I/D space and at least 1Mbyte of RAM, in simh I always use "set cpu 11/93 4m" which is the equivalent of of the new CPU card of my PDP-11/Hack, for online I return

0x00 0x00
0x02 0x00
0xD0 0x26
0x00 0x00
0x00 0x00
0x89 0x00 <-opcode "online" | op_end
0x00 0x00
0x00 0x00
0x00 0x00
0x00 0x00
0x00 0x00
0x00 0x00
0x00 0x00
0x00 0x00
0x06 0x02
0x33 0x40
0x64 0x25
0x00 0x00
0x00 0x00
0xEC 0xC3
0x04 0x00
0x00 0x00
0x02 0x6F

and for SCC

I return Software Version 2 and Hardware Version 1

As for the image, yes it is a standard disk image with /WB written back. It boots perfectly in SIMH. As for the hardware, RSX-11M+ is not very picky, in this case it just requires the MSCP controller, the console a processor with I/D space and at least 1Mbyte of RAM. It will automatically bring all devices missing offline.

good hint about the using the boot command from the RSX-11M+ bootet from RL I'll try that.

 

[cbscpe]

>mou du:/ovr
>boot du:[1,54]RSX11M.SYS
SAV -- Booted device cannot be brought online
131626
@

Definitely something I respond wrong in my MSCP Server, I managed to produce some trace in simh (some crude hack with my little C knowledge) to trace all MSCP response packets and what I see is rather strange in the online command

DBG(5853)> RQ REQ: cmd=0009(ONL), mod=0000, unit=0, bc=00000000, ma=00000000, lbn=00000000
DBG(5853)> RQ TRACE: rq_mscp - Queue
DBG(5853)> RQ TRACE: rq_onl
DBG(5853)> RQ DISK: sim_disk_isavailable(unit=0)=true
DBG(5853)> RQ TRACE: rq_putr_unit
DBG(5853)> RQ REQ: rsp=0089, sts=0000
DBG(5853)> RQ REQ: txt=002C, 0000, 0001, 0000, 0000, 0000, 0089, 0000
DBG(5853)> RQ REQ: txt=0000, 8080, 0000, 0000, 0000, 0000, 0000, 0204
DBG(5853)> RQ REQ: txt=103C, 22A4, 0000, 0000, 1B30, 0006, 029C, 0000
DBG(5875)> RQ REG: rq_rd(PA=0x003FF46A [SA], access=0)=0x0000
DBG(6053)> RQ TRACE: rq_quesvc
DBG(6096)> RQ REG: rq_rd(PA=0x003FF468 [IP], access=0)=0x0000
DBG(6096)> RQ REQ: poll started, PC=7A6
DBG(6168)> RQ REG: rq_rd(PA=0x003FF46A [SA], access=0)=0x0000
DBG(6243)> same as above (1 time)
DBG(6296)> RQ TRACE: rq_quesvc

The reported unit size is not that of an RD54 (311200. blocks) but that of an RA60 (400176. or hex 0x61B30 as in the trace). I see that it also reports some unit flags UF.RMV and and bit 15 which is not mentioned in the documents posted above. hmm, but I think returning 0x0000 as I do should be valid.

 

[Radix]

Sorry - but your data makes no sense with no further explanation - the endcode should be in the 5th word or 9th byte:

you need 3 words set in scc end message words 11 - 13 as 1 / 2 / 1

 

[cbscpe]

Sorry I inlcuded the internal link header of the queue. Ignore it. The output is lowbyte highbyte of each word of the packet. the endcode is as marked with the arrow 0x89, if you overlook the link header its the 9th byte (when counting starting with 1).

When you say words 11-13 you start counting as well with 1? which means words 11-13 are at offset P.CNTI+0, +2, +4

 

[Radix]

This:

Looks like word 13 (class and model) should be 0x0102

 

[cbscpe]

Thanks, I completely missed that. Will have to fix it.

 

[Radix]

Thanks, I completely missed that. Will have to fix it.

OK - weirdly, I have the class and model in upper and lower words - not the bytes as per the diagram - and mine fails to boot if I change it as per diagram...
I think the device number should be unique amongst all controllers and disks as well - I use the top byte as a prefix, like 1 for controller, 2 for disk - and the controller or disk number in the lower byte

 

[cbscpe]

I tried it both ways now (by accident) and no change. They failed both. But in the meantime I managed to get better idea about the debugging in simh and added my own MSCP response message trace. I will now compare the two trace outputs, i.e. mine and the one from simh. But this will have to wait until sunday.

 

[Terri Kennedy]

The issue is that RSX expects some specific values for an RD54 being returned by the ONLINE and GET UNIT STATUS responses, but I could not figure out which values, as the documents do not go into such detail as disk type specific values, only generic hints.

I think you want Storage Systems Port - CONNECTION ID, PORT TYPE, AND MODEL DEFINITIONS.

 

[cbscpe]

Thanks for the document, that explains and defines many of the bits and bytes I didn't find in the other MSCP documents I have. I added all the flags and version and IDs I previously just zeroized according to the document and the trace from simh and just in case made also sure other things are reported exactly the same as I can see in the simh trace, although in my opinion the disk reported by simh is not RD54 but the next in the table which is RA60, but RSX-11M+ seems not to be bothered by this. Nevertheless, RSX-11M+ is still not happy with my version.

Hmm... perhaps I need to go back to the low-level routines, can there be something wrong with them, which does not disturb RT-11 but does RSX-11M+? E.g. RT-11 uses a ring size of 1 and RSX-11M a ring size of 4, although loading of the RSX11M.SYS image seems to work and for this the ring does many index wrap arounds (approx. 100). I will check them again.

 

[cbscpe]

@165600g


RSX-11M-PLUS V4.6  BL87   1024.KW  System:"RSXMPL"
>RED DU:=SY:
>RED DU:=LB:
>RED DU:=SP:
>MOU DU0:"RSX11MPBL87"
>@DU:[1,2]STARTUP
>;                      PLEASE NOTE
>;
>;      If you have not yet read the system release notes, please do so
>;      now before attempting to perform a SYSGEN or to utilize the new
>;      features of this system.
>;
>;
SYSTEM FAULT DETECTED AT PC=056130  FACILITY=000300  ERROR CODE=000100

CRASH -- CONT WITH SCRATCH MEDIA ON MU000


013044
@

one step forward

Just as info, at ROM location 165600 I have my MSCP bootstrap loader

And after some thought, the crash could be as well caused by the fact that my CPU card reports the module ID of a KDJ11-E but does not implement all registers. Or other devices configured in this RSX-11M1 image that conflict with may hardware. Perhaps I make now may on SYSGEN for a DU: disk image with only the things my hardware really has.

 

[F11ACP]

although loading of the RSX11M.SYS image seems to work

It certainly did work, because it was already SAV that was working trying to restart the (loaded) system from its hibernate state.
The error was posted by the SDISK routine, the source code of which you can see on that very same DU disk in [12,10]SAVE.MAC

    612 ;
    613 ; SIZE THE LOAD DEVICE (SYSTEM DISK), MARK IT AS ONLINE, AND RESTORE
    614 ; ITS VECTOR(S)
    615 ;
    616 ; AT THIS POINT:
    617 ;       R0 = DCB ADDRESS OF LOAD DEVICE
    618 ;       R1 = UCB ADDRESS OF LOAD DEVICE
    619 ;       R4 = KRB ADDRESS OF LOAD DEVICE
    620 ;
    621 SDISK:  CALL    $SWSTK,50$      ;;; SWITCH TO SYSTEM STATE
    622                                 ;;; (PRIORITY GETS SET TO ZERO)
    623         MOV     R1,R3           ;; PUT UCB ADDRESS WHERE RVEC WANTS IT
    624         MOV     #$CTLST,R5      ;;
    625 10$:    MOV     (R5),R5         ;; GET NEXT CTB ADDRESS
    626         BITB    #LS.CIN,L.STS(R5) ;; A COMMON INTERRUPT DEVICE?
    627         BNE     20$               ;; YES
    628         CMP     R0,L.DCB(R5)    ;; DCB OF LOAD DEVICE BELONG TO THIS CTB?
    629         BEQ     40$             ;; YES, FOUND CTB FOR LOAD DEVICE
    630         BR      10$             ;;
    631 20$:    MOV     L.DCB(R5),R1    ;; POINT AT THE DCB TABLE
    632         TST     (R1)+           ;; SKIP THE COMMON ROUTINE ADDRESS
    633 30$:    TST     (R1)            ;; REACHED THE END OF THE DCB TABLE?
    634         BEQ     10$             ;; YES
    635         CMP     R0,(R1)+        ;; LOAD DEVICE DCB MATCH DCB TABLE ENTRY?
    636         BNE     30$             ;; NO, HAVE NOT FOUND CTB FOR LOAD DEVICE
    637 40$:    CALL    RVEC            ;; WAS ABLE TO RESTORE VECTOR(S)
    638                                 ;; AND MARK KRB AND UCB ONLINE?
    639         BCC     45$             ;; YES
    640         MOV     #ERR19,$ERRUP   ;; RECORD PROBLEM   <=== THIS IS WHERE THE MESSAGE ORIGINATED FROM

So, it was the "restore vector" (RVEC) routine, which was failing and causing that...
The RVEC code can also be found in the same file (beginning line 1137 and down), and it co-routines with the GETVC code that resides in SAVVEC.MAC in the same directory (there's a long description of how it does its job beginning line 66).
IDK if this would help some in detecting what is still missing, as per your later post, it looks like SAV is already able to activate all the hardware successfully, and now the system appears to crash later (but it still looks like it's related to some hardware configuration discrepancy).
HTH & good luck!

P.S. It may be helpful to search for the crash message in the system sources to see where it comes from, and what may be the underlying cause, just like I did for SAV above.