Interested in USB for TURBOchannel (slhci at tc)?

[Felix Deichmann]

Hi,

tinkering with a Lattice CPLD break-out board and a Waveshape SL811HS
USB board showed success: I was able to interface the SL811HS and
TURBOchannel of my DEC 3000/400. Code for "slhci at tc" was easy, as the
slhci driver seems mature (and portable) already.
The CPLD features a TC interface up to 25 MHz, is capable of I/O
transactions and interrupts, and even contains a basic option ROM as
required by TC systems' firmware.
It is a horribly "flying" lab setup with single wires between all the
connectors at the moment (hardly stable of course, but sometimes :)),
but I plan to design a "real" TC option module with custom PCB and even
bulkhead for myself (and others if interested) which will solve all
stability problems I hope.

Do not expect it to be fast, SL811HS is a USB 1.1 controller (12 Mbit/s)
and its 8-bit interface is sub-optimal (and errata-prone). I calculated
SL811HS peak data rate over an optimal (back-to-back) TURBOchannel to be
~1.25 MB/s for 12.5 MHz TC systems, and ~2.08 MB/s for 25 MHz systems.
Actual devices on the bus will show slower results of course.

Is anyone else interested in such a TC-USB option? I could kick-off a
hobbyist maker project of professionally made modules (you would get the
assembled thing with parts soldered to a PCB, CPLD programmed and
bulkhead mounted) then. Costs depend on amount ordered of course, but
even for prototype/smallest volume I see it far below USD $100. I will
not earn a single cent. Otherwise I will build manually for myself only.
So please excuse cross-posting to the three TC-capable platforms (pmax,
alpha, vax). It's a NetBSD special right now :)

More info is and will be available here (doc, pics, code, ...):
http://www.flxd.de/tc-usb/

And the alpha port seems to have really broken bus functions for widths
<= 4 (dense vs. sparse TC space etc.). I will also come up with a patch
for that soon.

Comments and suggestions welcome!

Regards,
Felix

[David Brownlee]

Awesome :)
I would definitely buy at least two at under $100 each, possibly more. As a
non NetBSD aside, I suspect if you can get the right VMS guy interested in
writing a driver for the VMS/VAX then you might suddenly find another happy
(if not huge :) market...

[Felix Deichmann]

Am 03.04.2016 um 10:46 schrieb David Brownlee:
> I would definitely buy at least two at under $100 each, possibly more.
> As a non NetBSD aside, I suspect if you can get the right VMS guy
> interested in writing a driver for the VMS/VAX then you might suddenly
> find another happy (if not huge :) market...

Great, we are approaching a reasonable volume really fast (others
interested wrote off-list)!

VMS support would be so cool, and is possibly not that hard for the
"right guy": USB is already supported for many of the later Alphas of
course, so a USB subsystem and API should be there.
comp.os.vms and its national counterparts could also help in raising
more interest.

I think I will wait for 1 or 2 more weeks, which will also give me time
to finish the PCB design and think about an "ordering process".

Felix

[Maciej W. Rozycki]

On Sun, 3 Apr 2016, David Brownlee wrote:

> I would definitely buy at least two at under $100 each, possibly more. As a
> non NetBSD aside, I suspect if you can get the right VMS guy interested in
> writing a driver for the VMS/VAX then you might suddenly find another happy
> (if not huge :) market...

I could do the Linux side probably, at least the MIPS port. I don't
expect huge interest there however TBH -- 10-15 years ago maybe things
would have been different.

Maciej

[Dave McGuire]

Short and sweet: Put me down for 3-5 of these, depending on the final
price.

Fantastic work!

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA

[Felix Deichmann]

Intermediate result:

I see enough interest for a professionally assembled option already,
which is a success and more than I expected (and even did not ask the
VMS community yet!).

