[cctalk] Re: DEC Unibus variants
The why not use a UniBone comment has merit, what will your (FPGA) > implementation add ? > Well, I know the Unibone! Surely is a very capable system for emulation of older hardware and interfaces. Also performances are good as far as I understand (I don't have one). I have the idea of extending the concept of Unibone. The new design shall be modular, composed by: - a main board hosting the SoM and common interfaces (Ethernet, SD, USB, console) - a bus module for specific bus / machine: support could be added for DEC / Data General / other? - an interchangeable interface module for an hardware device (SMD, Pertec, floppy, RX1/2, RL01/02, other). Any kind of interface could be supported, also for example ADC, DAC, maybe video to some limits...) If you have main module and bus module, you have a similar solution to Unibone / Qbone. However if you need to change bus type, you need to swap only the bus adapter (cheaper). If you have main and interfaces modules, you can control physical devices directly, and do anything with it. For example, you can dump / restore the content of a SMD disk at bit level, no need to know the controller format, etc. Similar to Kyroflux for floppy, but MUCH faster! Alternatively, you could also emulate the device at low level (for example a generic SMD disk). If you have a set of main, bus and interface modules, you can do anything as above, plus you can emulate a controller for a specific machine for a specific device. That said, implementing "anything" would be an infinite effort, but the platform is flexible, so support could be added step-by-step. So why an FPGA? A programmable logic can implement a true digital circuit, where the PRUs in the BeagleBone are processors. This means that in an FPGA the time is always precisely determined by a clock, in PRUs it is affected by the software execution. This means that a PRU can work quite well on an asynchronous bus, provided that sample rate is sufficient, even if not constant. But for a fast synchronous interface, i.e. when time is determined by an external clock, often embedded with data, no software approach can work steadily in my opinion. One thing is true: programming an FPGA is designing a netlist, not developing a software. It can be very hard to debug sometimes, because the approach is more similar to repairing an old board with a Logic Analyzer than perform debugging in software: it's a circuit in a chip, there no step-by-step execution! Nevertheless: I'm a quite good electronic engineer, highly experienced with digital logic and FPGA, so the hardware design wouldn't be a problem. Just a matter of time. Nowadays a SoM with a smaller AMD Zynq7010/7020 (a system-on-chip including an FPGA, plus dual core CPU, lot of peripherals) doesn't cost a lot, and have a great usage flexibility. Also brute computing power is superior to older BB. Why not try? I'm open to your comments. As for the UNIBUS unobtainable transceivers: I think the best solution is to use AM26S10 for drivers, and an LVC logic powered at 3.3v for receivers. Both are active parts costing nuts. I would try this approach. Andrea
[cctalk] Wanted : Philips PSU-B3 (or -B4?) power supply for the P3800
I am working on a Philips P3800 computer, about 40 years old. It's a multiprocessor Turbodos machine, a mix of Z80's and 80186's The main problem is that I only have half the power supply. I have the PSU-M3 battery-backed memory supply, but not the logic supply. This I believe to be a PSU-B3 module, although from the circuit diagrams I have, I think a PSU-B4 would work. Outputs are +5V, +12V, -12V, +24V and maybe -5V. There's also remote on/off control, so it's not trivial to use a different power supply The base board is a 233*160mm double eurocard wth a 96 pin 0.1" pitch DIN41612 connector for the outputs and a 32 pin 0.2" pitch DIN41612 connector for the mains input. There is probably another board stacked on top of it (connected only to the baseboard, not to the backplane) and there may be a metal plate on top of the lot. Please let me know if you have any idea where to find one. -tony
[cctalk] Re: Wanted : Philips PSU-B3 (or -B4?) power supply for the P3800
Tony Duell wrote: I am working on a Philips P3800 computer, about 40 years old. It's a multiprocessor Turbodos machine, a mix of Z80's and 80186's There is some P3500/3800 documentation online, including power supplies (Netzteile) at: https://electrickery.nl/comp/divcomp/doc/index.html Not exactly what you asked for, but related. Fred Jan
[cctalk] Re: DEC Unibus variants
On 3/29/25 21:05, Ethan Dicks via cctalk wrote: On Sat, Mar 29, 2025 at 9:46 PM Jon Elson via cctalk wrote: In the "old" days, such as the 1970's, pretty much any DEC-manufactured peripheral was supplied as a bunch of cards that plugged into a specific backplane section, generally 9 slots, I think. A couple double-wide slots were for the Unibus in and out connectors. There were plenty of 9-slot system unit peripherals, but there were also 4-slot system unit peripherals in the early days. Yes, you certainly are correct. It has been SUCH a long time since I worked on any Unibus systems... Jon
[cctalk] DEC bus transceivers (was: DEC Unibus variants)
On 3/29/25 7:29 PM, Martin Bishop via cctalk wrote: The why not use a UniBone comment has merit, what will your (FPGA) implementation add ? I'm not shad but I've also been working on a somewhat similar FPGA-based board called the USIC / QSIC. We started working on it before the UniBone but have been slower to come to completion. A lot slower. Maybe there's no point to it anymore but I keep poking along on the design anyway. If you solve the (near) unobtanium OC driver / receiver problem - I for one will be all ears Ah, yeah, this problem. At one point in the QSIC project I started doodling up circuits to deal with this so we wouldn't have to use up NOS bus transceivers, wouldn't have to deal with the 5V/3.3V conversion for the FPGA, and would be all surface-mount parts to make automated fabrication easier (I never found any DS3662s). A comparator for the receiver with just the right amount of hysteresis. Have to look around a little to find one that's fast enough to meet the 35 ns requirement but they're out there. And then the driver is just a transistor and a capacitor on the gate/base to limit the slew rate. Shouldn't be all that hard to design, right? Might want to go with a constant current source to charge/discharge that capacitor to make it a proper trapezoid waveform though I don't know that that's really needed. This all needs testing and I was going to make up a little test board with both my circuit and a DS8641 that could be plugged into different busses to have a look at the waveforms that come out. I looked up the pinouts for SPC, MUD, and QBUS so I could design a board that would equally work in all three. I was talked out of this idea though. We were doing enough new already with the whole rest of the board and from our prototype QSIC we knew that the DS8641s with level converters would work so it made sense to stick with that. Still, I think about this idea from time to time. In the small chance that anyone is interested, I just now threw my circuit ideas up on GitHub. Remember, this is doodling. I can see three generations of ideas in there, as I thought through different possibilities. I also had this idea about switchable, active termination so that's in there too, though I'm now less sure that's a good idea. https://github.com/dabridgham/DEC-Bus-Transceiver Dave
[cctalk] Re: DEC bus transceivers (was: DEC Unibus variants)
David You will have seen my response to shadooo / Andreas. Occasional NOS in small quantities excepted, I'm also unaware of slow transition rate drivers available for purchase. The DS8641 DS3662 DS 3682 are to my knowledge all unobtanium. Your driver design sketches and comments are substantially on the money. Thank you for making them public. However, an effective implementation in discrete components would not be "tiny" - even with 0402 passives and a pick / place machine on the case. Perhaps someday, someone will do a Q/U driver on a multi project wafer - or is that unafordable. Or, to fly another kite - what about FPAA (Field Programmable Analog Array) components ? Regarding comparators, as receivers, the TLV3501 (for example) is a 5v / 5 ns part - add hysteresis and set the H/L thresholds using resistors. Certainly receives OC signals for me. Should you make further progress very interested to hear of it Best Regards Martin -Original Message- From: David Bridgham via cctalk [mailto:cctalk@classiccmp.org] Sent: 30 March 2025 14:59 To: Martin Bishop via cctalk Cc: David Bridgham Subject: [cctalk] DEC bus transceivers (was: DEC Unibus variants) On 3/29/25 7:29 PM, Martin Bishop via cctalk wrote: > The why not use a UniBone comment has merit, what will your (FPGA) > implementation add ? I'm not shad but I've also been working on a somewhat similar FPGA-based board called the USIC / QSIC. We started working on it before the UniBone but have been slower to come to completion. A lot slower. Maybe there's no point to it anymore but I keep poking along on the design anyway. > If you solve the (near) unobtanium OC driver / receiver problem - I > for one will be all ears Ah, yeah, this problem. At one point in the QSIC project I started doodling up circuits to deal with this so we wouldn't have to use up NOS bus transceivers, wouldn't have to deal with the 5V/3.3V conversion for the FPGA, and would be all surface-mount parts to make automated fabrication easier (I never found any DS3662s). A comparator for the receiver with just the right amount of hysteresis. Have to look around a little to find one that's fast enough to meet the 35 ns requirement but they're out there. And then the driver is just a transistor and a capacitor on the gate/base to limit the slew rate. Shouldn't be all that hard to design, right? Might want to go with a constant current source to charge/discharge that capacitor to make it a proper trapezoid waveform though I don't know that that's really needed. This all needs testing and I was going to make up a little test board with both my circuit and a DS8641 that could be plugged into different busses to have a look at the waveforms that come out. I looked up the pinouts for SPC, MUD, and QBUS so I could design a board that would equally work in all three. I was talked out of this idea though. We were doing enough new already with the whole rest of the board and from our prototype QSIC we knew that the DS8641s with level converters would work so it made sense to stick with that. Still, I think about this idea from time to time. In the small chance that anyone is interested, I just now threw my circuit ideas up on GitHub. Remember, this is doodling. I can see three generations of ideas in there, as I thought through different possibilities. I also had this idea about switchable, active termination so that's in there too, though I'm now less sure that's a good idea. https://github.com/dabridgham/DEC-Bus-Transceiver Dave
[cctalk] Re: DEC Unibus variants
Hi shad / Andrea Thank you for the exposition of the merits of FPGA implementations for Unibus and Qbus machines; it was cheeky of me to pose the question. Regarding cost savings from reusing the main module I suspect the cost of a Zynq module would be much less than that of the bus adapter. However, there are of course infrastructure and programming savings from commonality. Additionally, obtaining sufficient 3v3 IO may be a constraint and there remains the 3v3/5v interfacing issue. However, fairly cheap Zynq 20 boards with lots of 3v3 IO are available, see eg https://www.aliexpress.com/item/1005005779045608.html - the date codes etc are (of course) obscured on the delivered boards. A PDP-11 will fit on a Zynq 10 SoC, at least my 11/45 -MUL/DIV/ASH(C) -MMU -FPU does; I use it as an embedded processor, for things below the dignity of the SoCs PS. 28 kiWd of main memory can be provided by BRAM (a memory cycle time of 10 ns is practical), and as it is double ported its very easy to peek over Axi from the PS. Also, you can hook up a Zynq logic analyser for tracing execution. For the generality you propose, I should think a microcoded platform would be appropriate, a 16 bit mill with a suitable sequencer would probably emulate any 1970's 16 bit mini or peripheral. IIRC numerous PDP-11 implementations used microcode : eg 11/20, 11/40, T-11, etc. However, microcode is of course software (which you deprecate) but so one could argue are the state machines which populate the bulk of contemporary FPGA logic. You mention the difficulty of handling externally clocked data streams. I shall agree that this is a hardware task. In FPGA / SoC work it is invariably addressed by synchronising external signals with internal processing clocks; perhaps at the edge, perhaps at shift reqister read out. But it has to be done or metastability will have its way. A very interesting question is how well "features" like the BBB PRU implement this necessary logic. You are quite correct that the Am26S10 devices are probably the best "off the shelf" driver option. However, given their transition times, they possibly require quite a bit of house training for U&Qbus use. Fortunately, not ground I need to tread. And, yes it is certainly worth a try. One plea, don't do a DG Nova 2; never have I been provided with a worse mini ... Best Regards Martin -Original Message- From: shad via cctalk [mailto:cctalk@classiccmp.org] Sent: 30 March 2025 10:16 To: General Discussion: On-Topic and Off-Topic Posts Cc: shad Subject: [cctalk] Re: DEC Unibus variants The why not use a UniBone comment has merit, what will your (FPGA) > implementation add ? > Well, I know the Unibone! Surely is a very capable system for emulation of older hardware and interfaces. Also performances are good as far as I understand (I don't have one). I have the idea of extending the concept of Unibone. The new design shall be modular, composed by: - a main board hosting the SoM and common interfaces (Ethernet, SD, USB, console) - a bus module for specific bus / machine: support could be added for DEC / Data General / other? - an interchangeable interface module for an hardware device (SMD, Pertec, floppy, RX1/2, RL01/02, other). Any kind of interface could be supported, also for example ADC, DAC, maybe video to some limits...) If you have main module and bus module, you have a similar solution to Unibone / Qbone. However if you need to change bus type, you need to swap only the bus adapter (cheaper). If you have main and interfaces modules, you can control physical devices directly, and do anything with it. For example, you can dump / restore the content of a SMD disk at bit level, no need to know the controller format, etc. Similar to Kyroflux for floppy, but MUCH faster! Alternatively, you could also emulate the device at low level (for example a generic SMD disk). If you have a set of main, bus and interface modules, you can do anything as above, plus you can emulate a controller for a specific machine for a specific device. That said, implementing "anything" would be an infinite effort, but the platform is flexible, so support could be added step-by-step. So why an FPGA? A programmable logic can implement a true digital circuit, where the PRUs in the BeagleBone are processors. This means that in an FPGA the time is always precisely determined by a clock, in PRUs it is affected by the software execution. This means that a PRU can work quite well on an asynchronous bus, provided that sample rate is sufficient, even if not constant. But for a fast synchronous interface, i.e. when time is determined by an external clock, often embedded with data, no software approach can work steadily in my opinion. One thing is true: programming an FPGA is designing a netlist, not developing a software. It can be very hard to debug sometimes, because the approach is more similar to repairing an o
[cctalk] Re: DEC bus transceivers (was: DEC Unibus variants)
https://forum.vcfed.org/index.php?threads/unibus-qbus-alternative-driver-chips.1243045/ Found on my travels - should have been attached to my previous eMail My summary is "no easy answer" Martin -Original Message- From: Martin Bishop via cctalk [mailto:cctalk@classiccmp.org] Sent: 30 March 2025 22:44 To: General Discussion: On-Topic and Off-Topic Posts Cc: Martin Bishop Subject: [cctalk] Re: DEC bus transceivers (was: DEC Unibus variants) David You will have seen my response to shadooo / Andreas. Occasional NOS in small quantities excepted, I'm also unaware of slow transition rate drivers available for purchase. The DS8641 DS3662 DS 3682 are to my knowledge all unobtanium. Your driver design sketches and comments are substantially on the money. Thank you for making them public. However, an effective implementation in discrete components would not be "tiny" - even with 0402 passives and a pick / place machine on the case. Perhaps someday, someone will do a Q/U driver on a multi project wafer - or is that unafordable. Or, to fly another kite - what about FPAA (Field Programmable Analog Array) components ? Regarding comparators, as receivers, the TLV3501 (for example) is a 5v / 5 ns part - add hysteresis and set the H/L thresholds using resistors. Certainly receives OC signals for me. Should you make further progress very interested to hear of it Best Regards Martin -Original Message- From: David Bridgham via cctalk [mailto:cctalk@classiccmp.org] Sent: 30 March 2025 14:59 To: Martin Bishop via cctalk Cc: David Bridgham Subject: [cctalk] DEC bus transceivers (was: DEC Unibus variants) On 3/29/25 7:29 PM, Martin Bishop via cctalk wrote: > The why not use a UniBone comment has merit, what will your (FPGA) > implementation add ? I'm not shad but I've also been working on a somewhat similar FPGA-based board called the USIC / QSIC. We started working on it before the UniBone but have been slower to come to completion. A lot slower. Maybe there's no point to it anymore but I keep poking along on the design anyway. > If you solve the (near) unobtanium OC driver / receiver problem - I > for one will be all ears Ah, yeah, this problem. At one point in the QSIC project I started doodling up circuits to deal with this so we wouldn't have to use up NOS bus transceivers, wouldn't have to deal with the 5V/3.3V conversion for the FPGA, and would be all surface-mount parts to make automated fabrication easier (I never found any DS3662s). A comparator for the receiver with just the right amount of hysteresis. Have to look around a little to find one that's fast enough to meet the 35 ns requirement but they're out there. And then the driver is just a transistor and a capacitor on the gate/base to limit the slew rate. Shouldn't be all that hard to design, right? Might want to go with a constant current source to charge/discharge that capacitor to make it a proper trapezoid waveform though I don't know that that's really needed. This all needs testing and I was going to make up a little test board with both my circuit and a DS8641 that could be plugged into different busses to have a look at the waveforms that come out. I looked up the pinouts for SPC, MUD, and QBUS so I could design a board that would equally work in all three. I was talked out of this idea though. We were doing enough new already with the whole rest of the board and from our prototype QSIC we knew that the DS8641s with level converters would work so it made sense to stick with that. Still, I think about this idea from time to time. In the small chance that anyone is interested, I just now threw my circuit ideas up on GitHub. Remember, this is doodling. I can see three generations of ideas in there, as I thought through different possibilities. I also had this idea about switchable, active termination so that's in there too, though I'm now less sure that's a good idea. https://github.com/dabridgham/DEC-Bus-Transceiver Dave
[cctalk] Re: DEC Unibus variants
On Sun, Mar 30, 2025 at 11:06 AM Jon Elson wrote: > On 3/29/25 21:05, Ethan Dicks wrote: > > On Sat, Mar 29, 2025 at 9:46 PM Jon Elson wrote: > >> In the "old" days, such as the 1970's, pretty much any > >> DEC-manufactured peripheral was supplied as a bunch of cards > >> that plugged into a specific backplane section, generally 9 > >> slots, I think. A couple double-wide slots were for the > >> Unibus in and out connectors. > > There were plenty of 9-slot system unit peripherals, but there were > > also 4-slot system unit peripherals in the early days. I also remembered a couple other 4-slot system unit peripherals I have: RK11-D VT11 Probably the most common 9-slot system unit devices I've encountered are: RK611 (which happens to have a couple of available SPC slots) DH11 RH11 But there are many of both sizes. Cheers, -ethan
[cctalk] Re: DEC bus transceivers (was: DEC Unibus variants)
I used to design UNIBUS bards in the day. I recall that the 8T26 was a good substitute and there are some pieces of them on ebay. Marc Howard On Sun, Mar 30, 2025 at 6:55 PM Martin Bishop via cctalk < cctalk@classiccmp.org> wrote: > > https://forum.vcfed.org/index.php?threads/unibus-qbus-alternative-driver-chips.1243045/ > > Found on my travels - should have been attached to my previous eMail > > My summary is "no easy answer" > > Martin > > -Original Message- > From: Martin Bishop via cctalk [mailto:cctalk@classiccmp.org] > Sent: 30 March 2025 22:44 > To: General Discussion: On-Topic and Off-Topic Posts < > cctalk@classiccmp.org> > Cc: Martin Bishop > Subject: [cctalk] Re: DEC bus transceivers (was: DEC Unibus variants) > > David > > You will have seen my response to shadooo / Andreas. > > Occasional NOS in small quantities excepted, I'm also unaware of slow > transition rate drivers available for purchase. The DS8641 DS3662 DS 3682 > are to my knowledge all unobtanium. > > Your driver design sketches and comments are substantially on the money. > Thank you for making them public. However, an effective implementation in > discrete components would not be "tiny" - even with 0402 passives and a > pick / place machine on the case. Perhaps someday, someone will do a Q/U > driver on a multi project wafer - or is that unafordable. Or, to fly > another kite - what about FPAA (Field Programmable Analog Array) components > ? > > Regarding comparators, as receivers, the TLV3501 (for example) is a 5v / 5 > ns part - add hysteresis and set the H/L thresholds using resistors. > Certainly receives OC signals for me. > > Should you make further progress very interested to hear of it > > Best Regards > > Martin > > -Original Message- > From: David Bridgham via cctalk [mailto:cctalk@classiccmp.org] > Sent: 30 March 2025 14:59 > To: Martin Bishop via cctalk > Cc: David Bridgham > Subject: [cctalk] DEC bus transceivers (was: DEC Unibus variants) > > On 3/29/25 7:29 PM, Martin Bishop via cctalk wrote: > > The why not use a UniBone comment has merit, what will your (FPGA) > implementation add ? > > > I'm not shad but I've also been working on a somewhat similar > FPGA-based board called the USIC / QSIC. We started working on it before > the UniBone but have been slower to come to completion. A lot slower. > Maybe there's no point to it anymore but I keep poking along on the design > anyway. > > > > If you solve the (near) unobtanium OC driver / receiver problem - I > > for one will be all ears > > > Ah, yeah, this problem. At one point in the QSIC project I started > doodling up circuits to deal with this so we wouldn't have to use up NOS > bus transceivers, wouldn't have to deal with the 5V/3.3V conversion for the > FPGA, and would be all surface-mount parts to make automated fabrication > easier (I never found any DS3662s). A comparator for the receiver with > just the right amount of hysteresis. Have to look around a little to find > one that's fast enough to meet the 35 ns requirement but they're out > there. And then the driver is just a transistor and a capacitor on the > gate/base to limit the slew rate. Shouldn't be all that hard to design, > right? Might want to go with a constant current source to charge/discharge > that capacitor to make it a proper trapezoid waveform though I don't know > that that's really needed. > > This all needs testing and I was going to make up a little test board with > both my circuit and a DS8641 that could be plugged into different busses to > have a look at the waveforms that come out. I looked up the pinouts for > SPC, MUD, and QBUS so I could design a board that would equally work in all > three. > > I was talked out of this idea though. We were doing enough new already > with the whole rest of the board and from our prototype QSIC we knew that > the DS8641s with level converters would work so it made sense to stick with > that. > > Still, I think about this idea from time to time. In the small chance > that anyone is interested, I just now threw my circuit ideas up on GitHub. > Remember, this is doodling. I can see three generations of ideas in there, > as I thought through different possibilities. I also had this idea about > switchable, active termination so that's in there too, though I'm now less > sure that's a good idea. > > https://github.com/dabridgham/DEC-Bus-Transceiver > > Dave > >
[cctalk] Re: DEC Unibus variants
Da11-f unibus window is 4 slots and has two complete unibuses (I have one) On March 30, 2025 6:17:05 PM CDT, Ethan Dicks via cctalk wrote: >On Sun, Mar 30, 2025 at 11:06 AM Jon Elson wrote: >> On 3/29/25 21:05, Ethan Dicks wrote: >> > On Sat, Mar 29, 2025 at 9:46 PM Jon Elson wrote: >> >> In the "old" days, such as the 1970's, pretty much any >> >> DEC-manufactured peripheral was supplied as a bunch of cards >> >> that plugged into a specific backplane section, generally 9 >> >> slots, I think. A couple double-wide slots were for the >> >> Unibus in and out connectors. >> > There were plenty of 9-slot system unit peripherals, but there were >> > also 4-slot system unit peripherals in the early days. > >I also remembered a couple other 4-slot system unit peripherals I have: > > RK11-D > VT11 > >Probably the most common 9-slot system unit devices I've encountered are: > > RK611 (which happens to have a couple of available SPC slots) > DH11 > RH11 > >But there are many of both sizes. > >Cheers, > >-ethan
[cctalk] Re: DEC bus transceivers (was: DEC Unibus variants)
Does anyone have a list of what boards they were used on? I do have some boards I'm planning or recycling (I know, I shouldn't say that, especially here, but most are common boards nobody uses anymore.) I haven't looked at the IPBs yet, but did plan on pulling some of the chips. On Sun, Mar 30, 2025 at 9:59 AM David Bridgham via cctalk < cctalk@classiccmp.org> wrote: > On 3/29/25 7:29 PM, Martin Bishop via cctalk wrote: > > The why not use a UniBone comment has merit, what will your (FPGA) > implementation add ? > > > I'm not shad but I've also been working on a somewhat similar > FPGA-based board called the USIC / QSIC. We started working on it > before the UniBone but have been slower to come to completion. A lot > slower. Maybe there's no point to it anymore but I keep poking along on > the design anyway. > > > > If you solve the (near) unobtanium OC driver / receiver problem - I for > one will be all ears > > > Ah, yeah, this problem. At one point in the QSIC project I started > doodling up circuits to deal with this so we wouldn't have to use up NOS > bus transceivers, wouldn't have to deal with the 5V/3.3V conversion for > the FPGA, and would be all surface-mount parts to make automated > fabrication easier (I never found any DS3662s). A comparator for the > receiver with just the right amount of hysteresis. Have to look around > a little to find one that's fast enough to meet the 35 ns requirement > but they're out there. And then the driver is just a transistor and a > capacitor on the gate/base to limit the slew rate. Shouldn't be all > that hard to design, right? Might want to go with a constant current > source to charge/discharge that capacitor to make it a proper trapezoid > waveform though I don't know that that's really needed. > > This all needs testing and I was going to make up a little test board > with both my circuit and a DS8641 that could be plugged into different > busses to have a look at the waveforms that come out. I looked up the > pinouts for SPC, MUD, and QBUS so I could design a board that would > equally work in all three. > > I was talked out of this idea though. We were doing enough new already > with the whole rest of the board and from our prototype QSIC we knew > that the DS8641s with level converters would work so it made sense to > stick with that. > > Still, I think about this idea from time to time. In the small chance > that anyone is interested, I just now threw my circuit ideas up on > GitHub. Remember, this is doodling. I can see three generations of > ideas in there, as I thought through different possibilities. I also > had this idea about switchable, active termination so that's in there > too, though I'm now less sure that's a good idea. > > https://github.com/dabridgham/DEC-Bus-Transceiver > > Dave > >
