• Please review our updated Terms and Rules here

PDP 11/45, Part 5

Hi Marty,

For level converters, I used these:

74AHCT125 (https://www.adafruit.com/product/1787)
74LVC245 (https://www.adafruit.com/product/735)

Looking back at my project, it was a Digilent Basys board, not Nexys, but I'm sure it would work fine on the Nexys. Basically the project is just a big binary counter driven at 9600Hz -- the ROM address bits and control signals are derived directly from various bits of the counter. The bits read out from the ROM are latched into parts of a big shift register, driven off the same clock, that generates the serial output. Constant bits latched into the shift register around the data bits do the ASCII conversion and formatting. It ends up just being a single page of Verilog.

Now that I have the Data I/O, I probably won't need this anymore, but it was a fun excuse to play with the FPGA board :). Happy to answer any questions if you decide to give it a try on one of your boards.

cheers,
--FritzM.
 
Marty/Fritz,

I have just sent you both (directly outside of VCFED) my 11/45 microcode spreadsheet for your enjoyment and feedback whilst I am away on a business trip...

I think I will add the KT11-C microcode extensions fields into this same spreadsheet in the not too distant future. Still thinking about the FP11-B (whether a separate spreadsheet or to integrate that too). Also - what about the 'other' ROMs dotted around the 11/45? Add those as well for posterity?

Regards,

Dave
 
Hi All;

Thank You, Dave for Your Vibrant work..

"" Also - what about the 'other' ROMs dotted around the 11/45? Add those as well for posterity? ""
Yes, By all means, anything in an 11/45 that has a Proms Please, when You can, Include..

THANK YOU Marty
 
>>> Thank You, Dave for Your Vibrant work..

No problem. I am learning useful stuff myself as I go along this journey...

I had a bit of 'down time' at work today because my IT doesn't work!

I have cross-checked my EXCEL ADDRESS_ORDER table with the flow diagrams in the 11/45 Engineering Drawings dated June 74. The only discrepancy I have found is on flow diagram 12 with TRP.00 (word 013) and TRP.01 (word 014). In my ADDRESS_ORDER table these words are identified by the mnemonics of TRP.01 and TRP.02 respectively. I did notice the 'clash' as I have two TRP.02 mnemonic entries in the table (words 014 and 124). Word 124 is correctly identified as TRP.02 in both my ADDRESS_ORDER table and flow diagram 12.

My proposal (to keep everything consistent) is to assume that the 11/45 System Engineering Drawings of Jun 74 are 100% correct and modify my tables accordingly (it is purely a change to the mnemonics TRP.01 -> TRP.00 and TRP.02 -> TRP.01).

Everything else appears to match perfectly OK.

I did notice in passing that there are two copies of flow diagram 8 in the PDF!

I hope this is clear! If not - keep re-reading it until it does make sense... Or wait for me to re-issue my spreadsheet...

Next check is for the microcode table entries themselves and for the VB code to combine the microcode bit fields into the HEX values for the ROM's

Dave
 
Hi All;

Dave, Yes, TRP.02 is in two places..

So far, what I have looked at seems to match..
At present, I am minimally putting into my EEprom, only what Routines that are needed, to get it working by Reset, and the Examine and Deposit switches.. It is coming along, as I put more of the Routines in..
I haven't figured out 'how' it gets from Reset to Console, Yes the flows show a branch to con.00, but the micro-code UAD's don't reflect where that happens.. So, it's partially working, I have another bunch of them to add, and then I can try it again..
I have to do some converting between, Binary, Octal and Hex, but I can manage..

I can get it to partially work, but I think, that the Problem is the slowness of the EEprom in reading mode,
Compared to a Prom in reading speed..

If Possible can You make a table that is Octal, since the tables are originally Octal and not Hex, for the ROM Entries, for checking purposes..
Also, another field that would be useful would be the UAD address to the ROM tables, so following the Micro-Code current position to where it would go next, would be Helpful..

THANK YOU Marty
 
Last edited:
I have just sent you both an updated spreadsheet (and PDF printout for Marty's benefit) of version 0.3.

Yes - your EEPROM may be just too slow compared to the ROMS.

The UAD column was already in the table - it had just become 'detached' from the other part of the table due to being too big for the virtual paper it thought I was printing on. I have now changed the virtual paper size to A3 landscape so all of the microcode fields are printed on the same paper width.

There is no benefit in me printing the microcode word out in OCTAL... Take for example the 8 bit field UAD. This conveniently fits in two 4-bit EPROMS. However, the 8 bits for the UAD field would occupy 2 and 2/3 of an OCTAL digit with the third OCTAL digit having the least bit of the next field (BEN) merged with it. It then gets progressively worse for all of the other fields as they are 1, 2 and 3 bits - but the 3 bit fields are sometimes split up over OCTAL (and HEX) digits. This is the whole point about displaying the HEX value - as each digit of 4 bits maps onto a single ROM. If you want to check the data that I have entered - you need to check each field entry in the table - not the resultant 64-bit microcode word itself.

Yep - I have to check the Visual Basic conversion from the individual bit fields to the full HEX word - but that is a separate issue.

To answer your issue regarding how the microcode gets from one word to another it is not simply a matter of directly using the UAD field to go from one word to the next. As I read it (and Fritz may be able to confirm) the UAD field is 'modified' by external conditions to give the next microword that is executed. Take (for instance) CON.00 and CON.01 at word addresses 170 and 167 respectively. They both have a UAD field of 070 - but (depending upon the state of the console switches from external-to-microstate logic) we could execute microcode at addresses 071, 070, 072, 074, 073, 075, 076, 077, 270 - or 170 (if no console key was depressed). Some of these signals (on a quick look) are derived on schematic UBCH (CNSL00, 01 and 02 amongst others) and arrive at the microcode branch logic on schematic RACK.

So - 'guessing' how we get from one microword to another is not quite that easy - but is somewhat intimately involved with the hardware gates associated with the microcode sequencer logic.

Hope this is enough to get you going - I have an event on at Church tonight so I have to run...

Dave
 
Hi Dave;

Thank You for the Explanation, and the update..

I Understand about the Octal Vs Hex situation..

"" Hope this is enough to get you going "" Yes, this is enough for me to grasp for now..

I am looking into what it would take for me to Use my Step System, it Uses very fast Cache Rams as Memory (2147's)..
Which IF I can make it work, would be Fast enough for the Micro-code to Execute..

THANK YOU Marty
 
daver2 said:
To answer your issue regarding how the microcode gets from one word to another it is not simply a matter of directly using the UAD field to go from one word to the next. As I read it (and Fritz may be able to confirm) the UAD field is 'modified' by external conditions to give the next microword that is executed. Take (for instance) CON.00 and CON.01 at word addresses 170 and 167 respectively. They both have a UAD field of 070 - but (depending upon the state of the console switches from external-to-microstate logic) we could execute microcode at addresses 071, 070, 072, 074, 073, 075, 076, 077, 270 - or 170 (if no console key was depressed). Some of these signals (on a quick look) are derived on schematic UBCH (CNSL00, 01 and 02 amongst others) and arrive at the microcode branch logic on schematic RACK.
Dave
Click to expand...

The PDP-9 does the same thing. There is a series of microinstructions to fetch an instruction from core, then external logic decodes the instruction and modifies the next microaddress. There is additional external logic that handles the address modifications for indirect addressing, autoindexing, etc. We really needed a logic analyzer to follow the microinstruction flow.
 
daver2 said:
As I read it (and Fritz may be able to confirm) the UAD field is 'modified' by external conditions to give the next microword that is executed. Take (for instance) CON.00 and CON.01 at word addresses 170 and 167 respectively. They both have a UAD field of 070 - but (depending upon the state of the console switches from external-to-microstate logic) we could execute microcode at addresses 071, 070, 072, 074, 073, 075, 076, 077, 270 - or 170 (if no console key was depressed). Some of these signals (on a quick look) are derived on schematic UBCH (CNSL00, 01 and 02 amongst others) and arrive at the microcode branch logic on schematic RACK.
Click to expand...

Yup. There are three ways to get to the next microinstruction -- "normal" (just use the UAD), "branch" (use UAD ORd with branch bits), or "fork" (UAD ignored and next address generated directly by fork logic)

The branching logic monitors various logic conditions within the processor (which conditions to monitor is selected by the BEN bits in the microinstruction). Branching logic produces two bits of output, and these two bits are ORd with bits 5 and 4 of the UAD. If bits 5 and 4 of the UAD are both zero, this can provide a four-way branch. If one of bits 5 or 4 in the UAD is one, this can provide a two-way branch. This is described in section 7.5.7 of the KB11-A maint manual.

The branching for the console switch operations is a special case. When BEN bits are 14, special logic is enabled that modifies UAD bits 7, 6, 2, 1, and 0 based on console switch logic on the UBC module. This provides the 9-way branch you can see on page FLOWS 14 in the engineering drawings.

There are three separate forks in the 11/45: A, B, and C. These are used when many-way branching is needed. Only one fork at a time is used, and they are enabled by the FEN bits in the microinstruction. They each have their own logic to generate the next microaddress in its entirety (UAD field is ignored). The A, B, and C forks are described in sections 7.5.3, 7.3.2, and 7.3.3 of the KB11-A maint manual, respectively.

Tables 6-4 through 6-7 in the KB11-A maint manual are very handy to consult when stepping through the microcode flow diagrams while debugging -- these list which forks are enabled for each instruction, and if a fork is enabled for an instruction then they tell what the expected destination state is.

--FritzM.
 
Hi All;

FritzM, Thank You for Your very detailed explanation of what is going on..
I will have to look into this and see if it makes any sense to me..

I have placed an order for 10 each of the 74AHCT125 and the 74LVC245 from Adafruit, I never heard of them before this..

I am going to sort of switch gears, I am going to go away from the Step System, as it doesn't work, and concentrate on two things,
One, Verifying Dave's code, it looks like I will be forced to get to know Hex better and
Two, make an attempt at building FritzM's FPGA Board interface, to check that I have some Blank 82S129's to send to FritzM, to program..
That will be the quickest possible fix to my problem on the 11/45..

Dave and FritzM, I may have found a first mistake, I check my columns by 8 bits or 2 words..
On Address '006 and '007, Dave has 'A9 on both places, and I have '69, the bit pattern is '251 Octal as I read it, and a bit pattern of '01101001..
In the checking of the first 15 locations, I found three of my own mistakes, but besides the above the rest are all OK..
On Address '027, we both had it wrong, I had 'CB808, You have 'C8008, and I read it now as 'C9808, for the left most 5 digits..
The rest of Address range '016 thru '32 are Ok, I have not marked '027 as OK, until we all agree on what we read..

I have copied down All of Dave's Hex numbers into my NoteBook, it just barely fits, I have 5 pages for misc notes at the end..
Now, I can get away from my computer, and hopefully get rid of this Headache, and compare what I have in my NoteBook to Dave's Hex numbers..

THANK YOU Marty
 
Last edited:
Fritz: Post #189 was a great help. Thanks. I think I am going to have to print out the KB11-A Maintenance Manual and read it from cover to cover...

Marty: Thanks for having a look at my table.

Addresses '006 and '007 have a UAD field value of '251 (the BEN field being 0) = 0xA9. You seem to have 'slipped' the most significant bit right by a bit (i.e. missed out a '0').

The first 5 hex digits of the microcode at address '027 should be 0xC8008 according to my 'by hand' calculations:

BRK = 1 = 1
BRX = 1 = 1
SRX = 0 = 00
DRX = 2 = 10
SRK = 0 = 0
DRK = 0 = 00
CCL = 0 = 000
PCA = 0 = 0
PCB = 0 = 00
SHF = 1 = 01
IRK = 0 = 0
PWE = 0 = 00

= 1100 1000 0000 0000 1000
= 0xC8008

Dave
 
Hi All;

Dave, Thanks for the Check-up..

I will re-check Both of them and report Back to You..

I see my Mistake on '006 and '007, I put in an '01 instead of an '10 for Octal bit '2..

BRK = 1 = 1
BRX = 1 = 1
SRX = 0 = 00
DRX = 2 = 10
SRK = 0 = 0
DRK = 0 = 00 <<<
CCL = 0 = 000
PCA = 0 = 0
PCB = 0 = 00
SHF = 1 = 01
IRK = 0 = 0
PWE = 0 = 00

I see Looking at my Listing here at my place and on the Bitsavers Listing, that DRK = 3 = 11 or am I seeing it WRONG ??
Address '024 shows '0, '025 = '0, 026 = 3, '027 = 3 and '030 = '0 as I see it..

I have taken a break from checking things, but I will be back to it soon.. My eyes can only take so much at a time or for a Day..

I have started to check addresses '034 thru '051.. This checks out OK..
Next is addresses '052 thru '067..

I found another Possible problem, at address '061 You have (starting on the left side) '07810, and I have '07C10, as CCL is a '4 = 100, You have '0..
Otherwise '052 thru '067 is OK..

Fritz, On Your FPGA Board is Your 74LV245 and the 74xx125 both tied to +3.3 or to 5.0 Volts for Power ??

THANK YOU Marty
 
Last edited:
Now I understand - my mistake.

Yep - I agree that DRK for word '027 is in error in my spreadsheet as is CCL for word '061.

Keep up the good work and thanks for finding these faults. I will correct them.

This is the reason work needs to be checked by someone other than the original author to find the problems and get them rectified before they propagate...

Dave
 
Hi All;

Dave, No Problem..

"" This is the reason work needs to be checked by someone other than the original author to find the problems and get them rectified before they propagate... ""

Not only that but, when we program some Proms, they have a better chance of being correct.. As, so far these are hard to find, in the 82S129's..

On addresses '0122 and '0123, You have BRK as '0 and I see it as a '1, so Your hex code would be '80010 for '0122, and '80000 for '0123.. Starting from the left side..


THANK YOU Marty
 
Last edited:
Marty said:
Hi All;

Dave, No Problem..

"" This is the reason work needs to be checked by someone other than the original author to find the problems and get them rectified before they propagate... ""

Not only that but, when we program some Proms, they have a better chance of being correct.. As, so far these are hard to find, in the 82S129's..

THANK YOU Marty
Click to expand...

I have a box of about 1000 or so N82S129N parts NOS that I got about 10 years back. Still have about 900+ left.

They are useful as the device boot proms for M9312s (DEC called out 512x4 parts, but never used the other half - so the 256x4 82S129 works fine).

I also have the capability to program them if need be (EEtools TopMax programmer).

So just ring me up (as they say, I don't) if you need any help with this.

Don
 
Hi All;

Don, Thank You for the Generous Offer..
Once, we get the code worked out, I will probably Take You up on this Offer..
And then, once I find out which ones of my Set are Bad, have You make them as well..
That way I have a fully NOS programmed set of Proms..

Dave, on the Addresses that I have checked, Except for '0122 and '0123, the rest of them are fine up to Address '0175, I haven't checked any further, yet..
Addresses '0176 thru '0303 are all good..
I have checked from Addresses '0304 thru '0377 and they are all Good, Mine had a few mistakes that I corrected..

THANK YOU Marty
 
Last edited:
Hi All;

I have sent out the 16 Individual files for the proms of the 11/45, (they still need to be checked) to Dave and Fritz..
I will check them out from my other NoteBook files I have on the Proms, next week..
And after that AnyOne who Wants them, can ask for them, as long as I have an Email Address to send them to..
And Once they are Verified, then I can Ask Don to Program some for me, but that will be sometime next week, Hopefully..

THANK YOU Marty
 
Great news Marty - so if I import those into my spreadsheet I can (a) automagically check for errors in my spreadsheet and (b) check for errors in your ROMS at the same time...

That may be this afternoon's job - after I have done everything else the Church, Wife and Son have lined up for me today...

Dave
 
Hi All;

Dave, Thanks for Your Input, I was beginning to think You had disappeared off of the face of this forum.. Having not heard from You in awhile..

"" automagically check for errors in my spreadsheet ""
YES,

""and (b) check for errors in your ROMS at the same time... ""
Well if You change Your Word ROMS to NoteBook, Then I can agree..

Since, I have just started to actually check the ROMS..
And I was just going to state something (here in this Post) that I may have found, I cannot completely confirm my theory until Monday..
But, it looks like, two of the Addresses Pins 3 and 4, (addresses 3 and 4) when some of the other pins are Addressed they are then turned on, by the Proms itself.. And show the wrong opcode..
I have two Proms on the BreadBoard, and the Address lines are wired together for both proms, and I need to Separate the two, and see if it is only one of them doing this Behaviour, One of the Proms is E90, which is one of them that looks like it is blown up, The other one is prom E89, which is the first pair for the UAD Address lines, and it could easily be checked as two hex numbers, as I have it in the NoteBook..

THANK YOU Marty
 
No - not disappeared off the the face of the forum - but IT have 'screwed my account' at work when they should have just copied me from one server to another... It will take another week or so to 'unscrew' the mess! One day to mess it up - but two weeks to unscrew it...

I 'massaged' your ROM files a bit (once I had worked out each ROM file was 128 lots of 8 bits rather than 256 lots of 4 bits) and imported the results into my spreadsheet.

When I compared my HEX listing to your ROM files (well, EXCEL compared them...) I only noticed errors in OCTAL addresses 122, 123 and 275 - the errors at address 027 and 061 have disappeared (see back to post #193)???

ADDRESS - ME - YOU

027 - C8008BC031004CCF - C8008BC031004CCF
061 - 0781000006C100AC - 0781000006C100AC
122 - 00010A003E812D6F - 80010A003E812D6F
123 - 00000A003FC1005A - 80000A003FC1005A
275 - 0002A0017D0000C0 - 0002A001700000C0

Are your Exx.bin files listings from the actual ROMs - I just want to check that this is what they are rather than something else?

Cheers for your hard work in playing with the 'bits'.

Dave
 
You must log in or register to reply here.
Back
Top