• Please review our updated Terms and Rules here

MSCP Controller with SD-Card, need some help

Yes, RSX11M.SYS was loaded in all cases, however when SAV choked this means it could not activate the boot disk and proceed with files outside the RSX11M.SYS image. The next post clearly shows, it could mount the boot disk load the AT processor and read and execute the startup command file. The difference between these steps is that I found out that I did only initialise CREDITS when the Emulator was started the first time, but in fact it shoud do so whenever the host initialises the MSCP controller (writing to the IP register). Now I initialise the CREDITS value on every initialize and this helped as you can see. Then I did indeed find a small bug in the put_packet routine as it wrote two words too much when placing the repsonse to the host memory. However as buffers in the response ring are always at least 60. bytes long and no response is larger than 44. bytes, writing 48. bytes in this case did not overwrite anything wrong.

Thanks for the advice, I will search the source files for a hint, what is causing the "SYSTEM FAULT DETECTED AT PC=056130 FACILITY=000300 ERROR CODE=000100"
 
I would be interested to know what that message means - it's the exact message I get trying to boot your image (as per my screen shot earlier!) - but on my emulator with no I&D space...
 
Great work!

Just curious about the hardware. Is the hardware a AtMega1284 and Atmel ATF1504/ATF1508 as the RLV12 board you made earlier? I guess that since you don't code in C you have done MSCP handling in AVR assembly, right?

Maybe it would be possible to create a Unibus design from what you have done later on. Should be fairly similar except for the bus interface.
 
Yes, except it is an AVR128DB48 instead of the ATMega1284P. The software makes use of some features not available on the ATMega1284P, e.g. nested interrupts most notably. And yes it is all in AVR assembler.

I'm not sure about Unibus, there are some subtle differences between an RQDX3 and an UDA50. I have not implemented purge requests, and as far as I know mapped busses in systems with Unibus Mapping need this feature. Same goes for a VAX with Q-Bus. However purge requests is only based on software protocol and makes not use of special hardware, so it should be possible to add this feature. So it should be possible.
 
cbscpe said:
SYSTEM FAULT DETECTED AT PC=056130 FACILITY=000300 ERROR CODE=000100
Click to expand...
I did a little bit of research of the system source code, and the message gets generated by a bugcheck (system crash).
The facility code 300 (as BF.EXE) is the Executive itself, and the code 100 (BE.ODD) supposedly means "odd address".
Both defined in the BCKDF$ macro stored in LB:[1,1]EXEMC.MLB, and the crashdump code is in [11,10]CRASH.MAC.

The only place I found in the Executive that use it is [11,10]SSTSR.MAC, namely:
Code: 
;+
; **-$TRP04-TRAPS AT 4 (ODD ADDRESS, NONEX MEM, ETC.)
;
; THIS ROUTINE IS TRAPPED TO WHEN A TRAP AT 4 OCCURS. IF A STACK VIOLATION
; HAS CAUSED THE TRAP (I.E. A STACKPOINTER OF LESS THAN 400), THEN THE
; THE SYSTEM IS CRASHED. ELSE THE CURRENT MACHINE STATE IS SAVED AND
; CONTROL IS TRANSFERED TO THE SST EXIT ROUTINE.
;
; INPUTS:
;
;    NONE.
;
; OUTPUTS:
;
;    02(SP)=SST CODE (SCOAD).
;    00(SP)=NUMBER OF BYTES TO BE TRANSFERED TO THE USER STACK (4).
;-

$TRP04::CMP    SP,#400        ;;;STACK VIOLATION?
    BLO    30$        ;;;IF LO YES
    DIRSV$            ;;;SAVE REGISTERS AND SET PRIORITY
    CLR    -(SP)        ;SET FOR ODD ADDRESS TRAP
    MOV    #BE.ODD,R3    ;ODD ADDRESS OR OTHER TRAP 4 BUGCHECK CODE
20$:    MOV    #2*2,-(SP)    ;SET NUMBER OF BYTES
    BR    SSTXT        ;TAKE COMMON SST EXIT ROUTINE
30$:    BGCK$A    BF.EXE,BE.STK,DIRECT ;;;SETTUP THE ERROR CODES FOR A
                ;;;STACK OVERFLOW

(Another use of BE.ODD is in the XDT proper, located in [15,10]XDT.MAC.)

IDK if this is helpful...
 
Thanks for that! - Hmm interesting - I turned on logging of TRAP 4 NXM errors - and it seems to scan the UNIBUS MAP range - then stop after 2 more:

...Lots more before this...
BusErrIO: dati: 170356 17770356
BusErrIO: dati: 170360 17770360
BusErrIO: dati: 170362 17770362
BusErrIO: dati: 170364 17770364
BusErrIO: dati: 170366 17770366
BusErrIO: dati: 170370 17770370
BusErrIO: dati: 170372 17770372
CPU HALT: Addr: 013042 Inst: 000000 PSW: 000344 R0 001770 R1 001522 R2 000000 R3 000000 R4 000000 R5 177564 R6U 121104 R6K 002022 SR0 000001 SR2 013042

