Dave McGuire wrote: One would think that this is it, but alas it is not :-( I did a download and disassemble, and it is just a copy of the DU (23-767A9) boot prom image. In fact, download both 23-767A9 and 23-E39A9 and compare them; they are EXACTLY the same image. I believe this happened because there is an image named 23-E39A9.hex/bin floating around various sites that actually is just 23-767A9 (DU, MSCP boot) renamed. FYI here is the suspect image disassembled: dec/m9312[847] hex2mac.pl --boot < 23-e39a9.hex .sbttl M9312 BOOT prom .asect .=173000 .ascii "UD" .word 000176 PUP0ND: sec PUP0D: mov #0,r0 BOOTSZ: mov #172150,r1 BOOTNZ: mov pc,r4 SECD: bcc L1 ; 000030 [.+10] br L2 ; 000034 [.+12] .word 173000 .word 000340 L1: jmp @#165564 L2: mov r0,(r1)+ mov #4000,r5 mov pc,r3 bpl L3 ; 000046 [.+2] L3: blt L4 ; 000060 [.+12] halt .word 000001 .word 000011 .word 001041 L4: tst (r1) bmi BOOTSZ ; 000012 [.-50] bit (r1),r5 beq L4 ; 000060 [.-6] mov (r3)+,(r1) asl r5 bpl L4 ; 000060 [.-14] L7: clr r2 L5: clr (r2)+ cmp r2,#2404 bne L5 ; 000100 [.-6] mov r2,@#1064 movb (r3)+,@#1100 movb (r3),@#1105 mov r0,@#1074 mov #1004,(r2)+ mov r5,(r2)+ mov #1070,(r2)+ mov r5,(r2)+ mov 177776(r1),r2 L6: tst @#2406 bmi L6 ; 000150 [.-4] tstb @#1016 bne BOOTSZ ; 000012 [.-150] tstb (r3)+ beq L7 ; 000076 [.-70] clr -(r1) clr pc halt .word 032074 .end

Dave McGuire wrote: I dunno, I think it was saved on /dev/null from all that I can tell. Even if a binary exists it is easy enough to disassemble and recreate a source. I have a version that I have recreated (from the logic in the SIMH TMSCP driver boot code) but the smallest I can get it down to is 5 words too large for the available ROM space :-( and even then I had to cheat a little bit to get it that small. I'm *really* interested to see what tricks DEC played to implement the real TMSCP boot PROM for the M9312. The MSCP PROM source is available and they did some really groady (cool) hacks (depends on your point of view) to use words as both instructions and data. Don

I'd love to see anyone write a self-modifying ROM ;-) -tony

Dave McGuire wrote: Actually I never said anything about writable, only that some words were being used as both data and instructions. See http://www.ak6dn.com/PDP-11/M9312/23-767A9/23-767A9.lst on lines 59-79 for what I mean. This is the only boot prom that I've seen that plays any tricks like this; all the others are pretty straightforward code. Funny that the boot prom had to do such strange things to interface to the 'most intelligent' controller (MSCP), whereas all the other dumb controllers (RK05, etc) used really simple boot code sequences.

Jerome Fine replies: That 'most intelligent" controller (MSCP) was supposed to be needed to handle large disk drives. The HD: interface (under Ersatz-11) has the capability of handling 2 TB disk drives and is probably the "dumbest" (perhaps cleanest and most easily implemented would be better) controller that I have ever had the pleasure of writing code for. The MSCP interface seems to be much more complex than is actually needed. Since I have been successful in producing a working device driver based on the HD: interface used in Ersatz-11 for a 22 bit Qbus emulation under RT11XM, I have also discovered just how much additional overhead must be present with MSCP code vs the "dumb" HD: interface. As for the size of the code needed to support MSCP, I haven't, as yet, started to use a translation table which DU(X).SYS supports, but the single RT-11 partition version which I first developed to replace VMX.SYS (which has a LOADed code footprint of just 87 words) is considerably smaller and much faster (3 times the speed of VM: and 2 times the speed of DU:), mostly because far fewer instructions need to be executed in the device driver for an I/O transfer. Note that the original version of the HD: device driver John Wilson wrote in 1995 worked well with unmapped monitors (RT11SJ and RT11FB), but since it did not support 22 bit Qbus usage, it did not function very well using PDP-11/73 emulation when I was using RT11XM running under Ersatz-11. A post that I just made recently compared how long it takes to copy an RT-11 MSCP 32 MB partitions vs an RT-11 HD: 32 MB partitions. Since the overhead should have been averaged out over many blocks per read / write request and the actual transfer of data been about the same, I was initially VERY surprised to observe that an MSCP copy took much more than twice as long or much more than 2 seconds vs just about 1 second per 32 MB copy using the HD: device driver. On the other hand, even the overhead of using an EMT request in RT-11 must be substantial since when subroutine code that is in user space (i.e. does not use an EMT request) is used, the speed of a transfer is again twice as fast as using the device driver. It takes only about 0.5 seconds to copy a 32 MB RT-11 partition using subroutines in user space. Based on the code in the MSCP device driver in RT-11, it is very obvious that MSCP code does MUCH more than in the HD: device driver. Under MSCP, there is also MUCH more code (I am finally responding directly to Dan's observation) that needs to be executed. On the other hand, under HD: all that is required is to transfer the word count, block number and buffer address to the IOPAGE registers (well the physical unit number as well which actually takes more instructions than any of the other variables since the 4 bits of the unit number are also in the CSR) and initiate the transfer. So the reason that Dan notes that the MSCP interface needed so much more code than the other so-called "dumb" controllers seems (in my opinion) because MSCP is just far more complex than it needs to be to accomplish the same result that HD: manages to produce with much less code and much less overhead. The statement that MSCP is an intelligent controller and that the other controllers are "dumb" is, therefore, perhaps correct in that the MSCP interface is able to handle very large disk drives. But the unnecessary overhead of MSCP that compares with the same capability of managing disk drives of up to 2 TB with HD: seems to indicate that a simple dumb interface can be much more efficient as well as easier to use - and take much less code to implement and time to execute. Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.

On Sep 29, 2007, at 5:54 PM, Tony Duell wrote: Hey, did you miss the smiley? ;) -Dave -- Dave McGuire Port Charlotte, FL Farewell Ophelia, 9/22/1991 - 7/25/2007