Ordering starts: PayPal deposit of EUR €79 (I'm in Germany...) per piece
+ shipping (EUR €9 worldwide insured for one) is required (*not* to this
e-mail address please). I will write to all who expressed interest
off-list with details, please make sure from *this* e-mail address to
prevent fraud...

Excess money will be refunded individually (or donated to the NetBSD
Foundation if you like) after completion of the project, which is likely
if volume is increased further and/or everything goes as estimated. My
decision for a refund policy is also a reason why common crowdfunding
platforms cannot be used (not allowed), but I see no other practical way
for me.

Deadline is April 17th, 2016. New orders are only possible until then. I
must also reserve the right to cancel the project altogether with your
money refunded.

This is a private sale (or better: collective order) under hobbyists, no
warranty or guarantee. The options will be tested before shipment (in
antistatic bags) of course.

This will also be put on the project site soon, which will document the
progress from now on.

Felix

[Martin Neitzel]

Hi Felix,

> Is anyone else interested in such a TC-USB option?

o/ please sign me up, too.

(5000/240-ish pmax here. Yes, I am aware that ultrix doesn't have
a USB driver stack. Yet.)

Martin

[Tobias Nygren]

On Tue, 5 Apr 2016 19:07:04 +0200
Felix Deichmann <m4j0...@gmail.com> wrote:

> Intermediate result:
>
> I see enough interest for a professionally assembled option already,
> which is a success and more than I expected (and even did not ask the
> VMS community yet!).
>

> Ordering starts: PayPal deposit of EUR ?79 (I'm in Germany...) per piece
> + shipping (EUR ?9 worldwide insured for one) is required (*not* to this

> e-mail address please). I will write to all who expressed interest
> off-list with details, please make sure from *this* e-mail address to
> prevent fraud...
>
> Excess money will be refunded individually (or donated to the NetBSD
> Foundation if you like) after completion of the project, which is likely
> if volume is increased further and/or everything goes as estimated. My
> decision for a refund policy is also a reason why common crowdfunding
> platforms cannot be used (not allowed), but I see no other practical way
> for me.
>
> Deadline is April 17th, 2016. New orders are only possible until then. I
> must also reserve the right to cancel the project altogether with your
> money refunded.
>
> This is a private sale (or better: collective order) under hobbyists, no
> warranty or guarantee. The options will be tested before shipment (in
> antistatic bags) of course.
>
> This will also be put on the project site soon, which will document the
> progress from now on.
>
> Felix

I'll take 5 pieces at this price point but I would like to humbly
request for verilog/vhdl source code to be included with the hardware
and that if possible any unused GPIO pins on the CLPD device be routed
to an unpopulated pin header along with power and gnd so that the
boards may be repurposed and extended for other turbochannel
shenanigans.

Kind regards,
-Tobias

[Felix Deichmann]

2016-04-07 21:29 GMT+02:00 Tobias Nygren <t...@netbsd.org>:
> I'll take 5 pieces at this price point but I would like to humbly
> request for verilog/vhdl source code to be included with the hardware
> and that if possible any unused GPIO pins on the CLPD device be routed
> to an unpopulated pin header along with power and gnd so that the
> boards may be repurposed and extended for other turbochannel
> shenanigans.

Great, a high-roller. :)

The CPLD variant I wanted to use has 100 pins, from which only 64 + 10
"special purpose" are usable as GPIO. Subtract 33 + 5 for TC, 8 + 6
for SL811HS, and around 5 for LEDs and jumpers (LEDs are nice to have
I think, but won't be visible when the enclosure is closed).
Maybe only 8+ GPIOs could be realized. More or much more will require
a larger CPLD (package, macrocells, cost) and seems to shift the scope
of the project severely.

TC provides 12 V and 5 V (I only wanted to use 5 V...). 3.3 V and 1.8
V are also required and obtained from 5 V by LDOs. It's a little
voltage converter board, too. :)
I planned using a (cheaper) two-layer PCB, which can be done when
carefully designed, but routing additional power to your pin header
(you would want all of course...?) can make things ugly quickly. I
will see what I can do. Single test points (you can solder in a single
pin) spread across the PCB for all the voltages are planned anyway for
acceptance testing.

Giving away my VHDL code is a point I still think about. I have my
fights... It is not necessary for people who want USB flat as per the
project's definition, as the CPLD is like just another dedicated IC.
For the people interested in extending the option's original scope, I
understand it would be valuable. But then you could also design your
own board altogether, maybe focus on extendability. TC is no rocket
science, all specs are still available from HP's FTP server and it was
designed as open bus since ever.
I see no problem in providing and maintaining the JED files for the
CPLD. For the source, gimme time.

What I also started writing together with developing the option is
documentation (manual/specification, many details on timings etc.).
This will also be made available of course.

Regards,
Felix

[Tobias Nygren]

On Fri, 8 Apr 2016 09:19:18 +0200
Felix Deichmann <m4j0...@gmail.com> wrote:

> 2016-04-07 21:29 GMT+02:00 Tobias Nygren <t...@netbsd.org>:
> > I'll take 5 pieces at this price point but I would like to humbly
> > request for verilog/vhdl source code to be included with the hardware
> > and that if possible any unused GPIO pins on the CLPD device be routed
> > to an unpopulated pin header along with power and gnd so that the
> > boards may be repurposed and extended for other turbochannel
> > shenanigans.
>
> Great, a high-roller. :)
>
> The CPLD variant I wanted to use has 100 pins, from which only 64 + 10
> "special purpose" are usable as GPIO. Subtract 33 + 5 for TC, 8 + 6
> for SL811HS, and around 5 for LEDs and jumpers (LEDs are nice to have
> I think, but won't be visible when the enclosure is closed).
> Maybe only 8+ GPIOs could be realized. More or much more will require
> a larger CPLD (package, macrocells, cost) and seems to shift the scope
> of the project severely.

This would be plenty of pins to bit-bang to an i2c daughter board
with an environmental monitoring chip, watchdog timer, debug port or
similar, which are the sort of applications I had in mind. I realize you
want to keep cost down :)

[Felix Deichmann]

2016-04-08 9:37 GMT+02:00 Tobias Nygren <t...@netbsd.org>:
> This would be plenty of pins to bit-bang to an i2c daughter board
> with an environmental monitoring chip, watchdog timer, debug port or
> similar, which are the sort of applications I had in mind. I realize you
> want to keep cost down :)

Hm, I could also test out a simple 8-bit GPIO implementation by two
registers (direction + data input/output) in TC address space, if you
like. Would be easy to bit-bang I²C or SPI or both then with another
plethora of options, right? I think we already have a framework in the
code for it.
This could potentially be part of the project right from the start if
it fits into the (CPLD) design, for free. Thanks, great idea!

Re-using timing of the current TC implementation, a 25 MHz TC system
could theoretically achieve a GPIO toggling speed of 25 / 6 = 4.17 MHz
with optimal back-to-back transactions. Not bad!

For the GPIO pin header, I would then go for 2x10, with one row being
8x ground + two voltages, the other row for the GPIOs + two voltages
(3.3 V and 5 V probably most useful). This would also allow connecting
a longer IDC flat ribbon cable with pwr/gnd running over every other
wire. The CPLD can source/sink -4.0/8.0 mA per pin regarding TTL, and
has hysteresis on the inputs, so additional buffers are not necessary
I hope. Default is LVTTL I/O config, 5 V tolerant, which should be
perfect for most applications. As this will be an "expert" connector
of your choice not fitted per default, I would also not provide
additional protection (reverse voltage, overcurrent/-voltage, ESD,
..). Watch out! :)

Felix