• Please review our updated Terms and Rules here

History and start of life of my strange 11/45

Thanks for the explanation.

Your remark made me want to experience. I did succeed in highlighting the problem. I did tests with 74LS02, LS38, S38, LS03...etc But I can't reproduce the issue with the 641-1 :)
 
Hi All,

Since last post, I implemented the instruction set. So now the goal for me is to test it. I started by using diagnostics in M9312. I used the code found on AK6DN site and the listing here:

ROM Listing

I don't understand the line 105 .

105 165124 105767 165004 T4: tstb data1 ; test a byte, if we get here...

I don't understand the mode 6 used here. Mode 6 will add PC value to 165004 ? Effective addresse =165128+165004 => ???

However , if I change mode 6 to mode 3 :

105 165124 105737 165004 T4: tstb #data1 ;
Effective addresse become 165004 .

It seems more logical.
Can somebody explains me where I am wrong ? . How the mode 6 can works in this case ?

Best regards.
 
I am stupid !

The listing indicate :

105 165124 105767 165004

To work correctly with mode 6 , operand must relative not absolute. I compared with binary data present into the .ROM file .Indeed inside I found at same location:

XXX 165124 105767 177654 The operand is negative of course.
And now it is logical ! I need to learn to read listing file......
 
I am stupid !

The listing indicate :

105 165124 105767 165004

To work correctly with mode 6 , operand must relative not absolute. I compared with binary data present into the .ROM file .Indeed inside I found at same location:

XXX 165124 105767 177654 The operand is negative of course.
And now it is logical ! I need to learn to read listing file......

The DEC assembled convention is to list the EFFECTIVE address in the instruction listing, not the exact data words of the instruction. Sometimes confusing when you are trying to compare an assembled listing vs what is in memory, but that is the way it is. EG:

Code:
     103                                	; ------------------------------------------------------------
     104                                
     105 165124 105767  165004'         T4:	tstb	data1			; test a byte, if we get here...
     106 165130 001377                  	bne	.			; br . if FAIL
     107 165132 022222                  	cmp	(r2)+,(r2)+		; (R2)+=165000 (R2)+=165002 R2=165004
     108 165134 105722                  	tstb	(r2)+			; (R2)+=000 R2=165005

After the 165004 on line 105 you see the ' (apostrophe) which indicates this is the computed relative address, not the instruction word offset.
You need to subtract the next PC location (PC+2) of the word with the listed value to compute the value of what you would see in memory.
Thus (in octal): 165004-(165126+2)=177654 or -124. You should see 177654 in memory at location 165126.
The +2 might seem counter-intuitive but it is because of the instruction word prefetching done. The PC has been bumped by +2 when this word is used.

Don
 
Hi ,

Thanks Don for your comment . I saw the ' but I didn't know how to interpret it. I was concentrate on the 165004 ...And as you says, it was my error.
Anyway, I am happy today, all tests presents in M9312 passed !. I spent a lot of time around a inconsistent TRAP 4. I finally found the error in bad initialization of bus timeout.
Next step is now to 'torture' the instruction set using DEC diagnostics. And I am sure to find other bugs !
 
Hi ,

Thanks Don for your comment . I saw the ' but I didn't know how to interpret it. I was concentrate on the 165004 ...And as you says, it was my error.
Anyway, I am happy today, all tests presents in M9312 passed !. I spent a lot of time around a inconsistent TRAP 4. I finally found the error in bad initialization of bus timeout.
Next step is now to 'torture' the instruction set using DEC diagnostics. And I am sure to find other bugs !

In most (all?) of the DEC diagnostic listings you will find the directive " .ENABL AMA " which tells the assembler (MACRO11) to turn all relative references (ie, mode 67) into absolute references (ie, mode 37). This has the beneficial effect of allowing the code to be written normally, but all the values then shown in the assembled listing are the real/absolute memory addresses. So the assembled listing corresponds exactly to what is in memory.

The downside of course is that the code no longer is relocatable, but for diagnostics this is not a issue.

Don
 
Thanks for this information..I agree with you, for tests, no relocatable code is not a problem.