But I don't know what it was built for at all!
 
Radix said:
then stop after 2 more:
Click to expand...
UNIBUS maps ends after two more, at 170376. 170400 may not be occupied by any device (peripherals handbook mentions AR-11 and LS-11 as possible candidates), so it can be an NXM.
 
Hmm, as you say it can also be an NXM, I think I encountered a strange issue in my MSCP emulator, not sure if hardware or software related. Fact is, after some time, my MSCP emulator creates bus timeouts... need to fix that before continuing.
 
As far what I know, RSX-11M+ does not access non-existant devices, except when probing and then it does not rise an exception. During initialisation it probes all "installed" (aka configured) components, i.e. sizes the memory and probes all IO page addresses (at least the first address of a device) related to a any driver installed and marks them accordingly. The exception we see however does not come from this stage. Rather it comes from accessing a probed and addresses expected valid. So the question is really what the image has been built for. It might be a device for which RSX-11M+ uses an address to probe which really exists, but other registers don't, as it is is not the device RSX-11M+ expects. Considering this I was thinking about my setup. It turns out, it was not my MSCP emulator, but the fact, that I mimicked my CPU card to report as KDJ11E (PDP-11/93). I changed that and the CPU card reports now as KDJ11A (PDP-11/73) and here it comes my first successfull boot of RSX-11M+ using my MSCP emulator.

Code: 
@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.
>;
>;
>* Please enter time and date (HH:MM DD-MMM-YYYY) [S]: 8:22 12-may-2026
>TIME 8:22 12-may-2026
>ACS SY:/BLKS=1024.
>CON ONLINE ALL
>ELI /LOG/LIM
>CLI /INIT=DCL/CTRLC/DPR="<15><12>/$ /"
>INS LB:[1,1]RMSRESAB.TSK/RON=YES/PAR=GEN
>INS LB:[1,1]RMSLBL.TSK/RON=YES/PAR=GEN
>INS LB:[1,1]RMSLBM.TSK/RON=YES/PAR=GEN
>INS $QMGCLI
>INS $QMGCLI/TASK=...PRI
>INS $QMGCLI/TASK=...SUB
>QUE /START:QMG
>INS $QMGPRT/TASK=PRT.../SLV=NO
>QUE LP0:/CR/NM
>START/ACCOUNTING
>CON ESTAT LP0:
>QUE BAP0:/BATCH
>QUE BAP0:/AS:BATCH
>@ <EOF>
>tim
08:24:40 12-MAY-26
>tim /full
08:24:43 12-MAY-26 (Tuesday)
>tim /rom
Maius XII, Anno Domini MMXXVI   VIII:XXIV
The moon is waning crescent. Today is Tuesday.
>

And thus starts now the cumbersome clean-up phase. Thanks for all the info, hints and suggestions. Here you can see my "development" system :rolleyes:.

PDP-11:Hack w: MSCP emulator.jpeg

Peter
 
Oh fantastic!

So... on a real controller, the IP register returns a value after initialisation, typically 122100 (Octal) - is this documented anywhere?

Also note that on writes not a multiple of 512 bytes, you need to pad with 0s to end of 512 byte block - similar to the RLV12

Another possible gotcha is that the IE bit is only for initialisation interrupts - the presence of a non-0 vector enables interrupts during normal operation, as well as the "F" bit...
1778574891597.png

Good luck with it!
Robin
 
Fantastic! Are you planning to do a Qbus form-factor board with proper Qbus receivers / drivers as well or just stay with existing QBUS-64 / Euro connector design?
 
There are a lot of strange oddities regarding interrupts. And in contrast to the note regarding the interrupt after step 4, the RQDX3 controller does however generate an interrupt after step 4, and the RQDX3 source code shows this as well. In my case RT-11 never boots if I did not generate an interrupt after step 4, however that was the case before I did all the changes and corrections for RSX-11M+ to boot correctly. I will test this again later with no interrupts after step 4, but at the moment, interrupts after step 4 do no harm neither to RT-11 nor RSX-11M+. What I see regarding IE is that when an RT-11 or RSX-11M+ reinitialise the controller, which they have to do because the ring configuration of the boot stage differs from the ring configuration of normal OS operation, they always set the IE, I assume they expect interrupts for the initialisation steps in order to not have to poll the device during initialisation, as the OS is already executing and it would be annoying in case you did not boot from DU: and when activating DU: you would wait polling the MSCP controller to get online. So a non-zero vector with IE not set is a very useful scenario.

And yes I definitely plan to create a Q-BUS board, in this case it will be a normal sized dual-width Q-BUS. In the meantime I switched from EAGLE (which has been discontinued) with a limited PCB size to KiCAD which has no such restrictions. It will look somewhat like this mock-up. I say mock-up because this is not based on final CPLD design I have in mind. Due to the fact that the CPLDs are only available in TQFP packages, PLCC packages have been discontinued, and the AVR MCU is available only in TQFP or QFNP , I decided to make an all SMD board. I will use the same QBUS receivers/transmitter design as on my Q-BUS RLV12 Emulator and Memory, using 74F38 as transmitters and CD74HC4049 as receivers. I.e. only components still available. The project will be done in KiCAD with BOM etc. so anybody should be able to order a fully assembled board with jclpcb.

