• Please review our updated Terms and Rules here

Heathkit H11A Gett'er Working Thread.

bladamson

Veteran Member
Joined
Nov 11, 2018
Messages
986
Location
Appalachia
Good evening gentlemen.

Within the past month or so, I've become the latest caretaker of a Heathkit H11A and a pile of QBus cards. This is a machine that has been on my bucket list for some time, so I am very excited to be able to service the machine, get it back in operating order, and document as much of it as I can.

To that end, I'm posting some videos about it. There's been a short interruption as I embrace sobriety and clean out and reorganize my workshop, but I am almost to the point of putting up the new workbench at which point the H11 stuff will continue.

If you feel up to the task of sitting through my rambling, this specific content can be found on the following playlist on my Odysee channel: https://odysee.com/$/list/499e7da1db27b44db14312660f741e4afca52b49

I also post to YouTube, but I delay posts there by one week to encourage the use of alt-tech platforms: https://www.youtube.com/playlist?lis...5LTZEM0FteJ27D

I shall update this thread as new content on the subject is produced. Here's what I have so far:

- The Heathkit H11 (PDP-11) | A look at all the qbus cards, and fixing the power supply.
https://odysee.com/@Old.Computer.Fun:f/H11-01:f

- The Heathkit H11 (PDP-11) | SASI, Mounting PDP-11 Filesystems on Linux, and a Qbus Ethernet Card.
https://odysee.com/@Old.Computer.Fun:f/H11-02:0
 
