I?ve recently acquired a rare complete set of 10 TRS-XENIX 1.0 Development System floppy disks. I?ve done quite a bit of 8? disk imaging so I'm fairly comfortable using ImageDisk, cleaning disk heads, etc. I?ve run into a scenario with these disks that I have not had to deal with before. Since this is the only complete set of this software I?ve ever seen, I need to be really careful with how I proceed. The media itself looks pretty good. No scratches, no blotches. However, on a number of disks the sleeves have warped. I am afraid that this will damage the media when I spin them up. I?m thinking of cutting open the sleeves and placing the media in new 8? floppy sleeves. I?ve also heard about baking the media, although I?ve never tried this and not sure of its value.
What are your thoughts on how to proceed?
Hi folks,
I've got my VAX3800 resuscitated after many years in limbo and two of the
four RF71s in there have gone bad. Has anyone tried swapping the controller
boards between drives? Is it just a matter of letting the drive
auto-calibrate or do I need to SET HOST onto the controller and tell it it's
on a different HDA...
Here it is in a happier mood shortly after first powerup:
http://www.binarydinosaurs.co.uk/VAX3800.jpg
(not my best LK201 keyboard but it was the closest :) )
--
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?
I don't see these manuals online at either bitsavers.org or hpmuseum.net.
Does anyone have copies of them available?
12044-90001 HDLC Direct Connect Interface Hardware Reference Manual
(12044A for A/L-Series)
12825-90001 HDLC Direct Connect Interface Hardware Reference Manual
(12825A for M/E/F-Series)
I have more than one HP-1000 CPU. Just curious what it would take to
connect some of them together running 91750A DS/1000-IV software.
So, I'm winding up to boot Unix V6 from an RX02 floppy. So I need two things:
- Details of how DEC ROM bootstraps boot from RX02's. I vaguely recall seeing
documentation of this somewhere (e.g. which sectors it loads, etc), but now I
can't find it. Don North has dumps of the RX02 ROM's, but I'm too lazy to read
through the code and figure out how they work. Is there some documentation
which covers it? I did a quick Google search, but if there is anything out
there, my Google-fu was inadequate.
- Did anyone ever do an RX02 driver for the V6 disk bootstrap? (Well, I guess
a V7 driver would work, too.) Note: what I need is _not_ either i) the Unix OS
driver for the RX02 (I found one of those already), or ii) a driver for the v7
standalone second-stage bootstrap (which would probably be in C). The thing
I'm looking for would be called rx.s, or something like that. Yes, I could
write it, but again, I'm lazy! :-)
Noel
I have uploaded a set of disk images from My Compupro system with an 8085
and 8086 card, plus regular z80. The thread starts a number of years ago,
but today I just updated, at the bottom, to include images of the disks I
have for the system.
Some interesting concurrent CPM and DOS stuff, not sure if this is really
MS DOS 1.25 or not, never got it to work on my system. I'd love to see
someone else make it work.
Thread:
http://vintagecomputer.net/browse_thread.cfm?id=265
Just get the IMD images:
http://vintagecomputer.net/disk_images/COMPUPRO/
As always, thanks Dave Dunfield, please use the images with the proper
licenses, etc.
Bill
SEEKING GOOD ILLUSTRATIVE MATERIAL ON IBM ADD ON BOXES GOT A STACK..
So need hi res scans of catalogs brochures etc showing them all
stacked and what when with what.
We had an early IBM pc for a while....but never this many add on boxes!
I am lost... Remember back in the 80s I sold HP stuff... any
help and guidance appreciated to make this all come together into
something nice visually!
thanks Ed Sharpe archivist for SMECC couryhouse at aol.com
Re: DEC bus transceivers
> From: allison
> Actually since about 1987 I've used about 1200 pieces of the 8641 alone
> repairing boards at the commercial level.
Well, that's over almost 30 years - and your total from that period is about
4% of the remaining stock (and in a commercial operation, to boot, not
hobbyist)...
> If you going to build a board or three maybe even 20 its not a big deal
> but its not a reliable source of predictable quality.
Sure, but try looking at it from our perspective: we either use an
out-of-production part, or have to design something (almost certainly from
discretes) that meets those specs; and we actually looked at the latter (viz.
Dave B's design). However, after some pondering, and taking everything
(including all the below) into account, we decided to go with the original
chips, since they were still sorta available.
Which is why both we and Guy have stocked up on them, at the start of the
process: we don't want to crank out boards designed for a certain part, and
then not be able to get the out-of-production parts the boards were designed
to use.
If we were designing something for serious production, that wouldn't be an
option, but for limited-volume hobbyist use, it is. The choice of an
out-of-production part does have a down-side, but it's minor (and mostly
alleviated by the pre-buying), and the other options were (in overall sum)
worse.
> If you get to the bridge your talking redesign in reality or an
> expensive buy from unreliable source then testing them in bulk.
But, but... I'm _already_ buying them from unreliable sources, then testing
them! :-)
But to be serious - if the demand for QSIC's, etc, runs the well of DS8641's
dry, yes, we'll probably have to re-design. In other words, we'd be right
where we'd be today if we decided not to use out-out-production parts.
Noel
Hi all --
Just wanted to let you guys know that a new version of the Xerox Alto emulator I've been working on at the LCM+L has been released; V1.1 of ContrAlto can be downloaded from: http://www.livingcomputers.org/Join/Online-Systems.aspx. At this point, the vast majority of software appears to be working properly, if you do run into any issues please let me know!
ContrAlto is open source, so if you want to hack on it the source is available on our GitHub site at https://github.com/livingcomputermuseum/ContrAlto.
Thanks!
- Josh
Many of us maintain large collections of bits that we'd like to preserve over a long time, and distribute, replicate, and migrate via unreliable storage media and networks. As disk sizes (and archive sizes) have increased, the probability of corruption undetected or uncorrected by the mechanisms normally built into disk drives, network protocols, and filesystems has increased to a level that warrants great concern.
I would be interested to know if there exists an archive format that has the following desirable properties:
1) It is well-documented, and relatively simple, to facilitate its implementation on many platforms present and future.
2) It supports some degree of incremental updating, but need not be particularly efficient about it. An explicit compaction operation is preferable to an overly complex format. It is adequate to use append-only strategies appropriate for write-once media.
3) Insertion and extraction of files, copying of the archives, and other archive-manipulation utilities support end-to-end verification that identical bits have been stably recorded to the media, bypassing or defeating platform-level or hardware-level caching mechanisms. Where this is not possible, the limits must be carefully delineated, with some basis for determining the properties of the platform and certifying reliability
properties where possible.
4) The format should provide for superior error detection capability, designed to avoid common failure modes with mechanisms typically used in hardware. For example, use a document-level cryptographic checksum rather than a block-level CRC.
5) The format should include a high degree of internal redundancy and recoverability, say, along the lines of a virtual RAID-array.
Just as biological organisms constantly correct DNA transcription errors,
the idea is to have a format that is robust across long-term exposure to
imperfect copying and transmission channels.
Does anything like this exist?
--Bill
I too have been searching for documentation/schematics for the Cambridge
Memories, Inc. Expandacore18 4k core memory boards. I have an old
Diversified Numeric Applications Med PL/185 machine which is a clone of the
Raytheon 703. This machine has 16k of core with 4 of these boards.
--
THE BLUES IS THE TRUTH. IF IT'S NOT THE TRUTH, IT'S NOT THE BLUES. (Willie
Dixon)
Here is an interesting article from the ozobob list on 50 yeas of
computing in the US Army!
http://www.dtic.mil/get-tr-doc/pdf?AD=ADA431730
About the earliest thing we have militantly computer related in the
museum are some parts of the NORAD SAGE system
(Apologies if this gets posted twice, e-mail changes appear to have lost
the first one...)
Hi all --
Just wanted to let you guys know that a new version of the Xerox Alto
emulator I've been working on at the LCM+L has been released. V1.1 of
ContrAlto can be downloaded from:
http://www.livingcomputers.org/Join/Online-Systems.aspx. At this point,
the vast majority of software appears to be working properly, if you do run
into any issues please let me know!
ContrAlto is open source, so if you want to hack on it the source is
available on our GitHub site at
https://github.com/livingcomputermuseum/ContrAlto.
Thanks!
- Josh
I have pmaz SCSI controller, a couple lofis, and a bunch of 8MB pmax+
modules that are being threatened with the local electronics recycler.
send me the address of your good home or place of business in the
continental US states, and I'll spare them that fate.
--
Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com
I scanned my copy of the Hitachi 303 manual a few weeks ago. For anyone
interested in downloading it, I uploaded it here:
https://drive.google.com/open?id=0B8Ow1Wo1rBQUSVdXQU84SWtVRFU
Didn't see it on Bitsavers yet, so I thought I would share.
Thanks,
Kyle
I have not had good luck with the RuGRiD list. I am aware of it.
There are only a small handful of people there with Compass gear; It is
mostly centered around the later PC-compatible GRiD stuff.
There is one fellow with quite a lot of Compass media who has reached out
to me a couple times, but I don't get the drift he sees any urgency in
imaging the media, nor intends to share it. I have offered a hand, money,
etc.
If he does come through, I'll be very pleased, but at this point I am
trying to look elsewhere.
Steve, if you're willing to cross-post my list below and see if you have
better luck, please do.
I have never received a single response of value on that list.
- Ian
On Tuesday, October 25, 2016, Steve Hatle <shatle at nfldinet.com
<javascript:_e(%7B%7D,'cvml','shatle at nfldinet.com');>> wrote:
>
>
>
> -------- Original Message --------
> Subject: Need to archive: GRiD Compass Computer Operating System
> Software
> From: Ian Finder <ian.finder at gmail.com>
> Date: Tue, October 25, 2016 7:08 pm
> To: "cctalk at classiccmp.org" <cctalk at classiccmp.org>
>
> Folks, there appears to be a large GRiD-sized hole where archived copies
> of
> the Compass Computer Operating System software should be.
>
> ...
> --
> Ian Finder
> (206) 395-MIPS
> ian.finder at gmail.com
>
> >>
>
> There's a fairly active GRiD list at
>
> http://groups.yahoo.com/group/rugrid-laptop/
>
> You may wish to cross-post there, or I can if you don't wish to join up.
>
> Steve
>
--
Ian Finder
(206) 395-MIPS
ian.finder at gmail.com
I picked up an Informer 213 from eBay this week, but it has the IBM rom
set! Noooooo!
Anyone out there with the VT100 version willing to dump the roms for me?
Thanks,
- Ian
--
Ian Finder
(206) 395-MIPS
ian.finder at gmail.com
> From: allison
> What vendor
I don't recall, would have to look it up; I turned Guy onto them, and he
bought out everything they in stock.
> They have been scarce save though resellers that have NOS parts from
> old stocks and they are not cheap and unpredictable quantities.
Yeah, that vendor said they could get more (apparently from others who still
had stocks), but they'd be slightly more expensive. Apparently these people
all interact, and deal stuff around.
So that figure I was given of 30K in stock is probably not from that one
vendor, but across all of them. But since nobody is using these chips in a
product (that I know of), I suspect the number is likely to go down only
slowly.
> Then I could buy them they are about .86 dollar US, but that was in the
> early 80s.
The ones Guy and I recently bought were about $1 each (I don't recall the
exact amount, would have to check). So not cheap, but not ridiculous.
Noel
> From: Paul Koning
> The trouble with chip resellers is that it's hard to know which ones are
> legit, and which ones are in the fake chip business.
I suspect that the network of major resellers would tend to keep out the
riff-raff. (They don't need the aggro of dealing with the consequences.)
> a 7400 instead of something more valuable.
Which is why it's good that the DS8641's are going for little more than a
buck; at that price point, there's only minimal benefit from faking them.
Anyway, for any I get, random samples go straight into my tester board!
"Trust, but verify!" :-)
Noel
Hello,
surely the old transceivers are the most compatible solution, however you
still need to convert the voltages back and forth...
Plus the solution is not the cheaper, and a little uncomfortable too, as
you need to find these old chips, hoping not to buy fake chinese duplicates
(it happened to me more time unfortunately).
So I was searching a solution with modern components, but not using
components too much specific and difficult to be found.
As we need 3.3v logic, but able to work in 5v bus, I'm thinking about 5v
tolerant standard logic as TI LVC or LVT.
The problem is that there aren't open drain bus transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.
So identifying one or maybe two codes would be enough for all the
components needed for the board.
The idea of using bare transistors seems to me too much simple.
Not that it couldn't work, but it would be almost impossible to satisfy all
the specifications of the bus in this way... unless you use a more complex
circuit with precise current sources and resistors to grant correct voltage
biases, impedances and slew rates, which in the end is a logic integrated
circuit.
Andrea
> From: Guy Sotomayor
> Secondary chip marke[t] (only reputable vendors).
I'm a little more willing than Guy to troll in disreputable waters (I bought
1K DS8641's from a source in Hong Kong), so I have this:
http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/TestCardF.jpg
which has a bunch of special circuits on it to test chips to make sure they
meet specs; e.g. the large potentiometer is so I can vary the input voltage
to see where it switches from 0 to 1, etc.
> From: Paul Koning
> it would be odd to have one; I can't think of anyone who would expect a
> PDP11 to work with part of its devices powered down. For one thing, if
> the box with the terminator loses power
Forget the terminator - as Jon Elson also points out (his email appeared
while I was creating this one), any device which uses interrupts, if
un-powered, won't pass grants.
> From: allison
> Bottom line is someday there will be no DEC parts and what then? I
> reserve DEC parts for repairing defunct boards for new and unique build
> it would be a waste of scarce material.
For actual DEC interface IC's like DC003's, sure. Those are hyper-rare.
But DS8641's are available in the 10's of thousands, there's no earthly way
we could use them all on repairs. Yes, when they run out, we'll have a
problem - but I plan to cross than bridge _if_ and when we get to it.
Noel
Does anyone remember a subscription time sharing system called, I think, "game master".
It was at least available and marketed in the chicago area... possibly nationwide.
I just wonder if there is any info on what kind of system it ran on and any preserved info etc.
Thanks.
-Bob
Update: I've swapped the displays and drivers around, and the "tunnel"
effect seems to be a property of the panel and not drive electronics.
Perhaps they are all high-hour examples?
Anyone here an electroluminescent display expert?
>
>
> On Wednesday, July 20, 2016, Ian Finder <ian.finder at gmail.com> wrote:
>
>> No, I'm not convinced the EL repro isn't a driver electronics issue.
>>
>> I'm just a little confused about why the issue congregates at the edges
>> of the displays. Any ideas why that might be?
>>
>> I may try swapping the panels around this evening if I am feeling brave.
>>
>> On Wednesday, July 20, 2016, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
>>
>>> On 2016-Jul-20, at 12:52 PM, Ian Finder wrote:
>>>
>>> > I have a few GRiD compass systems and some are suffering from massively
>>> > decreased contrast on the edges of the displays:
>>> >
>>> > [See the system on the left]
>>> > https://www.instagram.com/p/BIGGzUzgat-/?taken-by=tr1nitr0n
>>> >
>>> > [Or this one:]
>>> > http://www.ripstick.com/USCM/images/Grid_Compass_1101_
>>> Laptop_in_Box_002.jpg
>>> >
>>> > Meanwhile, other EL systems I have- like my HP integral PC- haven't
>>> > succumbed to this.
>>> >
>>> > I have seen similar issues on amLCD displays in my Tadpole, Toshiba and
>>> > other machines, so this is something we all may have to confront.
>>> >
>>> > -------
>>> >
>>> > I was wondering if the folks here had theories?
>>> >
>>> > I'm thinking moisture (or air) might be leaking in from the edges of
>>> the
>>> > glass panes, perhaps from a compromised seal- sorry for the silly
>>> picture
>>> > but you can see the composition of the display here:
>>> >
>>> > https://www.instagram.com/p/6BXaLBtSzd/?taken-by=tr1nitr0n
>>> >
>>> > Does anyone know how one might prevent this from progressing- storage
>>> tips?
>>> >
>>> > Could it be reversed?
>>> >
>>> > Better yet, does anyone have ideas on how to rapidly dehydrate the
>>> display?
>>> > Perhaps there is even a way to re-seal them.
>>> >
>>> > I think all two-glass-pane displays that don't have a vacuum may
>>> eventually
>>> > succumb to this.
>>> >
>>> > Perhaps it is just oxidation and not moisture, but I'd love to hear any
>>> > theories.
>>>
>>>
>>> Are you convinced this is a panel problem rather than a driver
>>> electronics problem?
>>>
>>> In one picture it looks like the sort of thing that happens when you
>>> have to turn up the brightness (for some types of display), resulting in
>>> partial illumination in other areas of the screen.
>>>
>>> I've never had opportunity to repair or work on EL flat-panel displays,
>>> I'm not familiar with the driving techniques and requirements, so this is
>>> just a query/guess. (I see it's an X/Y matrix drive scheme, but the
>>> voltages & timing & phasing I don't know about.)
>>>
>>>
>>
>> --
>> Ian Finder
>> (206) 395-MIPS
>> ian.finder at gmail.com
>>
>>
>
> --
> Ian Finder
> (206) 395-MIPS
> ian.finder at gmail.com
>
>
--
Ian Finder
(206) 395-MIPS
ian.finder at gmail.com
even with shipping across the pond a great deal if your system is
missing one!
Ed#
In a message dated 10/25/2016 3:15:40 P.M. US Mountain Standard Time,
linimon at lonesome.com writes:
If it were on this side of the pond I'll be all over that.
mcl
-------- Original Message --------
Subject: Need to archive: GRiD Compass Computer Operating System
Software
From: Ian Finder <ian.finder at gmail.com>
Date: Tue, October 25, 2016 7:08 pm
To: "cctalk at classiccmp.org" <cctalk at classiccmp.org>
Folks, there appears to be a large GRiD-sized hole where archived copies
of
the Compass Computer Operating System software should be.
...
--
Ian Finder
(206) 395-MIPS
ian.finder at gmail.com
>>
There's a fairly active GRiD list at
http://groups.yahoo.com/group/rugrid-laptop/
You may wish to cross-post there, or I can if you don't wish to join up.
Steve
Folks, there appears to be a large GRiD-sized hole where archived copies of
the Compass Computer Operating System software should be.
For those not aware, GRiD had an OS product that was quite advanced for the
time- with bitmapped graphics, multitasking, a beautiful forms-driven, UI,
etc.
Unfortunately, nothing but the basic OS seems to be preserved anywhere- no
add-on software, not even the utilities needed to format the hard drive.
This is a travesty- GRiD made something far more important than PC clone
machines, at one time.
*** I'm looking for leads on any software products mentioned below, or at
this URL:
http://www.1000bit.it/ad/bro/grid/GRID-1984-PriceList.pdf ***
I have been buying manuals for the express purpose of scanning, and have a
great deal of coverage, but am short on software.
I am not opposed to paying for any of this, nor shipping and returning the
original copies to the provider at my own expense.
I will certainly put all the images in Bitsavers, if Al is okay with that-
otherwise they will be made available through some other means.
Any leads on GRiD media is appreciated.
Thanks,
- Ian
GRiDWrite, Management Tools, GRiDVT100, and GRiDbasic have already been
preserved.
[35], [36] and [37-47] would be incredible to find.
REF PRODUCT MODEL VERSION NOTES
--- ------------------------- ----- ------- -----
18 GRiD-OS 110X/112X 29200 3.1.0.A [6]
19 GRiD-OS 113X 29210 3.1.5.D
20 GRiD-OS 110X/112X 29200 3.1.0.A
21 Management Tools 21100 3.1.0
22 GRiDMaster 21231 3.1.7
23 GRiDPaint 21214 3.1.5
24 GRiDWrite 21132 3.1.7
25 GRiDAccess 21212 3.1.7
26 GRiDPlan 3.1.5
27 GRiDPlan II 3.2.1
28 GRiDWrite 21132 3.1.7
29 GRiDVT100/Reformat 21191 3.2
30 GRiDVT100/Reformat 21191 3.1.5
31 GRiD3101/Reformat 21151 [7]
32 GRiD3101/Reformat 21151 3.1.5 [7]
33 GRiDTek4016 21228 36.9.4 [7]
34 GRiDTerm/Reformat 21141 3.1.5
35 GRiDTransfer/Partition 21210
36 GRiDRecord/Playback 3.1.5
37 C-86 23032 3.2.0
38 Pascal-86 23025 0.3.1 [1 COPY SOLD]
39 FORTRAN-86 23015 0.3.0
40 PL/M-86 23030 0.2.7
41 BASIC 3.1.0 [7], [1 COPY SOLD]
42 ASM-86 23031
43 GRiDDebug/Devel. Tools 29300 3.1.7
44 GRiDDebug/Devel. Tools 29300 3.0.0
45 GRiDTask II / Windows 21230 3.2
46 GRiDTask II 21230 3.1.7
47 GRiDTask 21230 3.1.7
48 ROM Builder 2.1.0 [7]
49 ROM: GRiD-OS System 112X 24100 3.1.0 [8]
50 ROM: GRiD-OS System 113X 24180 3.1.5 [8]
51 ROM: GRiD-OS Utilities 21400 3.1.0 [8]
52 ROM: GRiDMaster 3.1.7 [8]
53 ROM: GRiDVT100/Reformat 24150 3.2 [8]
54 ROM: GRiDWrite/Term/Refmt 24140 3.1.5 [8]
--
Ian Finder
(206) 395-MIPS
ian.finder at gmail.com
Friend of mine pointed this out to me, but I'm a software guy, don't have
any use for hardware. Maybe you guys would be interested.
http://www.ebay.co.uk/itm/DEC-PDP-15-console-panel-von-1970-/112179257620?h…
8 days left. I think he failed to sell it previously at 130 Euros so that
probably sets an upper limit on the auction price.
Graham
> I'll start with getting VTServer to run under V6 (my only Unix, don't
> have anything later :-)
So, I just got VTServer runnin under V6: it successfully loaded a memory
diagnostic from the 'server', into the 'client', using 'vtboot' on the
latter. (Both running on emulated machines, for the moment - I thought I'd
take all the hardware-related variables out of the equation, until I have the
software all running OK.)
It didn't require as much work on VTServer as I thought it might: I had to
convert the C to the V6 dialect (no '+=', etc), and some other small things
(e.g. convert the TTY setup code), but in general, it was pretty smooth and
painless.
Note that it won't run under vanilla V6, which does not provide 8-bit input
and output on serial lines. I had previously added 'LITIN' and 'LITOUT' modes
(8-bit input and output) to my V6; since the mode word in stty/gtty was
already full, I had to extend the device interface to support them. I didn't
add ioctl() or anything later, I did an upward-compatible extension to
stty/gtty. (I'm a real NIH guy. :-)
My only real problem in getting VTServer running was with LITIN; I did it
some while back, but had never actually tested it (I was only using LITOUT,
for my custom program to talk to PDP-11 consoles, which also did downloads,
so needed 8-bit output). So when I went to use it, it didn't work, and it was
a real stumper! But I did eventually figure out what the problem was (after
writing a custom program to reach into the kernel and dump the entire state
of a serial line), and get it working.
(I had taken the shortcut of not fully understanding how the kernel serial
line code worked, just tried to install point fixes. This turned out not to
work, because of a side-effect elsewhere in the code. Moral of the story: you
can't change the operation of a piece of software without complete
understanding of how it works...)
Is there any interest in all this? If so, I can put together a web page with
the V6-verion VTServer source, along with the modified V6 serial line stuff
(including a short description of the extended stty/gtty interface), etc.
> so if you turn up whatever you used to boot V6, it would probably still
> be useful.
So I guess my next step, if I don't hear shortly from someone who has
previously used VTServer to install V6, is to start on actually getting
a V6 file system created.
I'm still vacillating over whether it would be better to go V6-style (and
just transfer a complete, small existing V6 filesystem), or V7-style (and
get stand-alone 'mkfs', etc running with V6-format file systems). Anyone
have an opinion?
Noel
Hi Noel,
>> Any chance it could be put into 'production'?
Sure, if there is interest, I could make a run of boards.
>> Also, what FPGA board are you using? I assume it's one that has an SD
>> card socket or something, for actually storing the bits on?
My project is just an interface board for an existing RL02 emulator
project: www.pdp11gy.com There are a multiple project revisions listed on
the pdp11gy.com site that use different Altera FPGA dev boards: DE0 Nano,
DE0 Nano SOC, and BeMicro CV.
I was planning to use a Terasic DE0 Nano dev board since these boards can
be found on eBay from $50 to $100. The DE0 nano does not have an micro-SD
card socket which is why there is a socket on my interface board.
http://sierracircuitdesign.ddns.net/temp/RL02
The DE0 Nano SOC, and BeMicro CV dev boards have micro-SD card sockets, so
if you used one of those, then you would not need to populate the micro-SD
socket on the interface board. According to the author of the
www.pdp11gy.com RL02 project, the 40-pin headers on DE0 Nano, DE0 Nano SOC,
and BeMicro CV are compatible, so you could use my interface board with any
of these boards.
Regards,
Scott
Does anyone have a datasheet for an Intel 8089A, 8089A-3, or 8089-3?
The only datasheets I've found are for the "plain" 8089 with no "A" or
numeric suffix. The component resellers show better availabiliity for with
the "A" and/or "-3" suffix, though it's possible that those are in error.
The 8089 is an I/O processor. The "-3" suffix is most likely a speed grade.
The standard part without the "-3" is 5 MHz.
Hello all together,
i restore a rk05 disk drive in combination with an Plessey RK8E clone
controller.
Now the drive itself is restored, and the connection cables are built.
My problem is that the rk8e diskless controll test (dhrka) fails with an
data break error. The diskless controlltest
is running throug all register and also the databuffer test. But in the
first data break routine it fails.
Then i toggled in the Example program from the maintanence vol.III,
Single Cycle Data Break Transfers (Write than Read).
With this program the content of the SwitchRegister is written through
the data buffer registers and read back to the memory.
Afterwards it is compared to the original SR content. I found out that
the routine is running if SR=7777. Deeper investigation results that the
bits 0, 1, 4, 6 and 9 have to be one`s to run the routine. The other SR
bits are switchable while running the program.
Next thing i did is trying read data with futil. i could read data form
the disk. But with many read errors.
Because i do not know anything about the allignment between my diskpack
and the drive, i formated the pack
with the RK8E Formater (dhrkd). The write part of the format is running.
In the disk checking part the formater fails.
Anyway. Then i used futil and scanned the whole surface off the
diskpack. On the whole disk are 5 bad blocks left.
Now i am able to dump blocks from the disk. But it seems that no matter
witch block i dump out, it is the same block
all over the disk. Afterwards i tried to modifie some words in block 0.
And this is working. When i write the modified block i see the
modification also in every other block of the disk.
Have anyone the lightning idea?
On a Google search i found a post of Rick Bensene from 2014 on this list
witch described a similiar problem.
In this discussion where talked about an spike in the load signal of the
current address register.
I checked that and see that this was not my problem.
Thanks in advance
Marco Rauhut
Hello,
we are discussing on separate thread about doing an universal interface for
PDP11.
I'm taking all the relevant documentation about Unibus and Qbus busses,
aiming to check the possibility of doing a board compatible, with some
adjustments, with both worlds.
I started to read the 1979 specifications, however it's not all clear to
me, specially about Unibus.
What I understood:
- Qbus is complete on A and B connectors, so a dual card could be done.
Some backplanes have a true serpentine, while some other has C and D with
other signals, but those are of particular usage with dual-board interfaces.
Basically both dual and quad boards can be done, with the latter using A
and B and simply propagating grant on C and D, supposedly connected in
standard serpentine.
Unibus: the specifications are describing A and B, but backplanes are
complicate than that, and can have Unibus, Modified Unibus, Extended
Unibus, SPC...
What for?
If all the signals are in AB, why they are connected again in CDEF?
There's some complete documentation about the different backplane types,
and the standard approach for an Unibus board?
Thanks
Andrea
> From: David Bridgham
> Just the bus interface takes over half the area of a dual-height board!
In part because the level converters are SMD, and we had to mount them on
(modified) wide DIP carriers to use them in a wire-wrap board.
> I've played around with laying out what might be the production board
> ... and I've got it down to a row of 8641 bus transceivers and a row or
> two of the level-converter chips.
> http://pdp10.froghouse.org/qsic/proto-pcb.jpg
For those looking at that picture, it's not our current plan for 'producton'
QSIC's; the one in the picture uses a daughter-card with an FPGA on it, but
that makes the card to high to fit into a single slot. So the current plan is
to do a card with an FPGA on it directly.
Noel
> From: Glen Slick
>> Went unsold at $3500. Relisted, this time at $5000.
> there was a taker for that 11/35 at $5000 today....
Smack me with a wet halibut. They must not have seen the original listing?
I can't come up with any other explanation why someone would pass up a chance
to buy it for $3.5K, and pay $1.5 more for the priviledge...
Noel
> Philipp Hachtmann wrote:
> Was it really sold? I can't figure that out from here. Only "listing
> has ended". And when I try to search for it, the website doesn't show
> it :-(
??? If you go to the listing:
http://www.ebay.com/itm/142146207101
the image has 'Sold' emblazoned across it. And if you click on that image, it
takes you to the original listing, which says "Sold for: US$5,000".
Noel
Hi folks,
Now that the bouncing has calmed down I've got a question about this here
triple output pretty ubiquitous power supply. This one had some burst caps
so naturally wasn't working and was probably why the machine it came out of
was taken out of use.
I've replaced all of them because why not, along with the .1uF mains
filtering cap that would also burst at some point and I still get low output
on all rails. I've tested all the major components out of circuit and
checked for shorts; in Apple ][ power supplies (also Astec, apart from the
ones that aren't) low output is mostly caused by a feedback capacitor (C7)
going out of spec, but these are all new and as close a match to the
originals I could find.
One thing I've not done is reflowed all connections so I'll do that later,
but has anyone got experience of common failure modes with these things?
Cheers
--
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?
Hi All,
I have a few IBM PS/2s in various states of disrepair that are free to
anyone willing to collect from Yatton (Near Bristol), or arrange a courier.
Systems as follows:
Model 30-286 - powers on to BASIC prompt, bad floppy drive, missing hard
drive. A few minor scuffs, should make an easy restoration.
Model 50 - Boots from HDD to DOS, has bad sectors but might be OK after a
low level format, haven't tried it because the FDD is bad. Includes
untested tape drive in the second 3.5" drive bay. Some rust spots on case.
Model 77 - Very good cosmetic condition but doesn't power on, corrosion
around the BIOS chip so I'm guessing it's because of that.
If anyone's interested I can take photos and find out the system specs. I
also have one of the later IBM PS/2 mice.
Regards,
-Tom
> From: Scott Baker
> Feedback on this project is most welcome.
Any chance it could be put into 'production'? It just seems to me that
rather than having 53 people send in individual orders for boards, etc
it would be better (and also perhaps get a price break due to volume)
to do a small run. (You may not want to produce complete boards, but
even kits would be useful.)
I think an RL02 simulator is a great idea; those of us with RL0x controllers
could use this most of the time, avoiding potential damage to our old
drives/disks; I know I would buy several if they were available.
Also, what FPGA board are you using? I assume it's one that has an SD
card socket or something, for actually storing the bits on?
Noel
The fact that the installation procedures for V6 and V7 are wholly different,
in their technical detail, was apparently not well known.
The 'Setting up Unix' documents are more checklists, they don't go into a lot
of detail as to what is actually happening, so I have prepared two pages on
the Computer History wiki:
http://gunkies.org/wiki/Installing_UNIX_Sixth_Editionhttp://gunkies.org/wiki/Installing_UNIX_Seventh_Edition
which go into more detail on what is actually happening.
Noel
On 22 October 2016 at 17:27, Adrian Graham <witchy at binarydinosaurs.co.uk> wrote:
[..]
>> Same story from me, and I also wondered about the excessive bounces -
>> because of gmail.
>
> Ditto, and ditto. I also thought it was due to the dyndns attack so just
> resubbed after emailing Jay, but if everyone did that who got an excessive
> bounce message the poor chap will have quite a full inbox.
Yes, it must have been that attack. I wasn't aware of it at the time,
probably because I rely on 8.8.4.4. DNS which was never affected.
We still need that global task force to hunt down spammers and
ddos'ers and get rid of them once and for all. Or at least inflict
some discomfort.
Hello Dave,
exactly!
But in place of a plain FPGA, nowadays I would choose a FPGA-ARM board,
for example
the ZedBoard MicroZed or the Myirtech Z-turn, both of them have a Zynq
onboard,
and they can run linux for the software side and programmable logic for
the interface side.
Very nice and flexible.
For the development, I'm trying to figure if an hybrid QBUS / UNIBUS
solution is possible.
Of course one have to switch some jumper to avoid conflicts, but hey, in
the end you
would have a true universal board.
What kind of bus transceivers did you used for the QSIC, specially
because you have
to go from 5V open-drain logic to 3.3V logic?
Thanks
Andrea
On 10/21/2016 07:00 PM, cctalk-request at classiccmp.org wrote:
> You mean, perhaps, something like this?
>
> http://pdp10.froghouse.org/qsic/html/overview.html
> On Oct 18, 2016, at 11:00 AM, cctech-request at 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.
Just curious, I probably could have just asked Jay but incase this was wider spread I received a message that my subscription at my Gmail was suspended due to bounces. I was wondering if that may have been only today and more widespread from the Dyn dns ddos that happened? If so others may want to double check for similar issues as I probably missed some messages today.
No biggie, just a PSA if it affected more than myself.
micropolis 1325
--sectors 16,0 --heads 8 --cylinders 1024 --header_crc 0xffff,0x1021,16,0 --data_crc 0xffffffff,0x140a0445,32,5
--format WD_1006 --sector_length 512
40 meg disk in the system used a 1323, 4 heads instead of 8
OK, I have a fairly large collection of VAX 4000 and VAXStation 3000
systems which I have fun with and use with both OpenVMS and OpenBSD
over the years....
But, I also have two big rubbermade containers (about half a cubic
meter) filled with TK50 and TK70 tapes which I have never used.
Some are blank, some are the boot & install media for VMS 5.5, some are
software installations, etc. etc.
In the past 25 years that I have had them, I have not once ever used
my TK50 or TK70 drives...I've always either booted off the attached
disks or netbooted.
Should I just throw these things out? Do any collectors consider them
to be valuable? Since it's now 2016 and I think the last TK tapes were
made in the 1990s, I'm getting the urge to toss them.
Opinions? Comments?
---------------
Thomas "PDP-11" Dzubin
Vancouver, Calgary, or Saskatoon; CANADA
I wouldn't dismiss it if you're using images or any used software. Yes some platforms are more susceptible than others but unless you have no hard drive, power your system off after every use, and never switch disks while system is running it's still something that can infest your originals or archive.
Dan's great collection of cpm is a good example of something that ended up passed around the community and had a few infected images. ?Depending on whether it's a file, boot sector, MBr or TSR it will different and potentially detrimental impact.
I stopped archiving my Amiga disks but at a place I worked that had Amiga systems some kids brought in lots of games (some cracked) and while we didn't allow that it was spring break and they had finished their work. What's the worst that could happen? Kids slowly starting to walk up and say their computer says it's infected with a virus.
Probably one disk but who knows how many were infected after that. Took me longer just to find an antivirus for the Amiga than to get the systems cleaned lol but still, an unexpected pain.
One of the best preventative methods if the software doesn't need to write to the originals is write protect the floppy. ?But buying used, who knows if the previous owner was computer savvy or safe.
-------- Original message --------From: Steven M Jones <classiccmp at crash.com>
Well, glad to hear there's nothing to worry about.?
Hello Rob,
I'm quite sure that the tantalum explosion has nothing to do with the
spin-up failure.
Indeed the RD53 (Micropolis) is infamous for a problem in the head
positioning shock absorber.
The head positioning system is based on a voicecoil inserted in the
magnetic field; the angle covered by the head arm is limited by two
adjustable metal limits originally covered with rubber.
At startup the mechanism is moved back and forth to check the two limits,
and exactly at the ends a special magnetic pattern is recorded on the
surface of the disks for calibration.
Due to age, the rubber becomes goo, so the angle limits become wider, so
during the calibration the head falls offer the calibration area and
spin-up fails.
The suggestion is to choose a clean room with few dust and a good lighting,
carefully open the top cover of the disc, and remove the goo the more as
possible using adsorbent sticks.
Be sure not to touch the disc surface with the goo accidentally.
Then try to insert some small pieces of paper over one limit (if I'm not
wrong the failing is the left) in place of the missing rubber, and try the
disc, and continue to add thickness until it works.
Then you are sure about the right limit to move.
Then remove the paper, loosen a little the screw, but just a little so the
limit will not move unless pushed with some strength and a screwdriver.
Then move a very small amount towards the center and try, then repeat trial
and error until the disc starts. Then tight the screw and it is over.
Close the disc and voila.
Andrea
> From: shadoooo
> they can run linux for the software side
Maybe it's just me, but running Linux on an interface card strike me as
somewhat grotesque. It's bad enough running a far faster chip than the vintage
CPU, but... a majorly complex operating system to boot?
> I'm trying to figure if an hybrid QBUS / UNIBUS solution is possible.
> Of course one have to switch some jumper to avoid conflicts
Lots and lots and lots and lots of jumpers. The two buses are completely
unlike, pinout-wise.
And the UNIBUS board has to be a quad, and there are some QBUS chassis which
only take duals...
> What kind of bus transceivers did you used for the QSIC
We used a mix of DS8641 quad transceivers (they're still available in
reasonably good numbers for a reasonable price) and AM2908 octal latching
transceivers with a tri-state output (to allow us to have a bidirectional
internal bus for BDAL00-BDAL21 - we were trying to minimize the number of pins
needed on the FPGA to interfaces to the QBUS). But we probably will use a
different FPGA on the production boards, and all DS8641's.
> you have to go from 5V open-drain logic to 3.3V logic?
We do that with separate 74LVC7T245 level converter chips.
Noel
Hmmm... I just sent a message to the list and got the following error:
"Your message did not reach some or all of the intended recipients.
Subject: RE: Archived viruses, was Re: Reasonable price for a
complete SOL-20 system?
Sent: 10/22/2016 10:30 AM
The following recipient(s) cannot be reached:
'General Discussion: On-Topic and Off-Topic Posts' on 10/22/2016 10:30
AM
451 Requested action aborted: local error in processing"
Resent the message again and it went through fine. Anyone else having
trouble posting?
-Ali
Hello Dave,
exactly!
But in place of a plain FPGA, nowadays I would choose a FPGA-ARM board,
for example
the ZedBoard MicroZed or the Myirtech Z-turn, both of them have a Zynq
onboard,
and they can run linux for the software side and programmable logic for
the interface side.
Very nice and flexible.
For the development, I'm trying to figure if an hybrid QBUS / UNIBUS
solution is possible.
Of course one have to switch some jumper to avoid conflicts, but hey, in
the end you
would have a true universal board.
What kind of bus transceivers did you used for the QSIC, specially
because you have
to go from 5V open-drain logic to 3.3V logic?
Thanks
Andrea
On 10/21/2016 07:00 PM, cctalk-request at classiccmp.org wrote:
> You mean, perhaps, something like this?
>
> http://pdp10.froghouse.org/qsic/html/overview.html
Published in the National Computer Conference, 1976. Full quote:
"He bought an RPC-4000 "at a graveyard-type disposal sale," and later noted,
"My RPC is working but I can't get an assembly program more than two-thirds
loaded. This produces lots of messages telling me my programs are bad" I
suspect some memory aberrations, but the memory print routine won't print
either. So I have been trying to write a simpler routine of my own in
machine language. That is a drag. It is amazing how many ways you can make
mistakes with 32-bit instructions." "
Also memorable:
"An Indiana hobbyist bought a Univac 0 File Computer as scrap, with
arithmetic unit, program-control unit, 90-column reader/punch, sort-collate
unit, tape-drive program controller, and six magnetic-tape units. The new
owner says, "I had figured to use the outside winter air to get it turned on
and see what I've got, and just close down in summer. As to space, not too
bad: only about 400 or 500 square feet, pretty compact. I'm presently having
220 V installed to begin to turn on some of it."
And *we* think that we have it tough :->.
From:
https://www.computer.org/csdl/proceedings/afips/1976/5084/00/50840235.pdf
-----
>
> John McAfee predicted that 5 million computers would be wiped out.
> The press were called in.
>
> On March 6, there were apparently DOZENS of drives wiped. Few, if any
records kept to verify numbers.
> McAfee, as expected, took full credit, and declared that the REASON why
it was dozens, instead of millions, was because his warnings were heeded.
>
> Six months later, when he took his company public, he raised 42 million
dollars.
>
> He is currently a fugitive as the "prime suspect" in the murder of his
neighbor in Belize (apparently NOT virus related)
>
>
Side note...maybe 6 or 12 months before the big virus scare I called McAfee
on the phone and spoke with him about a virus I found on a GRID laptop that
I found was copied to 4000 similar machines out in the field where I
wokred. He emailed me his latest test iteration of his software, a copy on
a scratch disk. It was a very early version. I had no idea of course of
his future, but I was impressed with his software because it was light, no
install disks and he knew his stuff. We were talking about how to inject
his antivirus prpgram into a program I wrote to update laptops remotely by
modem, and how we could send virus updates via this process. It was
getting impractical to keep sending me disks and we needed a better way.
You could not buy his software
Viruses were starting to get more numerous. I don't know if he had just
started his company, it was not public or anything yet. In fact I got his
number inmformally from a manager at a company called Sales Tchnologies out
of Atlanta, I w as working with their sales tracking program they were
already using my "mass update" system to manage their software and data
updates. That's where the virus came from. Fun times all MS DOS based,
btrieve database, Sprint Internet exchange for free phine calls inbound
>from anywhehre in the USA... I also remember building and compiling Sales
Tech software version updates on a xerox workstation. When I left they
offered me the Xerox but I remember thinking what would I ever do with
*that* old piece of junk? "Well Bill you're the only one who knows how to
use it so we will just throw it away then, are you sure".."yah, my
apartment is too small...."
At least that's how I remember it.
Bill
On Oct 21, 2016 8:30 PM, "Steven M Jones" <classiccmp at crash.com> wrote:
>
> On 10/21/2016 14:15, william degnan wrote:
> > Any disk or archive you come upon from the early 90's should be scanned
for
> > viruses before use on a vintage machine. USe a modern PC as it's no
biggie
> > to clean old viruses that way. Scan before you use on an older machine,
> > scan inside of ZIP files not just the zip itself. There were three
viruses
> > that I found years ago on the most-often seen Maslin archive set. Old
> > stuff that's not an issue for modern machines.
>
> I didn't think modern A/V products included complete historical sets of
> signatures. I'm sure they can deal with ancient, simple bootloader
> infections and such, but at some point I'd be concerned there's a gap
> where something might be too new to be detected by the simplest
> heuristics, but too old for a more sophisticated signature to be in your
> common modern products.
>
> But this isn't something I've had to deal with. Is this an imagined
> problem, or has somebody run into this?
>
> Thx,
> --S.
>
Stoned Monk is still detectable by modern anti virus software, 25 or
whatever years later, at least last time I tested using a win 7 machine.
So, that was maybe 4 or 5 years ago.
for anyone wanting to try David's MFM emulator in an HP MFM 7945 disk box, here is the
format, determined from reading a Vertex V170 drive from one
--sectors 32,0 --heads 7 --cylinders 987 --header_crc 0xffff,0x1021,16,0 --data_crc 0xffffffff,0x140a0445,32,5 --format
WD_1006 --sector_length 256
The 7945 is notoriously flaky because of the Vertex drives.
Hi,
The author of this project http://www.pdp11gy.com
<http://www.pdp11gy.com/doneE.html> built a wire-wrapped board to interface
an RL02 controller (RL11, RLV21, or RL8A) and an FPGA development board
(which does all the heavy lifting for the disk emulation).
I decided to build one of these emulators and to design a printed circuit
board rather than using wire wrap.
The schematics and layout of my RL02 interface board can be found here:
http://sierracircuitdesign.ddns.net/temp/RL02
I made changes to the original design (e.g. I used different driver and
receiver chips) but I think it should be plug compatible with the original
wire-wrapped design.
Feedback on this project is most welcome.
Regards,
Scott
On 21 October 2016 at 16:37, Liam Proven <lproven at gmail.com> wrote:
> A friend of mine is working on an emulator for this Burroughs Large
> Systems beast.
[..]
> I have suggested to him that it might be easier to work under an
> existing mini/mainframe emulator, such as SimH or maybe even
> MESS/MAME, but he is highly resistant to this idea, for reasons I do
> not really understand.
>
> I'm interested in opinions: do folk think that it would help, or not?
I fully understand. Not everything is easily tweaked to fit into those
frameworks. When I wrote my two minicomputer emulators I couldn't see
how on earth I could get that working inside simh without increasing
the work needed ten or fifty times. There wasn't anything there that
would help me for what I had in mind.
> From: Paul Koning
> 1976 Peripherals Handbook, page 6-4. It specifies the driver output
> low voltage at 70 mA sink, not 50...
Differing editions give slightly different numbers. I was looking at the 1972
edition (which was the one that was closest to hand, no other reason); the
number I gave is on pg. 204. I haven't checked later ones to see if there
were further revisions.
The later 70mA sink spec is probably a slightly more robust number to work
with.
Noel
A friend of mine is working on an emulator for this Burroughs Large
Systems beast.
There is an existing one -- https://github.com/pkimpel/retro-b5500
But it's web-based and in Javascript. Mark wants one that can be run
as a proper local binary, under Linux. I believe he's using part of
this emulator but trying to port it to either C, FreePascal or a
mixture of both.
I have suggested to him that it might be easier to work under an
existing mini/mainframe emulator, such as SimH or maybe even
MESS/MAME, but he is highly resistant to this idea, for reasons I do
not really understand.
I'm interested in opinions: do folk think that it would help, or not?
Also, anyone who might have any info that would aid him and are
interested, I can put you in touch.
He claims the system was influential in the design of the original
Intel 8088/8086, which is news to me. Comments?
--
Liam Proven ? Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk ? GMail/Twitter/Facebook/Flickr: lproven
Skype/MSN: lproven at hotmail.com ? LinkedIn/AIM/Yahoo: liamproven
Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)
> From: David Bridgham
> the right threshold voltage to meet the receiver spec
The UNIBUS spec says the 4 crucial receiver parameters are input thresholds
(high and low), and the input currents (high and low); the crucial
transmitter parameters are the output low voltage (at 50 mA sink), and
the output high leakage current.
Noel
> From: Lars Brinkhoff
> Emacs in 1983 would have been Gosling Emacs, I guess.
Prior to that one, someone else at BBN (whose name I have forgotten, alas)
did an Emacs intended for PDP-11's running Unix. It wasn't programmable (the
way 'real' Emacs is), perhaps because there was not enough room for that on a
PDP-11.
I should have that on my MIT-CSR backup tapes, but if you're interested in a
copy, it will be a while before I can excavate it; the tapes had some
dropouts, which may have made the dump (a straight 'dd' of a 4.3 filesystem)
unreadable.
Noel
Folks,
We have another pedestal ES40 and rackmount ES45 to give away, as well as a
half-height Compaq rack (20U?). Has to be collected from CB8 7NY before the
end of next week otherwise they get recycled.
Anyone fancy an early xmas present? :)
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
> From: Lars Brinkhoff
>> someone else at BBN (whose name I have forgotten, alas)
> Sounds vaguely like MicroEMACS by Dave Conroy, but I suppose this is
> something else? Unix V6 you say? Was it BBN PEN by David Barach, David
> Taenzer, and Robert Wells?
None of those names rang a bell.
I just read the entire backup tape (in file form) into an editor, and
searched for "Emacs", and I found some things which indicate the version I'm
thinking of was written by Warren Montgomery, of Bell Laboratories (that's
what I get for relying on memory, sigh). It was apparently written in the
1980 to early-1981 timeframe.
Googling 'Emacs Warren Montgomery' turns up some interesting early things,
including this:
http://org.ntnu.no/emacs/implementations.htmlhttps://www.finseth.com/emacs.html
Perhaps you already have this content, though?
> Yes, I am! I don't think I can take on every single variation of Emacs,
> but a version this early is interesting.
OK, I will keep this in mind if/when I ever manage to read the dump.
Noel
For those curious about the equipment that sold last week, I put together an album from my brief stop on Saturday. Let me know if you have trouble viewing it.
https://goo.gl/photos/yb83SJSj67gS96n39
On closer inspection it appears the documentation for that GP-4, as well as some of the other computers, sold to different parties (the value being in the shelving and cabinets).
I'm still losing sleep over that GP-4. From all appearances it was a turn-key setup (in theory). Unfortunately, the auction site immediately removes closed lots from their webpage so no idea what it sold for, or if it went to a scrapper. I suspect it was billed as 'cabinets of aviation equipment'. Being 3 hours away I can't exactly run over there and pin a note on it.
Some further digging on the net revealed a photo in the Motorola Annual Report 1965 featuring the machine touting Moto's new ECL logic. Apparently it was designed for aviation simulation but included facilities for being a general purpose machine. -C
There's someone local who's seen my assortment of computer hardware
twice and has, each time, told me I should set up a museum.
This is tempting, but I don't know the first thing about doing it.
About all I'm sure of is that it would involve a lot of stuff I
currently have no idea of.
I know that there are at least a few people here who've been involved
in such things. While all the examples that come to mind are in the
USA, and mine would be in Canada, I'm sure there are many respects in
which the issues are jurisdiction-independent - and, who knows, there
may be such a person in Canada that I just can't recall offhand.
So, I'm wondering if there's anyone who'd be willing to share
experiences, thoughts, issues, whatever, on the possibility.
I'm not looking to make a lot of money off this. If I can turn my
computers from money-sink to money-neutral, I'll be content. (They are
currently soaking up money in the form of causing me to be renting
significantly more storage than I would be if they were to vanish.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Nice display Bill!
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------
From: william degnan <billdegnan at gmail.com>
Date: 10/20/16 13:01 (GMT-07:00)
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
Subject: Re: Museum thoughts?
>
> >
> > There's someone local who's seen my assortment of computer hardware
> > twice and has, each time, told me I should set up a museum.
> <snip>
> >
> > So, I'm wondering if there's anyone who'd be willing to share
> > experiences, thoughts, issues, whatever, on the possibility.
> >
>
>
Maybe you could find a local museum and volunteer there, see what's
involved behind the scenes.? If there is nothing close enough to your
interests offer to contribute an exhibit to a local college, or business,
or someone who has a stale display case that could use a refresh. Come up
with a plan and present it to the powers that be.? This way you can get
some experience before you go full museum.
Here is an example of what I am talking about, at the U of Delaware in the
computer sci hall.? I got some students to help set up.
http://vintagecomputer.net/UofDelaware/UofDelaware_CM_TRS80-2.JPG
Bill
> From: Paul Koning
> That's fine if your target is an OS for which you can write drivers. It
> wouldn't help RSTS users.
Right, they're stuck with exact clones of DEC controllers. (For Unix, tweaking
the RP11 driver to handle the extended RP11 should take all of 12 minutes,
tops! :-)
> Q22 disks .. RL02 also, if I remember right.
Oh, right, the RLV12 - forgot about that. Still, it would be nice to be able
to run RK11's and RP11's in 22-bit mode! :-) Especially since there will be
replicas of DEC's indicator panels for them, whereas an RL11 indicator panel
would definitely be... an anachronism! ;-)
> A possible answer for a lot of this is to do the actual emulation
> algorithms in software, in an embedded CPU inside the FPGA. For MSCP
> that's obvious, but it would work for the others as well I suspect.
Dave B is a wizard with Verilog, so until it gets to the complexity level of
MSCP we'd probably do it all in Verilog.
> From: Jon Elson
> I did **ONE** board with some kind of gold flash that a PCB house
> recommended. ... it was a colossal disaster. You had to lift the pin
> ... Since then, I have used pure tin HASL, and had little trouble.
I think gold came into the discussion in the context of the contact fingers
where the board plugs into the backplane. I've never seen a QBUS/UNIBUS board
with tin fingers, although they were common on SIMM memory cards; no idea
if tin would work for QBUS/UNIBUS - although now that I think about it,
SIMM cards didn't slide into position, but kind of rotated, so maybe tin
would work there.
Noel
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.
From what I understand, there could be a great demand of a such
interface here around?
Andrea
I have a couple of drives I would really like to recover the data from.
On one of the two I've tried so far, the lowest head in the stack is really stuck on.
Has anyone successfully unstuck a head from this era. I've tried the obvious things
(gentle rotation in both axis, heating the platters) but there is a lot of surface
area on those old heads and it is pretty badly stuck.
> From: Paul Koning
> 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.
If you want to exactly emulate only DEC controllers, yes. (Of course, such a
project should do that, for binary compatability.)
However, as I think I have mentioned before, I'm actually enamoured of taking
a very simple controller like an RP11, which has lots of spare disk address
bits, and defining an 'RP11-E' which maxes out the virtual drive size without
changing _anything_ about the register format other than using unused bits in
the cyclinder address register. That will produce disks with 2^28 blocks, or
2^36 bytes, or 64GB. That's most of a large SD card... :)
Not too useful to those without the ability to tweak drivers, but... there's
another issue with the older controllers, which is that they only support
18-bit addressing, and for use on QBUS machines, where one would really like
to be able to do DMA to anywhere in the 22-bit space (for Unix, this would be
for swapping, and raw I/O - buffered I/O would be fine with 18 bits). So maybe
an updated version of those old, simple controllers would actually have some
use. (I'd certainly want them for my Unix boxes.)
> Apart from MSCP, avoid RL emulation also.
Why avoid RL's? Not the greatest controller, I agree, but it is a 'lowest
common denominator' drive for a certain era of gear.
> From: Toby Thain
> Isn't Noel working on something related?
I think Dave B gave a pretty good update.
In addition to what he mentioned, I'd like to mention the indicator panels
(like the DEC ones for the RF11, RP11, etc). Dave has designed the new
indicator PCB, and we have a couple of prototype PCB's in hand, stuffed and
working. I think there's a video clip of it doing its thing on the Web page he
pointed to.
Our concept is that we'll be able to drive more than one of these panels, by
connecting them together serially - that way a machine could have, say, both
RK11 and RP11 indicator panels, driven from a single QSIC board. That will
slow down the refresh rate a bit, but our numbers indicate it should still be
acceptably fast.
Noel
-------- Original Message --------
Subject: Re: Photos from the NWA Auction
From: ethan
I would figure the data center rooms and stuff might of had other racks
of
more modern server equipment that might have been sold off separately or
relocated to other sites. Didn't see holes in the floor for cabling but
wouldn't be surprised. I didn't see video projection hardware on the
auction and usually that is used to project the stuff outside the
cockpits
no?
What was left is the interesting stuff :-)
-------
There were a number of ex-NWA/Delta employees that were in the building
during the inspection phase. Talking to them, the sentiment was that
after the merger, Delta took "anything that was worth anything" and sent
it down to their facilities in Atlanta.
There were a number of simulator bays where the cockpits had been
removed, and the attendant server rooms were fairly bare. I saw a bunch
of Sun-3 "operator manuals" laying around, but no Suns. One of the guys
said they had a bunch of "old" Sun gear at one time, but that all went
south.
The PDPs and GP4 were part of what was the oldest DC-9 sim in the
country up until they walked away from it, so we were told.
I agree - the "interesting" stuff was left behind, but maybe not all of
it :-)
Steve
I read something in THE NeXT Best Thing book about Stanford col..
actually making some? or they were in on a design of some book not
handy now and my memory may also be flawed on this issue...
Ed#
In a message dated 10/20/2016 11:18:19 A.M. US Mountain Standard Tim,
wmachacek at q.com writes:
Does anyone on this list have any information on Stanford Computers? I
have
2 of them that I saved from being recycled many years ago. I have finally
gotten around to looking at them more closely. I have a model ?640? and a
model ?XT-10?. The 640 has 2 ? 5 ?? floppy drives plus a Conner CP-344,
42MB HD (the HD may have been a later add-on to the original
configuration).
The XT-10 has 1 ? 5 ?? floppy drive and a NEC D5186, 25MB HD. I could not
see a name on the MB in the 640, but the name ?80 Data? was on the XT-10
MB.
I believe these to be from the mid to late ?80s time frame. They both have
the 9 DB pin video connectors. The XT-10 has an EGA Graphics card, I could
not tell what kind of card is in the 640. I am being very reluctant to
start pulling cards on a machine this old for fear of breaking something.
The ribbon cable seemed somewhat brittle on the 640. Can ribbon cables
break due to age? If anyone has any information on these systems, I would
appreciate hearing from you. I believe this company was in the bay area
somewhere. With the name Stanford Computer, that seems very likely.
Thanks
for any information you can give me. I am in Colo. Springs.
Bill Machacek
Does anyone on this list have any information on Stanford Computers? I have
2 of them that I saved from being recycled many years ago. I have finally
gotten around to looking at them more closely. I have a model ?640? and a
model ?XT-10?. The 640 has 2 ? 5 ?? floppy drives plus a Conner CP-344,
42MB HD (the HD may have been a later add-on to the original configuration).
The XT-10 has 1 ? 5 ?? floppy drive and a NEC D5186, 25MB HD. I could not
see a name on the MB in the 640, but the name ?80 Data? was on the XT-10 MB.
I believe these to be from the mid to late ?80s time frame. They both have
the 9 DB pin video connectors. The XT-10 has an EGA Graphics card, I could
not tell what kind of card is in the 640. I am being very reluctant to
start pulling cards on a machine this old for fear of breaking something.
The ribbon cable seemed somewhat brittle on the 640. Can ribbon cables
break due to age? If anyone has any information on these systems, I would
appreciate hearing from you. I believe this company was in the bay area
somewhere. With the name Stanford Computer, that seems very likely. Thanks
for any information you can give me. I am in Colo. Springs.
Bill Machacek
-------- Original Message --------
Subject: Re: Photos from the NWA Auction
From: ethan at 757.org
Date: Tue, October 18, 2016 6:47 pm
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
> 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.
Hi Mouse -
running a museum project is fun but also a lot of work.
here is a little framework to think about and discuss Ed# at SMECC .
- SPACE
you rent or buy a building ($$$$ !)
or...
place displays in other's premises (can work if they protct your gear)
- INSURANCE
(property, liability, employee)
- UTILITIES
( winter is your enemy, summer is ours in AZ)
- SECURE FURANITURE AND FIXTURES
(when in doubt, lock it under glass)
EMPOLYEES and/or VOLUNTEERS
Great to have so you are not the only one chained to the entry desk,
employees cost $$$ volunteers no salary - either can be a
blessing or a curse if you get a bad one
In a message dated 10/19/2016 7:41:07 P.M. US Mountain Standard Time,
mouse at Rodents-Montreal.ORG writes:
There's someone local who's seen my assortment of computer hardware
twice and has, each time, told me I should set up a museum.
This is tempting, but I don't know the first thing about doing it.
About all I'm sure of is that it would involve a lot of stuff I
currently have no idea of.
I know that there are at least a few people here who've been involved
in such things. While all the examples that come to mind are in the
USA, and mine would be in Canada, I'm sure there are many respects in
which the issues are jurisdiction-independent - and, who knows, there
may be such a person in Canada that I just can't recall offhand.
So, I'm wondering if there's anyone who'd be willing to share
experiences, thoughts, issues, whatever, on the possibility.
I'm not looking to make a lot of money off this. If I can turn my
computers from money-sink to money-neutral, I'll be content. (They are
currently soaking up money in the form of causing me to be renting
significantly more storage than I would be if they were to vanish.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
> From: Dennis Boone
> The sources for the V6 versions of the tmrk et al programs seem to be
> here:
Yes, I have those, thanks; those are the 1-block programs I mentioned to
Warren:
>> The only V6 boot mechanisms are 1-block programs that go into block 0
>> of device 0 and which boot Unix directly from that file-system
Well, to be technical, also there are the programs to copy the disk images
>from tape to disk - mcopy.s does that - etc. In case anyone looks at mcopy.s
and wonders how R5 (which contains a pointer to the console print/input
routines) gets set up, mboot.s, which will have run previously (to load the
appropriate disk-controller-specific version of mcopy off the tape) does that.
One can't actually boot V6 Unix directly from a V6 distribution tape, all one
can do is copy the disk images from the tape to the disk; one then boots from
the disk. (Although now that I look, there is tpboot.s, which claims to boot
>from a file on a 'tp' format tape. But I don't think V6 was ever distributed
in that form - and in any case, it would still need a disk with a Unix file
system, with appropriate files - init, sh, etc - already on it, to be able to
boot Unix that way.)
Noel
> Here are some notes I made a while back, when I looked at it:
> ...
> Block 2-xx - gubbish, apparently inodes, code, etc?
So I just realized something's incomplete here. There's an intermediate stage
(loading 'xxyy', where 'xx' is "tm" or "ht", and 'yy' is "rk", "rp" or "hp").
Those must be in stored in that block "2-xx" area, but I'm not up for
grokking the assembler ("tpboot.s") that loads them to see how it works (it
takes a file-name, 'xxyy' as above, entered at the console).
And I got the tape files slightly wrong: mcopy.s is indeed the tape copier
program (assembled with either tm.s or ht.s, and one of rk.s, rp.s and hp.s),
to produce the 'xxyy' files above. However, the first stage booter is
"tpboot.s", not "mboot.s" (didn't look closely enough); again, assembled with
either tm.s or ht.s - that produces the first-stage bootstrap that goes in
blocks 0 and 1 of the tape.
Noel
> From: Warren Toomey
> This doc: .. describes a way to install from tape, but it seems like it
> does a block copy of a tape image to the disk.
Yup, that's the standard V6 install from tape. It uses the two programs I
mentioned in the last message; first mboot (which produces the '=' prompt),
and then mcopy (assembled with the appropriate disk and tape drivers), which
is used to copy disk images to the disk.
> Also .. there is a v6.tape.gz file. Unfortunately, I have no
> documentation on this. It could be raw blocks, or it could be a TAP
> file, who knows.
I looked into this previously. The other three files:
root.v6.tar.gz
doc.v6.tar.gz
usr.v6.tar.gz
are just TAR dumps of the 3 disk images on the V6 distribution tape: the root
(includes kernel source, and most of the binaries), usr (source for all
commands), and documentation.
The v6.tape seems to be an image of V6 distribution tape. Here are some
notes I made a while back, when I looked at it:
The first 100 512-byte tape blocks contain the tape bootstrap stuff. Blocks
100 - 4099 are the RK05 root image, blocks 4100 - 8099 are the /usr RK05
image, and the blocks 8100 - 12099 are the /doc RK05 image. .. The most
recent timestamp on any file in /usr and /doc is July 19th 1975, as with
Dennis' copy. However, the most recent file timestamp on root is October
11th, 1975
Block 0 on tape - mboot (tm tape booter)
Block 1 on tape - hboot (ht tape booter)
Block 2-xx - gubbish, apparently inodes, code, etc?
Block 98 on tape - hpuboot
Block 99 on tape - rpuboot
Block 100 on tape - rkuboot
HTH.
Noel
Hah, the file http://www.tuhs.org/Archive/PDP-11/Tools/Tapes/Vtserver/v7_standalone.tar.gz
has the source code for the standalone tools including boot and vtboot.pdp.
So, given a working V7 environment, you should be able to rebuild these
and possibly make them work in a V6 environment.
Alternatively, if you have a working V6 environment (e.g. a simulator),
you could bring in the vtclient.c code and integrate it into the V6
boot binary.
Cheers, Warren
Don't store ur tapes in a damp basement will help with sticky shed
syndrom... Keep em dry a food dehydrator helps...
On Oct 18, 2016 7:46 PM, "Al Kossow" <aek at bitsavers.org> wrote:
On 10/18/16 5:37 PM, Steven M Jones wrote:
> I think they're useful to folks who have drives that can use them, and
> they aren't nearly as fragile as QIC or helical scan drives (4mm, 8mm)
> of a similar age.
>
The drives, maybe, but the tape sheds like nuts.
From: Mike Ross
Sent: Wednesday, October 19, 2016 2:39 AM
> On Wed, Oct 19, 2016 at 7:44 PM, Pontus Pihlgren <pontus at update.uu.se> wrote:
>> Somewhat related, how much power does a 2020 draw on average?
> Bye some enormous coincidence I was just looking through some DEC
> pdp-10 brochures I have.
> DEC advertised the 2020 as drawing no more power that a hairdryer; the
> quoted figure was 1400w as I recall.
Umm, are you sure about that? That was how we advertised the Toad-1 System
in the 1990s, but the Mighty Mite power supply in the 2020 draws a lot more
than that.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.orghttp://www.LivingComputerMuseum.org/
> From: Ian S. King
>> Does anyone know anything about the status of the plans to open-source
>> it?
> I've made some inquries, stay tuned....
OK, thanks!
>> Can you briefly describe what it was?
I'm still curious about what it was: was it a stand-alone board with a
separate power supply, or did it plug into some sort of backplane? Did it use
something like SD cards for storage? And what was the MASSBUS connection
like: a set of 3 Berg headers into which one plugged the flat cables, or was
there some oddball connector that wound up connected to a standard MASSBUS
connector?
Noel
I could care less about telnet... I want to make the teletype ?clack! ? Ed#
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------
From: Rod Smallwood <rodsmallwood52 at btinternet.com>
Date: 10/16/16 18:39 (GMT-07:00)
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
Subject: Re: VCFed, the BBS!
On 16/10/2016 14:10, william degnan wrote:
> On Oct 16, 2016 5:52 AM, "Evan Koblentz" <cctalk at snarc.net> wrote:
>>> I mean? please add 110? Baud? Evan!
>>
>> I was giving examples, not carved-in-stone specifications.
> If the system is simple it'll be easier to support, 110b is not, given the
> number of persons coming in from the other end so slowly.? No one barely
> has a phone line anymore as it is, most (95%) of the external traffic will
> be telnet.? If the bbs allows those few of us with phone lines to connect
> at 300 to 1200b to get to a handshake and resolve to a simple welcome
> screen for hardware testing purposes, that would be a good start. Get that
> running see what kind of traffic results, and plan phase ii from there.
>
> I imagine it will be best once this system is up and running that people
> call in on Sunday afternoon so visitors to the museum hear the inbound
> calls in real time like a sys op would running a bbs from his basement.
> Bill
Speaking as a former Sysop from the 1980's.
What would be nice is a couple of DEC Rainbows running FidoBBS and
connected via a phone line simulator.
Enter your mail message on one and see it get transferred to the other
where it can be read.
Rod Smallwood
--
*PDP-8/e PDP-8/f PDP-8/m PDP-8/i Front Panels ex Stock - Order Now*
> From: Rich Alderson
> Yes, the d/r card is strictly level conversion, and the microcode in
> the Xilinx does all the Massbus protocol.
So if you don't mind continuing to indulge my curiousity (thanks for all the
indulgence so far :-), is the D/R card a daughtercard that mounts on the Mesa
(my guess)?
Noel
> From: Liam Proven
> It boots, and with a borrowed mouse, GUI apps work
There was a new blog post which I don't think was mentioned here yet:
http://www.righto.com/2016/10/restoring-ycs-xerox-alto-day-10-new.html
but it doesn't cover the borrowed mouse; does cover getting the CPU 100%
working, though.
Noel
I have two IBM 21F5093 AS/400 8-port twinax to DB25 adapters with clip
mounts.
Looks like the coil is about 14-16 feet of cable.
Pics on request.
Free for the cost of shipping (01888 metro-west Boston,MA , about 3 lbs
each)
Need the space, gotta go.
> From: Warren Toomey wkt at tuhs.org
> To load V6, you need to build a virtual tape which replicates the V6
> tape.
Err, there's the problem. The V6 boot tape consists of 3 'dd' images of RK05
V6 file systems (one each root, source, and doc), with a 'boot block' on the
tape which can copy them to RK05 packs; there is no standalone 'mkfs', etc.
Now, if I were willing to wait for the transfer of the entire 4K blocks, I
could use that approach, but... my only working mass storage device
(currently - more on the way, at some point) is an RX02 - much smaller. So I
_can't_ go that way, my only choice is to replicate the V7-type process
(stand-alone 'mkfs', etc), for V6.
Although I suppose I could use an emulator (I have been using Ersatz-11 to
run V6 for quite a while now) to produce a RX02-sized file system, with just
the stuff it needs to boot ('init', 'sh', etc), and use VTServer to transfer
that over. And I'd probably have to tweak the client-side code to write raw
images to disk (not sure if it already knows how to do that).
> the problem is that both "boot" and "vtboot.pdp" contain the
> client-side code to talk to the server, and it seems that I didn't
> supply the source code for this.
> ...
> Hah, the file .. v7_standalone.tar.gz has the source code for the
> standalone tools
Yup, found that some years back when I first found VTServer.
> Alternatively, if you have a working V6 environment (e.g. a simulator),
> you could bring in the vtclient.c code and integrate it into the V6
> boot binary.
The only V6 boot mechanisms are 1-block programs that go into block 0 of
device 0 and which boot Unix directly from that file-system (type a file
name, and it loads that file and starts it). So there is no second-stage boot
program to integrate the VT client into (although obviously I could port the
second-stage bootstrap to V6).
> From: Ian S. King
> I know I made it work and booted V6 on my 11/34.
I'll start with getting VTServer to run under V6 (my only Unix, don't have
anything later :-), so if you turn up whatever you used to boot V6, it would
probably still be useful.
Noel
Hi all, an early version of VTServer is still at:
http://www.tuhs.org/Archive/PDP-11/Tools/Tapes/Vtserver/
I think some others took it and extended; Fred van Kempen springs to
mind.
To load V6, you need to build a virtual tape which replicates the
V6 tape. Hopefully this is easy to do.
However, the problem is that both "boot" and "vtboot.pdp" contain the
client-side code to talk to the server, and it seems that I didn't
supply the source code for this.
I'll go home and dig through my old stuff and see what I can find.
Cheers, Warren
> From: "Ian S. King"
> ISTR that one can generate a 'tape' config file with whatever components
> you want/need.
Right, I saw that, but I need the V6 components...
> I know there are v6-specific tools somewhere ... I think it's somewhere
> in the TUHS site, and not completely obvious so you have to hunt a bit.
Any hints you could provide would be most gratefully received. I looked in the
source tree, and doing a search for "mkfs" only turned up the normal V6
mkfs. (Note that for the V7 one, the source for the standalone and Unix
versions is one file, which has #ifdefs. That seems to be the one that's in
the VTServer tree.)
I had a pretty extensive walk through the archive 'back when' I first found
out about TUHS, and I don't think I saw V6 versions (I would likely have
grabbed them, if I had); I did find (and grab) VTServer, along with a bunch of
other stuff. I just took another quick skim, couldn't find them.
I would have guessed that they didn't exist, since that whole method of
putting Unix on a machine didn't exist until V7, so it wouldn't have been
written 'back in the day'.
Noel
So, I'm trying to do what VTServer was invented for - load Unix into an actual
PDP-11, over its serial line, when one doesn't have machine-readable Unix on
any mass storage for the machine.
However, all the initial code that VTServer loads ('mkfs', etc) is V7-specific
(V6 has a slightly different file system format) - and I want to install V6.
Has anyone ever tweaked the programs which VTServer loads to do V6-format
filesystems? I did a quick Google, but didn't see anything.
No biggie if not, it won't be much work to adapt them all, but I figured I'd
try to avoid re-inventing the wheel...
Noel
> From: Rich Alderson
> There have been 2 generations of Massbus Disk Emulator (MDE) at LCM.
Thanks for the bits... very interesting.
> Data was transferred via FTP over a 100baseT crossover cable connected
> to a Slackware server; the Rabbit was able to keep up with 4 drives at
> this speed
Were the bits actually stored on the Slackware server, or was it just used to
put bits on the 'drive' to start with? If the latter, what were the actual
bits stored on? (I know, not that relevant, since this is the prior rev, but
I'm curious.)
> a Mesa 5i22 Anything I/O card (includes a Xilinx Spartan-III FPGA) that
> plugs directly into the PCI bus in a server-class X86-64 box, and used
> a revision of a separate driver/receiver card designed for MDE 1.0 to
> connect to the Massbus
Let me make sure I understand this; was there some sort of cable or somehow a
connection from the Mesa 5i22 directly to the driver/receiver card, which was
purely 'level conversion', with the Mesa doing the 'protocol' on the MASSBUS?
(I.e. they didn't communicate over the PCI bus?)
> a control program for the PC side which runs under Windows 2008/2012
> Server.
So the actual bits are stored on something (disk?) controlled by the PC?
Noel