Re: Are DEC TK50/TK70 tapes worth hanging onto?

[Ulrich Tagge]

Hi,

I search some time for TK50/TK70 media for my MVII, and 3600 so I'm 
Interested.


By now I have the need for the following tapes, if you have them.

biggest need>>>
- MVII DIAG MAINT TK50
>>>

- MVII DIAG CUST TK50
- VMS V5.5-1 BIN TK50
- VMX XYZ BIN TK50 xx/nn
- VMS LIC KEY BIN TK50
- MICROVMS xyz BIN TK50
- DEC TCP/IP SER VMS xyz TK50

And any other MVII or Microvax 3600 TK70 related Tape ;-).

I know, that there is only a 50% chance, that they are still readable, 
but with view onto my QIC and other old media, it looks like I have some 
luck, in using old tape media.



Many Greetings
Ulrich

RE: Photos from the NWA Auction

[Steve Hatle]

 Original Message 
Subject: Re: Photos from the NWA Auction
From: et...@757.org
Date: Tue, October 18, 2016 6:47 pm
To: "General Discussion: On-Topic and Off-Topic Posts"


> Wonder if anyone got the actual simulators/cockpits? Fun toys but
> won't fit in your average basement...

There were bids on them, hopefully they go to home flight simulator
nerds 
that will entertain us with videos on youtube of them running inside
their 
houses!


--

I was at the facility briefly to help out another lister with prepping
his lot for shipment. The GP4 is being dismantled for scrap. About half
the racks are already empty. 

With a little bit of cash beer money and some wrench work, the panel you
see in IMG_5535 is now in the backseat of my car. It will likely be all
gone by EOD on Friday.

Re: Unibus disk controller with modern storage

[David Bridgham]

On 10/19/2016 06:48 PM, shad wrote:
>
> One of my retrocomputing dream is to design an Unibus universal board,
> probably based on FPGA because of precise timing requirements,
> to emulate one or more disk/tape interfaces, and possibly something more.
> The real storage could be based on SD card

You mean, perhaps, something like this?

http://pdp10.froghouse.org/qsic/html/overview.html

Noel and I started working on this project about a year ago.  I've been
away all summer, working in the wilds in Alaska, so the project stalled
for the last six months.  I'm home now and getting back into normal life
so it's time to restart.  Here's a quick status report on how far we got.

Noel wire-wrapped two prototype boards with the bus drivers and level
converters.  We have those cabled to a ZTEX FPGA module for
development.  I was working on the Verilog in the FPGA.  We got to the
point where we had all the basic QBUS bus cycles working: device
register reads and writes, bus grant, DMA reads and writes, and
interrupt cycles.  We hacked up a quick and dirty RK11 using just
internal FPGA memory for the "disk" storage and wrote some C code to
exercise all those QBUS operations.  It seems solid.  The short video of
the indicator panel on that website above is running that exerciser program.

Where we're sitting now is that the next step is to wire up an SD card
and start writing the Verilog to access it.  It's a little daunting
though not as daunting as implementing the USB protocols in the FPGA. 
I'm hoping that doing the SD card will pave the way for more complex
things like USB.

Dave

Re: Unibus disk controller with modern storage

[Paul Koning]

> On Oct 19, 2016, at 6:48 PM, shad  wrote:
> 
> Hello,
> I read several posts about Unibus disk interfaces and emulation.
> One of my retrocomputing dream is to design an Unibus universal board,
> probably based on FPGA because of precise timing requirements,
> to emulate one or more disk/tape interfaces, and possibly something more.
> The real storage could be based on SD card, so very easy to be moved
> to a PC for imaging and data transfer.
> Probably a low level emulation would be quite easy, while a more complex
> solution (MSCP) could be more difficult.
> The board itself wouldn't be cheap at all, because PCB would be big,
> and because FPGA aren't cheap either.
> Probably it would be anyway cheaper than an MSCP-SCSI, and it would be far 
> more
> flexible.

Actually, Unibus has very straightforward timing.  It certainly should be a 
breeze with an FPGA, but the original designs (nicely spelled out in the back 
of the early Peripherals Handbooks, or later on in the Unibus Handbook) take 
just a handful of MSI ICs.

Yes, a non-MSCP disk would be a good choice.  I'd suggest the Massbus series, 
they are just about as simple as anything and that's where you find the largest 
capacities short of MSCP devices.  And even an RP07 fits comfortably on a small 
SD card.  Or 8 of them, for that matter.  Apart from MSCP, avoid RL emulation 
also.

SD is actually the hardest part, at least the initialization.  If there's off 
the shelf IP that handles that state machine, the rest is simple.  
Alternatively, is CompactFlash still around?  That's just an ATA interface, 
really easy.

How small is the smallest possible Unibus DMA card?  Quad, if I remember right, 
because of where the NPR/NPG wires live?

paul

Re: Unibus disk controller with modern storage

[Eric Smith]

On Wed, Oct 19, 2016 at 4:48 PM, shad  wrote:

> The board itself wouldn't be cheap at all, because PCB would be big,
>

True. From a Chinese vendor such as PCBway, a DEC quad size double-sided
PCB without ENIG (immersion) gold surface finish but without hard-gold edge
fingers costs $15.10 each in quantity 10, and a hex side PCB costs $20.40
each.  However, the ENIG gold is quite thin and won't withstand very many
backplane insertions.  The cheap PCB vendors don't offer hard gold edge
fingers. Jon Elson pointed out that E-TekNet in Arizona does offer hard
gold at better prices than some fab houses, but still a lot more than the
cheap Chinese PCBs.

I prefer NOT to use ENIG, as I find HASL tin-lead better for hand assembly,
though the lead is a problem due to RoHS regulations in much of the world
(but not in USA). I haven't tried HASL lead-free.