What a nice system. Yes Heathkit and digital in one box this is really awesome. The disk controller most likely talked to a Xebec S1410. I have almost the same controller and have attached a SD2SCSI Version 5.0, I had no success using a SD2SCSI V5.1, with the newest firmware. As the controller emulates emulates an RLV11/12 you need to create some RL02 images and then convert them. Here is some information and a way to create disk-images for the SD2SCSI with 256 sectors (it's actually just splitting the 512bytes sectors of a RL02 disk image into 2 x 512 sectors on the SD-Card with the first 256bytes going to the 1st sector and the second 256bytes going to the 2nd sector) https://www.5volts.ch/posts/plessey/. It's at the end of the web page.
 
What a nice system. Yes Heathkit and digital in one box this is really awesome. The disk controller most likely talked to a Xebec S1410. I have almost the same controller and have attached a SD2SCSI Version 5.0, I had no success using a SD2SCSI V5.1, with the newest firmware. As the controller emulates emulates an RLV11/12 you need to create some RL02 images and then convert them. Here is some information and a way to create disk-images for the SD2SCSI with 256 sectors (it's actually just splitting the 512bytes sectors of a RL02 disk image into 2 x 512 sectors on the SD-Card with the first 256bytes going to the 1st sector and the second 256bytes going to the 2nd sector) https://www.5volts.ch/posts/plessey/. It's at the end of the web page.

Ah drat, version 5.1s are all I have! There are some Emulex UC7s on ebay, but the prices are absolutely insane. I guess I'll be emulating drives with the qbone for now then.

Thanks for the info. You've probably saved me a pile of headaches.
 
Don't give up. I did not really investigate the issue for a long time when activating my Plessey controller. Mostly due to the fact, that my V5.0 with the newest firmware immediately worked. I tried the V5.1 several times but perhaps I was just not patient enough. The main reason I did give up fast was the fact that Version 5.0 is still available at https://itead.cc/product/scsi2sd/ for quite a decent price. And as I want to have as many SCSI2SD as I have systems I anyway had to buy another one.

You should try your luck with one of your V5.1 SCSI2SD, perhaps your controller is not as picky as mine. YMMV. Also, I checked the SCSI2SD Wiki and found that the V5.1 and newer got a major firmware upgrade. I definitively will give it a try with my Plessey RLV12 controller when I have time. You could as well contact Michael McMaster perhaps he has some more ideas.

And then there is still your QBone which can emulate RLV12 and MSCP.

Edit: it seems the major update is only for 5.2, but not for 5.0, 5.1 and 5.5 :rolleyes:
 
Last edited:
So he could flash the firmware back to 5.0? Or forward to a newer one? I don't remember if this can be done. I have an older SCSI2SD but have not messed with it in some time.
 
... Version 5.0 is still available ... And as I want to have as many SCSI2SD as I have systems ...

Hmm yeah, all of my SCSI2SDs are already assigned to machines, so I guess getting a 5.0 if needed wouldn't be that big a deal anyway.

Thanks again, gentlemen.

FWIW, I ought to have my new bench built by the end of the week, so hopefully I can dive back into this thing. I am really anxious to get it going.
 
So he could flash the firmware back to 5.0? Or forward to a newer one? I don't remember if this can be done. I have an older SCSI2SD but have not messed with it in some time.
The figures refer to the hardware revisions. Many revisions require different firmware which is not compatible with the other hardware revisions.
 
The forum software won't let me edit the original post anymore, so after a huge delay..... Here's the next vidjeroo.

Please let me know if I am about to step on any landmines I'm not anticipating. I'd really hate to let the magic smoke out of any of this stuff!!!

 
I have these three cards that came with the H11, which are somewhat mysterious.

20220703_143429.jpg20220703_143452.jpg

M9401 appears to be a backplane extension card, for adding an additional card cage and chassis.

M9400-YB appears to be a 120 ohm passive bus termination card, presumably to be used at the end of the expansion chassis. Nothing is populated but those resistor packs and a few capacitors.

M9400-YA is the same PCB as M9400-YB, but with a bunch of extra stuff populated. DS8641 bus drivers along the bottom. A couple of 6306 PROMs(?), S7628 and S7619 mystery ICs, 74174 flip flops and a DM8136N comparator up from that. More flop-flops and a couple DM8556 counters up from that. And finally another flip flop, some 74-series logic, an MC4024 multivibrator, and some kind of trim pot up in the corner.

That's a 512x4 ROM. Surely not big enough to be some kind of boot rom? What the heck is all that extra stuff supposed to do?

20220703_150930.jpg
 
PS: I assume that those red chicklet caps are mylar and they along with the ceramics will be fine. But those silver ones are probably film caps, yes? Should I be expecting to replace those? They're on about every card I've got.
 
The M9400 are terminators - and may have bootstrap ROMs on them to boot (no pun intended).

The M9401 permits one QBUS to be linked to another (for expansion purposes).

That's my 10 pence/cents.

Dave
 
Ah so they are boot roms then. Interesting. Thanks.

I guess all those flipflops are for address latching and the rest of that funny business up in the corner is for bus timing or something. Neato.
 
I figured maybe it was doing 8-bit bus cycles or something, and address latching because of the way qbus shares data and address lines, before the ROMs put their data on the bus. Just kind of shooting in the dark though. I need to learn more about most of the more innerworking PDP-11 stuff all around. This is all new territory for me.

It would be interesting to disassemble them. I assume that they burned custom proms for whatever particular piece of equipment the system was embedded in. 512x8 bits would be pretty small for some kind of entirely diskless industrial machine though, I'd think.
 
The disassemblies are already out there somewhere for the standard DEC ROMs.

If I remember correctly, they may be in a weird format...

Don's website may be?

Dave
 
https://www.ak6dn.com/PDP-11/M9312/ for M9312 compatible boot PROMs, using 256x4 or 512x4 devices.

The M9312 does a wierd mapping of a 16b word to 4 consecutive 4b nibbles:

03 02 01 08
07 06 05 04

~11 ~10 09 00
15 14 13 ~12


I have no idea if M9312 PROM format is the same as M9400 PROM format.

UPDATE: just looked at the M9400 schematic, completely different way of handling the boot PROM(s).
The four 512x4 PROMs are split horizontally, so bits <3:0> are in PROM#1, <7:4> in PROM#2, etc.
So if you want to change the code, all four PROMs must be regenerated and most likely replaced.
So all four PROMs are one 'set', and must be upgraded/replaced in unison.
I suspect each BOOT PROM set also supported a range of different devices.

M9312 OTOH went with a one device per PROM model, each of the four boot PROMs are independent.
(For the most part; there were some devices that required more code than one PROM could handle,
so they were in multi-prom, usually two, sets. Usually network related devices.).

Also FYI: the boot PROMs on the M9400 are not registered and drive the QBUS data lines directly thru the 8641 bus drivers.
All the discrete single flip flops are involved in the QBUS protocol logic.
 
Last edited:
Trying to figure out how to make a qbus memory interface


Very boring ramble session as I head scratch unproductively.

I forgot about needing to reset all the chip enable latches when the SYNC line is released, too.
 
Alright, so RAM cards. All the ones I have are 16 bits. Which is fine, but iirc I'll have to have a 22-bit memory of at least 1mb if I put the 11/73 card in and get it booting 2.11BSD.

After some head-scratching and reading of various existing designs, I think it would be not-impossibly-hard to put together a memory decoder with 74LS series logic, using LS240s for bus transceivers, LS273s for latches, and a small assortment of gates for decoding. It appears that the only critical timing requirement would be a small delay on the rise of RPLY, to give the data time to stabilize before it is consumed. I think this could be accomplished with an RC circuit into a gate with a schmitt trigger input, or one of those little 8-pin Maxim delay line units if an RC circuit isn't precise enough. With 4 or 5 jumpers, it should be possible to design a card that can take a pair of AS6C62256 32k x 8 SRAMs (for 64k on a 16-bit qbus system), a pair of AS6C1008 (for 256k on an 18-bit system), or 2, 4, 6, or 8 AS6C4008 (for 1, 2, 3, or 4mb on a 22-bit system), all using the same socket footprints.

The most annoying part will be filtering out segment 7 in the address decoding so that the memory does not enable while the IO segment is being accessed.

It would be possible to put all the latching and decoding on a small 5v CPLD, or maybe even a couple 22V10s, but that seems kind of cheaty and too anachronistic. And I guess others who might want to build one might not have a programmer for that stuff.

Those of you who actually know what you are doing (unlike me, lol), does this seem viable?
 
Back
Top