I started to explore the maindec 'Jungle' on retropcmp.com . But is not so easy to find the corrects files. I found that the 11/45 is identified by letter C, Cpu by KB . So I search CKB*...And I found 5 diagnostics ..CKBA,CKBB,CKBC,CKBD,CKBE. Each diag test only 1 instruction (..:confused: I suppose that CKB test only instructions specific to 11/45. In this case which CPU do I choose ? 11/20 ?
Is a binary exist with all test wtih all instructions?
Indeed , I probably not started from the correct point...
Is anybody can help me ?
 
Thanks for this information..I agree with you, for tests, no relocatable code is not a problem.

I started to explore the maindec 'Jungle' on retropcmp.com . But is not so easy to find the corrects files. I found that the 11/45 is identified by letter C, Cpu by KB . So I search CKB*...And I found 5 diagnostics ..CKBA,CKBB,CKBC,CKBD,CKBE. Each diag test only 1 instruction (..:confused: I suppose that CKB test only instructions specific to 11/45. In this case which CPU do I choose ? 11/20 ?
Is a binary exist with all test wtih all instructions?
Indeed , I probably not started from the correct point...
Is anybody can help me ?

So have you read this? http://www.classiccmp.org/cini/pdf/DEC/PDP11_DiagnosticHandbook_1988.pdf

The first three diagnostics listed are 11/45 related CPU diagnostics.

A loooong time ago the DEC requirement for diagnostics was that they be limited to be at most 4KW/8KB in load length (via papertape).
So lots of small diagnostic tests were written to test various features of a CPU (like the 11/20, 11/45, 11/40 which were the 1st gen of PDP-11s).
The limit was imposed to make the diagnostics be 'user friendly'. Loading an 8KB image via tape is a lot easier than a 32KB or more image.

Probably you will find the 11/45 diagnostic tests on the v2.2 RL02 XXDP image, I don't think they were included on the v2.5 image.

Don
 
hi Don, thanks again.:D . And no I didn't read this document . I searched on other site . I will study especially CQKCGO that seems to be what I am looking for.
If yesterday I was happy , today is different..I am breaking my brain on the M9312 listing .
There is a sub routine called "prteol" and there is a incomprehensive part (for me) here :

261 165510 061702 add (pc),r2 ; bump count
262 165512 003767 ble retR1 ; done if expired


When the CPU executes the add , PC contains the next addresse so 165512, that means (pc) give 003767 . Why adding 03767 to R2 ??? Look like there is a big ingeniousness here , but I don't see what !
 
hi Don, thanks again.:D . And no I didn't read this document . I searched on other site . I will study especially CQKCGO that seems to be what I am looking for.
If yesterday I was happy , today is different..I am breaking my brain on the M9312 listing .
There is a sub routine called "prteol" and there is a incomprehensive part (for me) here :

261 165510 061702 add (pc),r2 ; bump count
262 165512 003767 ble retR1 ; done if expired


When the CPU executes the add , PC contains the next addresse so 165512, that means (pc) give 003767 . Why adding 03767 to R2 ??? Look like there is a big ingeniousness here , but I don't see what !

This is all a lot of shenanigans to get the code to fit in the allowed PROM space. The author is making use of the value in the upper byte of the next instruction (ble retR1) as the value to subtract from the initial count to loop the required number of times.

As an example of 'good coding' the M9312 PROM images are not a good place to look (both the console and boot PROMs). They do a lot of this funky stuff to get the code to fit in the required space, and do what needs to be done. It is NOT an example of good coding style, unless you are a fan of the obfuscated C contest. I would just ignore it for now and move on.

Don
 
Hi,

After a silent period , I come back with some informations.
The instructions set is now almost complete except state manipulation.After implementation of this , I decided to run a maximum of diagnostics to validate my work. I am happy to show the result today.

Screen Shot 07-05-19 at 08.31 PM.jpg

All diagnostics I found for the CPU, passed !:eek:nfire: To be honest some of them was really hard (TRAPS,STACK Limit for example). Globally , it was very interesting and tests are very vicious ;).

Now some questions :
Do you think there is some diagnostics missing for this CPU (KB11A ) ?

I found a issue with my hardware around power supply. In the real 11/45 , you can power off the CPU without cutoff the memory. It is a requirement for power fails diagnostics.
I found in console schematic, a GND IN + GND OUT that can link together (Ok understood). There is also a GND A (A for always ?) , never cut.
I found also a GND A in SPC pinout description. I didn't found GND A on MUD pinout.
Can anybody help me to understand how it is working with memory board?

Thanks for help.
 
Nice work, Activmaker! I found it a non-trivial undertaking to even make a real '11/45 pass the full suite of MAINDECs :)

I note you discovered the timing sensitivity in CKBM -- I ran into this as well. The diagnostic as written (I was working with version E0) has an apparent bug and is sensitive to preconditions of the console serial card when certain tests run. I found on my real '11/45 that I could pass that diagnostic consistently if I set my console DL11 down to 4800 baud, or if I modified the diagnostic code to make sure there was still a character in one half of the DL11 xmit double-buffer before the failing diagnostic ran.

Interestingly, I see you have a similar note for diagnostic CKBN. I didn't have any difficulty with that one, but my real DL11 only goes up to 9600 baud...

As for the memory and the power fail tests, I think these routines were written assuming actual core memory, which would retain its contents across power cycles without need for any power.

cheers,
--FritzM.
 
Hi,
Thanks for the comment. About CKBM, I don't think it is a bug. The diagnostic has been made to be used with teletype, so the speed of thid kind of device was < 9600.
In the real 11/45, this test need speed <=4800. This information is useful for me as it means than my implementation is a little bit faster than the real one. Indeed,one caracter is emit, interrupt are activated , then some instructions are executed and then a "wait" instruction is present to get the capture the interrupt. If the speed is too high (>4800), interrupt occurs before the "wait" , and the test fails. In my system, look like that CPU can reach the "wait" instruction before interrupt occurs even at 9600. I didn't make test with speed between 9600 and 115200.
About CKBN, you are absolutely right. Test passed even at 115200. My note is incorrect.

Now about the power fails test, if you read the PDF DCKBP-B_1145_PWR_FAIL.PDF, you will see that the test require the real shutdown of system except for memory:
7 :Restritions
Do not power down the MOS or BIPOLAR, Just the processor

With core memory , you are right as this kind of memory keep information even whithout power supply.
So, in my case (I use CMOS Memory), if I want to pass this test, I need power off processor, without power off memory. Regarding schematics , It seems that there is 2 GND, 1 cut with power switch and used by processor, and a other one called GND A, probably used by memory. As I don't have a real 11/45 , I am wondering if memory board (Mos and bipolar) use specific backplane or do they use the GNA present in SPC connectors.
I would like to passed this test, because I made a small board between power supply and backplane to manage ACLO and DCLO signals. I would like to known if this board is ok or not. For me , today it is not the case, because if I powered off , all system is down (processor + memory) . Before , make a change in my hardware ,i am looking for more information how the hadare of 1145 manage this case.
 
On the real 11/45, MOS/BIPOLAR would have been one of two types: FASTBUS (dedicated, non-SPC slots on the 11/45 backplane) or UNIBUS (which would have to be put into an expansion backplane). I am not aware or any quad-height SPC memory options that would have fit into the three available SPC slots on the 11/45.

Expansion backplanes with MUD slots had "+15 BAT", "-15 BAT", "-5 BAT" pins (pins AR1, AS1, and BD1, respectively) meant to be supplied by battery backup units, and many of the UNIBUS memory options draw power from these pins. In fact, a common fail when configuring UNIBUS memory options is not to have power to the corresponding harness pins when installing expansion backplanes in systems without a battery backup.

I would have to check the wiring for the FASTBUS backplane memories (since I don't have any of these in my 11/45, I am less familiar with them). The 11/45 was customarily configured, however, with one H742(0) master power regulator that was "switched" (controlled via the front panel key) and one H742(0) master regulator that was "unswitched" (on as soon as the master power distribution breaker is closed). I would suspect that the FASTBUS memory options were supplied by the 11/45 power harness from mini-regulators installed in the "unswitched" master regulator, and so would remain powered if the CPU was power-cycled via the front-panel key. I'll check the docs on this and follow up here.

One other note: there is a lot of variability in what is connected/supported on the 11/45 backplane SPC slots. Early serial-number 11/45's didn't have certain power or other signals wired at the factory for these three slots; the wiring to make them identical with the later standardized expansion backplane SPC slots didn't come along until later, as a set of ECO's. Unfortunately, records of these ECO's are incomplete. I have not yet to date been able to find any wiring list for the 11/45 backplane, either (as I'm sure you are aware -- one needs to reversed, signal by signal, from the callouts on the engineering diagrams).
 
Thanks for this answer. I really appreciate . Since my last post, I read the documentation EK-1145-OP-001 Found on bitsavers with name 1145_SystemMan. pdf . As you said in your last post, there is 2 H742. The upper is driven by console and can be switched off. The lower not (by console) . So, yes, FASTBUS backplane should be powered by the lower one, CPU with the upper one.
Anyway, look like that the console switch cut on the AC part as the H742 only give AC power (As I understood). I don't know why DEC use GND IN, OUT and A in the schematics ..:confused:
I went to your github repository. You have very good pictures of your 1145. So, now I start to see how I can organize power supply ;) .
 