MSCPEmulator.png
 
That board is going to be VERY popular!!!

Interestingly, I don't and have never generated the interrupt at stage 4 and RT-11 and TSX boot fine...

I started messing with a little test program at the weekend, for RT-11SJ written in C, to explore what the real controllers do - it's VERY much a work in progress, but already tracks the initialisation flow:

The controller must NOT be the boot device (!) - and currently only supports address 160340, where I happen to have a second MSCP controller (Viking) on my real system..

It's attached below just in case it is of any interest...

(The ring buffer is initialised with data so you can see if the controller clears the buffer area)

Robin

1778580260829.png
 

Attachments

Last edited:
Radix said:
But I don't know what it was built for at all!
Click to expand...
The disk image contains all the SYSGEN files in [200,200], including saved answers, SYSGENSA{1,2,3}.CMD, and the device table SYSTB.MAC, but haven't noticed any smoking guns there, esp. for the 170400-address vicinity. The "show io" command in SimH should reveal all the I/O and vectors used (including those of the CPU, IIRC). And SimH was said to able to run this without crashing.
 
The disk image boots successfully without crash in simh and now after some corrections to my MSCP server code it also boots successfully on my PDP-11/Hack with the above mentioned MSCP Emulator. I was also looking into the SYSGEN files and there is definitively no trap or hidden feature configured. The only restriction I see is that the system has been configured with kernel and user D-Space support, so it will only boot on processors with I and D space support. Else, as already mentioned, RSX-11M+ normally probes all configured devices during boot and marks devices not found as offline. And even the ONLINE command probes any device you want to bring online and will not crash if it does not exist.

The crashes I had with my MSCP emulator lately were cause by the fact, that from time to time the DMA failed. The reason was, that I forgot to add dual-rank synchronizers to some of the bus signals. I added those into the CPLD design and now the system boots and is stable, currently the system ran over night and has an uptime of 12 hours. Once the cleanup is finished I will perform a SYSGEN just to see whether it is stable enough to do real work.
 
Nope, does not work, it stucks after loading the bootblock, there is a dead-lock between MSCP and boot code. I'm using the disk image available here BDS 2.11which works fine in simh. Don't really know what is going wrong, the log of my MSCP server does not show anything special. I was hoping to find a hint reading the source code of the boot block, but I got lost in the source code repository, could someone point me to the correct MSCP bootloader source code (boot block) ? There must be something different to what RSX-11M+ does.

Thanks

Peter
 
Just in case it is useful - here's the responses to INIT, ONLINE and SET CONTROLLER CHARACTERISTICS for both Viking SCSI and Emulex UC07 controllers...

Robin
 

Attachments

FYI, At boot, The BSD image goes ONLINE, READ, SCC, ONLINE - and then a load of 1KB reads...

This is before the boot prompt, so I get that far before it notices the lack of I&D space, lol

mscp_p[0] Init4: cmd_s: 1 res_s: 1 r_base: 00005204
mscp_command: port 0 MsgLen: 36 O:1 F:0 ConID:0 MsgTyp:0 Cred:1 Opcode:9 Unit:0 Modify:0x0000 ByteCount:0 CmdRef:0 0x0 Flags:0
mscp_command: port 0 MsgLen: 32 O:1 F:0 ConID:0 MsgTyp:0 Cred:1 Opcode:33 Unit:0 Modify:0x0000 ByteCount:512 CmdRef:0 0x0 Flags:0
mscp_p[0] Init4: cmd_s: 1 res_s: 1 r_base: 00156106
mscp_command: port 0 MsgLen: 60 O:1 F:1 ConID:0 MsgTyp:0 Cred:0 Opcode:4 Unit:0 Modify:0x0000 ByteCount:0 CmdRef:0 0x0 Flags:0
mscp_command: port 0 MsgLen: 60 O:1 F:1 ConID:0 MsgTyp:0 Cred:0 Opcode:9 Unit:0 Modify:0x0000 ByteCount:0 CmdRef:0 0x0 Flags:0
mscp_command: port 0 MsgLen: 60 O:1 F:1 ConID:0 MsgTyp:0 Cred:0 Opcode:33 Unit:0 Modify:0x0000 ByteCount:1024 CmdRef:0 0x0 Flags:0
mscp_command: port 0 MsgLen: 60 O:1 F:1 ConID:0 MsgTyp:0 Cred:0 Opcode:33 Unit:0 Modify:0x0000 ByteCount:1024 CmdRef:0 0x0 Flags:0
mscp_command: port 0 MsgLen: 60 O:1 F:1 ConID:0 MsgTyp:0 Cred:0 Opcode:33 Unit:0 Modify:0x0000 ByteCount:1024 CmdRef:0 0x0 Flags:0
...lots more of these...
 
You must log in or register to reply here.
Back
Top