> and because FPGA aren't cheap either.
>

Xilinx XC6SLX9-2TQG144C is probably big enough for such things, and only
costs $16.52 in quantity 1 from Digi-Key.  It's in a TQFP, so not *too*
difficult to deal with. It has essentially 11,440 logic cells (5-LUT with
FF)*,  32 block RAMs of 18 Kbits each, and 102 3.3V I/O pins. It's not 5V
tolerant, but no modern parts are. 5V tolerance can be achieved in many
cases by the use of series resistors, but I like using the TI
SN74CBTD3861DGVR bus switch/voltage clamp, which can make 10 I/O pins 5V
tolerant at a cost of $0.62 in quantity 1. The bus switch is advantageous
over series resistors because it doesn't add much series resistance to pins
that are being used as outputs, and it has a maximum propagation delay of
0.25ns.

If you need more FPGA capability, the XC7A15T-1FTG256C has substantially
more resources, and costs $25.69 in quantity 1.  It's in a 256 ball BGA, so
somewhat harder to deal with, and needs at least a four layer board,
possibly even six layer.  However, it has 20,800 logic cells (5-LUT with
FF), 25 block RAMs of 36 Kbits each, and 170 3.3V I/O pins.

If you need more resources than that, it turns out that the XC7A15T,
XC7A35T, and XC7A50T are actually all the same die, just factor-programmed
with a different device ID. The 35T and 50T have double and triple the
logic cells and block RAMs of the 15T. The Vivado FPGA toolchain
artificially limits the resource usage of the two smaller parts, but
doesn't actually restrict which specific logic cells and block RAMs are
used, which means that the 15T and 35T have silicon that passes the factory
testing for ALL resources, not just 1/3 or 2/3 of them. It's been verified
that one can change the device ID in the bitstream, disable bitstream CRC
checking, and use the smaller part as a larger part. I don't like disabling
the CRC, because it serves to protect the FPGA from damage if the bitstream
has been corrupted, so I wrote a program that can both change the device ID
and recompute the CRC. I don't yet have a board with a 15T or 35T to test
with, but I'll release the program as open source once I do.

Because going to a 4 layer or 6 layer board is quite expensive when the
board size is large, e.g., DEC quad or hex size, I think it makes sense to
put the FPGA, its configuration flash, voltage regulators, and the bus
switches for 5V tolerance on a daughterboard. I've been working on such a
design, with two 96-pin DIN connectors for connection to the main board,
and at least 160 GPIOs available. The main board can then be just
double-sided, and possibly even 100% through-hole, for people that don't
want to hand-assemble boards with surface-mount components. The drawback is
that it will occupy more than one backplane slot due to the height.

There's still the problem that no current production bus interface ICs meet
Unibus, Qbus, or Omnibus specifications. Surplus DS8641 chips are
technically the best choice. With modern chips, it's necessary to use
separate drivers and receivers, and still difficult to meet the full specs.
Compromising the specs is possible but may make things unreliable in a
large system (multiple backplanes with cables, and many other cards).

Eric

* Xilinx has some other confusing definition of a "logic cell" for
marketing purposes, which is not the same as a LUT+FF. Oddly enough, their
marketing logic cell count is actually lower than a sensible accounting,
which is the opposite of how FPGAs used to be rated in exaggerated gate
counts, which we derided as "marketing gates".

The 6-series and 7-series actually have 6-LUTs with 2 FF each, but they can
be used as two 5-LUTs with 1 FF each, which is how I count them for
assessing the FPGA's logic capacity.

Re: Unibus disk controller with modern storage

[Fritz Mueller]

On Oct 19, 2016 6:48 PM, "shad"  wrote

Hello,
I read several posts about Unibus disk interfaces and emulation.
One of my retrocomputing dream is to design an Unibus universal board,
probably based on FPGA because of precise timing requirements,
to emulate one or more disk/tape interfaces, and possibly something more.
The real storage could be based on SD card, so very easy to be moved
to a PC for imaging and data transfer.
Probably a low level emulation would be quite easy, while a more complex
solution (MSCP) could be more difficult.
The board itself wouldn't be cheap at all, because PCB would be big,
and because FPGA aren't cheap either.
Probably it would be anyway cheaper than an MSCP-SCSI, and it would be far
more
flexible.


A good way to go on this might be just a small paddle card with Unibus 
drivers, level conversion, and some shift-register chains, which could 
then be interfaced easily to any number of off-the-shelf FPGA 
prototyping boards (the latter having the advantage of being quite 
cheap, with many integrated peripherals like ethernet, SD slots, USB 
serial, etc. and having tool chain support out of the box).


I've seen a few projects started like this out in the wilds, but none 
seem to have made it past the debug stage.


It would be super useful -- you could emulate all sorts of peripherals 
as well as memory, or you could configure it as a Unibus analyzer, or 
emulate a CPU to debug peripherals.


--FritzM.

Re: Looking for HP98034 / HP9895 ROM images

[Curious Marc]

If you have not gotten the HP 98034 ROM image yet, I can try to dump mine when 
I'm back from travel next week. I suspect you want the "revised" version, which 
is the interface that works with the HP 9895. I have both versions.
Craig, I'd be interested in your 9895 ROM dump and reverse engineering info too.
Marc

> On Oct 18, 2016, at 1:14 PM, Craig Ruff  wrote:
> 
> 
>> On Oct 18, 2016, at 11:00 AM, cctech-requ...@classiccmp.org wrote:
>> 
>> does anyone of you happen to have the images of the firmware ROM of
>> HP98034 module and/or of the HP9895 disk drive, please?
> 
> I’ve sent F.Ulivi the contents of the single ROM version from my 9895A, along 
> with some preliminary reverse engineering work on the contents that I’ve done 
> in conjunction with Eric Smith.