Hi ,

Since last message (1 year ago) many elements has been added to my system .
Around august, I decided to work on software improvements. I wanted to have a better emulated console than M9312.
I implemented almost all functionnalities on physical console (Load adresss, deposit, exam, register deposit, register exam, start and cont ).
Using a free micro switch on CPU on board, I can have now the 'ENABLE/HALT' button. For example if a "HALT" during M9312 console program :

cONS3.PNG


Then at this place , I can examine/change register or memory and use "cont" command to resume program.

Cons4.PNG


**********

An other improvement was to build a power distribution more like the real 11/45. This is the schematic diagram :

PowerDistrib.PNG

So, now I can have one part permanently powered and an other switched. For example , my memory board is permanently powered, programs are not lost when CPU is OFF.
The control board capture sector frequency (50 or 60 hz) and gives a TTL signal to the CPU. I used this signal to implement a KW11-L on the main board.
The sector capture is also used to manage ALCO signal.
The control board has also a "feedback" from power regulator to monitor 5V.
One control board can control an other one. If some day I have more than 1 cabinet :).

**********

Finally, I made an big improvement on my system,that seems to works , not totally tested and implemented. So, stay tune. I will post a new message in few days with many pictures to explain it.
 
Hi,

Since 1 year , many changes has been made. My last post talked about 'minor' changes , but today I talk about a major change.
Last year my system had a fonctinnal CPU/Memory ,but without any mass storage capabilities , it was not really useable.
So, I decided to make my own RL11/RL02 system. I wanted a concept near of RL02 but not so big. For the cartridge, I chose this case :

