• Please review our updated Terms and Rules here

MicroPDP-11 - some questions

What's in there now are 2764 EPROMs; I just grabbed the 28C64 EEPROM variant. Pinout's the same and the parts I got are 5V-capable, so I assume there shouldn't be any problems...?
 
Well, no luck - I checked the EPROMs that are in there, and they're identical to the DECROMs image set. Still running through the same sequence...is there a manual for the MXV11-B2 firmware somewhere that would have any indication as to what these lights indicate?

Given that the ROM is standard, I'm a little baffled that it's not saying anything over the serial ports...
 
Sorry if you already answered this but, you are using a null modem cable right ? Have you tried swapping the console ports and try the other connector ?
 
Yes, I've tried it multiple ways. According to the MXV11 manual only the second port can be used for the console, but neither of them worked. I even tried swapping out the physical connectors for the known-good set from my KDF11 CPU; no dice.
 
I had to go try mine and quickly was reminded there is no serial output. You have to hit CTRL-C a mess of times (and I mean a whole lot) to get the boot prompt. It will just sit there and never say anything otherwise if it can't find a bootable device. If something is bootable you get no output until whatever it is running.

You can send a break command too check a little quicker than the ctrl-c thing but, you don't get the boot menu. It will show if serial is working anyway.
 
The MXV11 manual doesn't even tell you that because they don't know what ROM you're using. I found the BREAK thing just because I tried it. The ctrl-c thing I only found on a blog somewhere totally by chance. The manual for the diag ROMs exists but, isn't online anywhere I could find. Seems like the MVX11 was intended for sales for use on other companies products where custom ROM might be commonly used.

Lordy, that's counter-intuitive. I'll give it a try when I get home.
 