rl02k2.jpg

Each case have a hole and then can be locked by RL02 :

lock2.jpg

Cases are smaller enough to have 4 in a 19" rack, so I made a quad RL02, able to receive 4 RL02K.

rl02quaq2.jpg

I also made a front panel to drive the 4 units. Height is 3U.

panel2.jpg

After that, I made the RL11 board. Simpler than the CPU board.

rl11_2.jpg

To have a 'global' view of system :

RL11.jpg

As you can see, a computer can be used to extract data from cartridge to file, or transfer file to cartridge. At this time , RL11 is in debug mode and is sending log info to computer. Computer can be used to change base adress (174400) or vector (160). It can also be used to change SPI or serial parameters and other things.
Computer can become owner on any RL02K if this one is not used by unibus. Other cartridges can be used by unibus in same time than the computer. Unibus has
more priority than computer.

The complete system :
cimplete2.jpg

I can describe with more technicals details , ask questions if you need more informations.
Your comments are welcome.
At this day, RL11 functions are implemented , not completely tested, DMA tested and seems working. BR not yet working .
I think I have at least 2 weeks of works to finish implementation and basic tests , before starting starting diagnostics.

Thanks for reading me.
 
After a long period with a lot of issues , I am back with new infos : My strange 11/45 is now functionnal and can boot XXDP2.2 XXDP2.5 RT-11 and RSX-11 M . I am really happy to have my system working . :eek:nfire:

RT11Config.PNG


What problems I discovered :

When I started to test my RL11 board , the system became instable . I suspected something wrong with the new board but even whithout the RL11 , issues were present. Problems was intermittent. After a long period of tracking , I discovered that some backplane connectors was damaged ! . I was using EDAC connectors , but the quality was poor. The only choice I had was to re build a new backplane with others connectors (I use now Sullins ). Making a backplane need a long time (Lot of soldiers + wire wrapping ).

After that, system came back, but not for a long time :( . During DMA Test of RL11, some data was corrupt in memory. The reason was hard to find : the memory board has not been cleaned enough and 2 pins of memory chip was linked by dry soldering flux !!.
Since the system was stable ,I started diagnostics of RL11 . I took a long time , but finally all diagnostics passed !
XXDP 2.2 was functionnal , but none of other :( . XXDP2.5 was looping during boot.By exploring boot sequence, I discovered that my system answering to 1 address but it should not ..Easy to fix .
XXDP 2.5 Was now functionnal.
RSX-11M was not booting with a lot of errors messages, and RT-11 Stop in HALT instruction with a PC at very strange address.
I started to analyse source code of RT-11 , trying to follow what happenennig during boot..It was a really hard job !! :shock: . After many weeks of debugging , I discovered that some instructions in CPU didn't set the carry bit correctly ! Instructions was RORB,ASLB,ASRB . I was surprised that CPU diagnostics didn't find these issues !
After fix of instruction implementation, RT-11 was functionnal, and RSX too !

Next step is now to make more tests, finish some improvments in code, and starting thinking about the box and of course making blinkenlights panel !
Comments are welcome...
 
Back
Top