Oof. Well, that was a lot of time killed over nothing. I had to cut one of the wire-wrap jumpers to get the console line up to 9600 baud for it to catch my Ctrl+Cs, but I was gonna do that anyway (I'd like to know why they shipped it with the console set all the way down at 300 baud in the first place!) But it worked, and I got the prompt. Getting all the memory to work took a little re-jiggering, but with everything re-ordered in approximate hierarchy of importance (except for having to fill a slot with the printer card before the disk controller comes in,) it's all up and running and boots right into RT-11 as an 11/73 with 4MB RAM!

New plan: eventually, when I know my way around PDP-11 assembler a little better, hack those ROMs to make a little noise during boot!

I haven't yet made any attempts to get the SCSI card working - one thing at a time, I says!
 
I had to cut one of the wire-wrap jumpers to get the console line up to 9600 baud for it to catch my Ctrl+Cs, but I was gonna do that anyway

They have a jumper for software baudrate selection. I assumed it meant using the baud rate selection on the console panel rather than the hard wired one. Since mine are both set to 9600 I am not sure if that's true or not. I've pulled them all out of the case or I would check. Too annoying dealing with all that ctrl-c smashing when trying to boot different things. That diag rom is really primitive. You never know what is happening either. Wonder if there is stuff in the manual that makes it more useful.
 
Hmm. I kinda figured it meant that the baud rates could be selected in code (I'd have to reexamine the manual, though.) My MXV11 doesn't come with a console panel that includes a rate selector, anyway (though my KDF11 CPU does - not sure if it would affect anything.)
 
Hmm. I kinda figured it meant that the baud rates could be selected in code (I'd have to reexamine the manual, though.) My MXV11 doesn't come with a console panel that includes a rate selector, anyway (though my KDF11 CPU does - not sure if it would affect anything.)

I used a standard 11/23 panel with the selector. I just tried and it ignored baud rate selection on the panel. The manual is kind of hard to follow. I wonder if you put it to the software selection the ROM sets the baud rate or it's more to disable the software that is running from changing it. If it's the ROM the diag ones must set it to 9600. Although, there are so many jumpers on these things who knows anything for sure. Anyone want to trade a KDJ11B for a KDJ11A and MXV11B ? ;)
 
The MXV11-B was intended to be used with BC21B cables. The BA23 console connection board with the baud rate switch has its own baud rate clock on it and replaces the baud rate clock on a board it's plugged into. Studying the print set will reveal this.

The console connection is the left (components facing you, fingers down) connection on a MXV11-B. There are many jumpers that have to be set correctly. I studied the manual and determined the right jumpering. Trial and error will not work, there are too many jumpers.

Lou
 
The manual actually has a good flow chart for setting the jumpers. Of course, you have to understand what the things are. What does a BC21B cable look like ? I can't find a picture.

The MXV11-B was intended to be used with BC21B cables. The BA23 console connection board with the baud rate switch has its own baud rate clock on it and replaces the baud rate clock on a board it's plugged into. Studying the print set will reveal this.

The console connection is the left (components facing you, fingers down) connection on a MXV11-B. There are many jumpers that have to be set correctly. I studied the manual and determined the right jumpering. Trial and error will not work, there are too many jumpers.

Lou
 
BC21B has a ten position female header connector on one end and a DB25M wired DTE (as it should be) on the other.

I pulled out my MXV11-B2 out of the test backplane. Below I have listed all the jumper positions. I have it configured to attempt to boot, then to drop to the boot menu if that fails. The console (CSR 177560 Vector 60) connection is on J2 (SLU1) (left with components facing you and fingers down) 38,400 baud and J1 (SLU0) (CSR 176500 Vector 300) 9600 baud for the serial line printer or TU58. Roms are 145 and 146.

J3 to J4 (halt processor on console break)
J8 to J9 to J10 (console SLU 38400 baud, SLU 0 9600 baud)
J16 to J17 (enable roms)
J19 to J20 (4k/8k roms)
J26 to J27 (disable on-board LTC [my backplane provides BEVENT])
J36 to J37 (Q22)
J44 to J45 (bootable roms present)
J47 to J48 (master clock - must always be in)
J49 to J50 to J51 (8k roms)
J61 to J62 (set SLU1 to console)

Lou

The manual actually has a good flow chart for setting the jumpers. Of course, you have to understand what the things are. What does a BC21B cable look like ? I can't find a picture.
 
So out of curiousity, I've generally seen clock speeds for the LSI-11 models given in the 10+ MHz range. The Wikipedia article on the J-11 chipset, for instance, says that it was eventually pushed up to 19 MHz. However, when trying to find a comparable value for the F-11 chipset (in order to compare my 11/23 as it was to the 11/73 it is now,) I found this site, which lists speeds for the J-11 as 3.75 MHz and eventually up to 4.75 MHz. Is that correct? If so, I presume that it uses a four-phase clock like the TMS-99xx chips I was confused about in another thread, and Wikipedia is just listing the input clock rate. What is the advantage to a four-phase clock, anyway?
 
...I found this site, which lists speeds for the J-11 as 3.75 MHz and eventually up to 4.75 MHz. Is that correct? ...

The site at that link appears to suffer from "translation difficulties".

  • The DEC original published DCJ11 CPU manual lists "67ns min" [~15mhz] as the attainable "CLK cycle time" [Appendix B-2].

It's difficult to infer their intent reliably, but the article at your link appears to be incorrectly using the terms "Clock rate", "Core Frequency" and "Microcycle" times interchangeably. These are completely different, often incongruous concepts when applied to older machines.

Perhaps that will help clear things up?
 
A little bit. I see from the "Instruction Timing" appendix, though, that instructions are timed in "microcycles," which are equal to four CLK cycles, so I'm thinking that 3.75 MHz is closer to the mark than 15 MHz.

I realize, of course, that clock speed is only meaningful when comparing two speeds on a similar microarchitecture, I was just curious.
 
If you're trying to appreciate relative "processing power", it's easiest to do within a family of "like" machines.

However, applying MIPS to these machines can be misleading once you cross the boundary into other manufacturer's architectures. Even DEC tended to understate the capability of an 11/70 when making comparisons to VAX11/780.

Such an architectural misalignment could result in a factor of 2-5 for a given comparison.

I've heard it said that an 11/70 with PEP70 memory and enhanced CACHE [offered by the same manufacturer] could attain ~5 MIPS sustained.

DEC in general estimated their 11/84 as being slightly higher performance than the 11/70 - and the 84 had a J11 based CPU with an 18mhz clock.''

However those comparisons don't reflect the actual usefulness when the architectures are considered in a given application. An 11/70 performing a program compile for example, was always assumed to be doing so on a disk drive that was UDA50 connected. An 11/70 was a MASSBUS machine, and if the tests were repeated on this basis, it actually outstripped the 11/780. [which is why DEC stopped making that comparison]

Similarly, CPU instruction rates would need to take into account what computations were being performed, whether a floating point accelerator was present and beneficial, before approaching any meaningful answer.

In RAW terms, 4 clocks per microcycle, 2-4 microcycles per instruction would give a more or less correct impression of a ~1 MIP machine when talking about a J11 @ 15mhz clock. This assumes memory latency is not an issue, and that CACHE was reasonably effective.


Remember too, we're talking about a 16-bit ALU with integer math and multiply / divide instructions. (exclude Floating Point - which is much more cloudy)

Is that a useful yardstick?
 
It's good enough. Again, I'm not trying to come up with precise benchmarks, I was just kinda curious. The thing I'm not really clear on is that the KDF11 manual shows execution times that are vastly longer for the same instructions, if they're using the same definition of "microcycles," which it looks like they are. (40 microcycles versus 14 for CLRD mode 0, for example!) So evidently there was a major improvement in microcode efficiency between the KDF11 and the DCJ11, even without the increased clock speed and cache (again, if I'm reading this correctly!)

Edit: I was looking at the floating-point instruction table. Integer/control instructions show a less consistently drastic difference, but still notable.
 
Last edited:
Back
Top