DEC Minnow (KT-20)
radi...@gmail.com
I noticed that some design information to the DEC Minnow was uploaded
to bitsavers.org. I've spent a couple of days reading the schematic and
microcode.
Does any know the status of Minnow when it was discontinued? Did it
boot any OS?
I've always wanted to build a PDP-10 and this looks like a nice, clean,
FPGA target-able implementation.
Any advice would be appreciated.
Bob Doyle
Mark Crispin
> Does any know the status of Minnow when it was discontinued? Did it
> boot any OS?
My understanding is that Minnow got as far as running EDDT before it was
canceled, but it never ran any OS.
EDDT is a major milestone; but as anyone who has worked on an emulator (or
a new CPU) can tell you, about 75% of the work is still to come...
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
jmfbahciv
You might want to search for anything written by Mike Uhler that's been
put on bitsavers. I don't know if he wrote down much about some of his
design work. (Mike's first initial is G.)
And, looking at the KA stuff will give you a pretty good idea about
what a PDP-10 should do.
/BAH
/BAH
hea...@aracnet.com
> I've always wanted to build a PDP-10 and this looks like a nice, clean,
> FPGA target-able implementation.
> Any advice would be appreciated.
http://www.aracnet.com/~healyzh/pdp_fpga.html
Try to contact either Neil Franklin or David G. Conroy. IIRC, David has
managed to boot ITS on his.
Zane
radi...@gmail.com
As far as I can tell David G. Conroy booted ITS on a simulator running
his microcode, not on *real* hardware.
Bob Doyle
radi...@gmail.com
I'm encouraged -
Is this the proper forum to ask PDP-10 processor questions?
Is there an instruction set test program?
The documentation implies that the KT-20 microcode is assembled with
the MICRO2 assembler. A Google hit shows how to build CVAX microcode
using MICRO2 on a VAX.
Is there a working copy of MICRO2 or do I start from scratch?
Bob Doyle
Dave Conroy
> heal...@aracnet.com wrote:
I did successfully boot ITS on a micro-simulator for one design.
But I hated that design. So I threw it out, and did a new design. In
my tradition
of building something inspired by the oldest sensible model of the
machine I'm building,
the new design is more like the KA, but with my rendition of a KA ITS
pager. I have a version of ITS that has been modified to work with my
pager and
my devices, and which I can boot and run on a simulator (or, to be
more precise, I can
run the ROM program which can boot ITS from a virtual disk).
I also have all the logic. Like the KA, the machine is hardwired. It
executes
the whole KA instruction set, including the long format floating point
which reveals
many details of the KA implementation. The APR device is not the same
as
the KA because the trap/error conditions are different, and there is a
hack to simplify
the posting of page failures generated by XCTRI instructions in PI
routines. It runs
all of the standard diagnostics, and some custom diagnostics for the
new pager,
in the logic simulator. All of the FPGA pinouts and constraints are
done,
and everything synthesizes and times out at an acceptable speed. In
the little bits
of free time I can arrange these days I'm working out the details of
building the thing; floor-planning the pcb so the signal integrity
will be ok on
the main FPGA-to-FPGA bus, finishing up the clock and reset logic,
sizing the
1.2V and 2.5V power supplies, working on the details of the JTAG loop,
and so on.
Someday I will finish.
Tim Shoppa
wrote:
> Mark Crispin wrote:
> > On Tue, 17 Mar 2009, radioe...@gmail.com posted:
> >> Does any know the status of Minnow when it was discontinued? Did it
> >> boot any OS?
>
> > My understanding is that Minnow got as far as running EDDT before it was
> > canceled, but it never ran any OS.
>
> > EDDT is a major milestone; but as anyone who has worked on an emulator
> > (or a new CPU) can tell you, about 75% of the work is still to come...
>
> > -- Mark --
>
> >http://panda.com/mrc
> > Democracy is two wolves and a sheep deciding what to eat for lunch.
> > Liberty is a well-armed sheep contesting the vote.
>
> I'm encouraged -
>
> Is this the proper forum to ask PDP-10 processor questions?
Probably!
> Is there an instruction set test program?
There are various diagnostics for the various machines. KLAD, "Red
Pack", "KS diagnostics" are the terms.
In the end getting an OS to run requires extensive device support
which is harder to come by. The various emulator impelementations and
their trials and tribulations will be an excellent resource.
If you haven't read it, you must start with Bob Supnik's "Bug,
Feature, or Code Rot? Adventures in O/S Debugging".
I myself haved worked at the periphery of several architecture
emulations and the way that documentation meets implementation meets
schematics meets code meets OS's meets diagnostics and the way old
farts meet newbies to find common ground in the crankiness of certain
hardware/software/device combinations is a fascinating interface. And
one that resources and collaboration on the 'net (Usenet, E-mail, the
web, whatever the implementation may be in the future) has truly
enabled.
> The documentation implies that the KT-20 microcode is assembled with
> the MICRO2 assembler. A Google hit shows how to build CVAX microcode
> using MICRO2 on a VAX.
>
> Is there a working copy of MICRO2 or do I start from scratch?
Obviously MICRO2 is later than MICRO and also different than the VAX
microcode tools. I don't know where to find the version you need.
Microcode generation tools work at a lot of different levels...
there's abstractions in the languages used to describe the microcode,
there's optimizations in layout and allocation, the rigamorale of
working with text files in the language chosen, etc. A truly concept-
bridging abstraction.
Tim.
radi...@gmail.com
>>
>> Is this the proper forum to ask PDP-10 processor questions?
>
> Probably!
Good. I'll try not to ask too many stupid questions.
>> Is there an instruction set test program?
>
> There are various diagnostics for the various machines. KLAD, "Red
> Pack", "KS diagnostics" are the terms.
>
I'll file that away for later. I assume the diagnostics do not
require OS support to run. Or do I not understand.
> In the end getting an OS to run requires extensive device support
> which is harder to come by.
Minnow already has a console using a UART with lots of microcode.
It looks to me like there are all the right engineering hooks to
make debugging the hardware possible. The console commands are:
A * Address break
B Bootstrap
C Continue
D #1 #2 Deposit #2 in physical memory location #1
DI * Deposit IO
DR * Deposit RAMFILE
DV * Deposit Virtual
E # Examine physical memory location #
EI * Examine IO
ER * Examine RAMFILE
EV * Examine Virtual
H Halts the machine and prints out PC
I Initialize system
R Repeat
S # Start at address #
SH * Shutdown
SI * Single Instruction
SM * Start Microcode at uaddress
T Perform self test
^C Abort repeat, or current 1ine
<cr> ends command
^U deletes current command line
^\ Toggles console/user switch for console tty
; Separates commands
rubout deletes previous typed character
* Engineering Command (conditionally compiled into uCode)
The schematic has a disk controller although I haven't found any
IO instructions for the disk in the microcode. If worst comes to
worst, I think I can microcode PIO to an IDE disk a-la Dave
Conroy's PDP-4/x and PDP-8/x.
Are there any other devices I should be worried about?
> The various emulator implementations and
> their trials and tribulations will be an excellent resource.
> If you haven't read it, you must start with Bob Supnik's "Bug,
> Feature, or Code Rot? Adventures in O/S Debugging".
Thanks. I've downloaded it.
> I myself haved worked at the periphery of several architecture
> emulations and the way that documentation meets implementation meets
> schematics meets code meets OS's meets diagnostics and the way old
> farts meet newbies to find common ground in the crankiness of certain
> hardware/software/device combinations is a fascinating interface. And
> one that resources and collaboration on the 'net (Usenet, E-mail, the
> web, whatever the implementation may be in the future) has truly
> enabled.
I'm hoping that once things I get it executing instructions, then the
experts will help with that.
>> The documentation implies that the KT-20 microcode is assembled with
>> the MICRO2 assembler. A Google hit shows how to build CVAX microcode
>> using MICRO2 on a VAX.
>>
>> Is there a working copy of MICRO2 or do I start from scratch?
>
> Obviously MICRO2 is later than MICRO and also different than the VAX
> microcode tools. I don't know where to find the version you need.
If MICRO is used for the KS and KL microcode (and I think it is), then
MICRO2 is fundamentally different. See below.
> Microcode generation tools work at a lot of different levels...
> there's abstractions in the languages used to describe the microcode,
> there's optimizations in layout and allocation, the rigamorale of
> working with text files in the language chosen, etc. A truly concept-
> bridging abstraction.
The KT-20 micro-sequencer uses the am2910 controller. The am2910 has
a program counter and stack: it implements call, jump, loop, and return
instructions. In that respect the KT-20 microcode not very different
than any assembly language where addresses are sequentially assigned by
the assembler. The MICRO2 assembler does not need perform any "layout
and allocation".
It's quite different than the KS-10 microcode where the address of the
next instruction was determined by the assembler and is encoded into the
microcode. Because of the way the micro-sequencer implemented skips and
dispatch tables (using "wired-or" and "wired-and" logic instead of
multiplexers) it placed a lot of constraints on the addresses that
could be selected by the assembler.
Do you know for certain that MICRO2 for Minnow is not the same as the
VAX version?
> Tim.
I'm very grateful for all the input.
Rob Doyle
Ignorance is bliss. And I'm happy.
Lawrence D'Oliveiro
> Ignorance is bliss.
Bliss-36, I presume. :)
jmfbahciv
/BAH
radi...@gmail.com
<snip>
>> The documentation implies that the KT-20 microcode is assembled with
>> the MICRO2 assembler. A Google hit shows how to build CVAX microcode
>> using MICRO2 on a VAX.
>>
>> Is there a working copy of MICRO2 or do I start from scratch?
>
> Obviously MICRO2 is later than MICRO and also different than the VAX
> microcode tools. I don't know where to find the version you need.
I found the document "VAX 11/780 Microprogramming Tools Users Guide -
AA-H306B-TE" on Bitsavers.org. I'm convinced that the microcode syntax
and tool is same for Minnow and the VAX 11/780.
I'm guessing that my best bet to get Minnow microcode compiled (without
creating my own tool) is using the VAX toolset.
<http://www.bitsavers.org/pdf/dec/vax/780/AA-H306B_780uprogToolsMar82.pdf>
> Microcode generation tools work at a lot of different levels...
> there's abstractions in the languages used to describe the microcode,
> there's optimizations in layout and allocation, the rigamorale of
> working with text files in the language chosen, etc. A truly concept-
> bridging abstraction.
>
Bob Doyle
Lawrence D'Oliveiro
> I found the document "VAX 11/780 Microprogramming Tools Users Guide -
> AA-H306B-TE" on Bitsavers.org. I'm convinced that the microcode syntax
> and tool is same for Minnow and the VAX 11/780.
>
> I'm guessing that my best bet to get Minnow microcode compiled (without
> creating my own tool) is using the VAX toolset.
How much information is there available that could be used to build a
Crosscode-type solution?
Tim Shoppa
> Do you know for certain that MICRO2 for Minnow is not the same as the
> VAX version?
The only paper (well, bit) trail I see leading to a known Minnow
microcode tool is the CONVERT.EXE from BB-BL69C-SB which claims to
convert Minnow debug micro-code listings to a .RAM file. Later ones
don't call out the Minnow but do say "breadboard"... don't understand
what that means.
And to kinda reiterate the typical emulator development cycle: when
the emulator boots the OS from an emulated device and runs all your
favorite applications you know you did it good enough (well, at least
for that OS and that application and that set of devices - that's not
saying that the emulation is perfect but you probably overcame the
deficiencies in the architecture description and device behavior
etc.). Seeing as how the real Minnow never booted an OS or run an
application... how do you know you've succeeded in your goal of
cloning it? Not trying to criticize your effort, just saying that the
"money shot" has to be different at the end, so what's your money
shot?
Tim.
radi...@gmail.com
> On Mar 20, 3:20 pm, "radioe...@gmail.com" <radioe...@gmail.com> wrote:
>> Do you know for certain that MICRO2 for Minnow is not the same as the
>> VAX version?
>
> The only paper (well, bit) trail I see leading to a known Minnow
> microcode tool is the CONVERT.EXE from BB-BL69C-SB which claims to
> convert Minnow debug micro-code listings to a .RAM file. Later ones
> don't call out the Minnow but do say "breadboard"... don't understand
> what that means.
Where is that?
I found that archive but no documentation on CONVERT.EXE
I've run the microcode source PDF through an OCR. It'll be a couple
of days before I will have re-created the .MIC file. There are a lot
of 10 to IO (etc) cleanups that will need to be manually fixed.
After that, I'll be very interested in trying to compile it.
> And to kinda reiterate the typical emulator development cycle: when
> the emulator boots the OS from an emulated device and runs all your
> favorite applications you know you did it good enough (well, at least
> for that OS and that application and that set of devices - that's not
> saying that the emulation is perfect but you probably overcame the
> deficiencies in the architecture description and device behavior
> etc.).
I understand.
> Seeing as how the real Minnow never booted an OS or run an
> application... how do you know you've succeeded in your goal of
> cloning it?
In the end, I don't want to clone it. I want to use it as a
stepping stone.
I see this clearly as a two phase program:
Phase 1: Clone Minnow. This gets me 'something' relatively fast.
Make sure I understand it. Fix my implementation mistakes.
Phase 2: Hack away. Fix Minnow. Play around. If I can run
ADVENT.EXE I'll celebrate. I'd archive that design and make
the next change...
I'm just trying to be realistic. I've seen others that I respect
attempt this and not succeed. I think the Minnow architecture
(i.e., small am29xx design) gives *me* the best shot at completing
Phase 1.
I don't have a clue about what it would take to get TOPS-x
running. Realistically, I'll probably need some help to even start
Phase 2.
> Not trying to criticize your effort, just saying that the
> "money shot" has to be different at the end, so what's your money
> shot?
>
> Tim.
... at the end? It's the journey!
My goal is to learn VHDL and Verilog and have fun along the way.
I'm not sure what your concern is - Are you worried that I'll be
disappointed if I get a perfectly cloned Minnow and it doesn't
work? Are you worried that I'll never boot TOPS-x from an
attached disk drive?
As for the hardware platform, I'd like to be able to re-program the
FPGA (which would include the microcode) via USB. This will minimize
the hassle of making changes (which, for me, will maximize the
probabilitly of making changes). Something like:
<http://www.latticesemi.com/products/developmenthardware/fpgafspcboards/xp2stardevaluationboard.cfm>
This uses a little USB microcontroller to program the FPGA. This
Eval Board doesn't have enough memory - and I'd prefer ZBT RAM.
It's probably good enough for Phase 1.
I genuinely appreciate your advice and interest.
Bob.
glen herrmannsfeldt
> I'm just trying to be realistic. I've seen others that I respect
> attempt this and not succeed. I think the Minnow architecture
> (i.e., small am29xx design) gives *me* the best shot at completing
> Phase 1.
Note that the VAX 11/730 was also am29xx based. That might
be why there is a connection to VAX.
-- glen
Rich Alderson
> radi...@gmail.com <radi...@gmail.com> wrote:
Note that the KS-10 processor is am29xx-based, with no connection to any VAX.
For that matter, the sequencer in an XKL Toad-1 is an am29xx, with the rest of
the CPU based in two Altera FPGAs. The Toad-2 (unreleased) replaced all that
with a single Xilinx chip and a lot of VHDL.
So in one sense this project has already been done before.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
Johnny Billquist
> glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
>> radi...@gmail.com <radi...@gmail.com> wrote:
>
>>> I'm just trying to be realistic. I've seen others that I respect
>>> attempt this and not succeed. I think the Minnow architecture
>>> (i.e., small am29xx design) gives *me* the best shot at completing
>>> Phase 1.
>
>> Note that the VAX 11/730 was also am29xx based. That might
>> be why there is a connection to VAX.
>
> Note that the KS-10 processor is am29xx-based, with no connection to any VAX.
The am29xx was popular with a lot of designs. Not all even connected to
DEC. :-)
> For that matter, the sequencer in an XKL Toad-1 is an am29xx, with the rest of
> the CPU based in two Altera FPGAs. The Toad-2 (unreleased) replaced all that
> with a single Xilinx chip and a lot of VHDL.
Was any prototype built, or was it only simulated?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Tim Shoppa
> TimShoppawrote:
> > On Mar 20, 3:20 pm, "radioe...@gmail.com" <radioe...@gmail.com> wrote:
> >> Do you know for certain that MICRO2 for Minnow is not the same as the
> >> VAX version?
>
> > The only paper (well, bit) trail I see leading to a known Minnow
> > microcode tool is the CONVERT.EXE from BB-BL69C-SB which claims to
> > convert Minnow debug micro-code listings to a .RAM file. Later ones
> > don't call out the Minnow but do say "breadboard"... don't understand
> > what that means.
>
> Where is that?
> I found that archive but no documentation on CONVERT.EXE
If you run CONVERT.EXE with /H from that tape you can get a little
menu of choices that says:
COMMANDS TERMINATE WITH <CR>
COMMAND IS FILE.EXT/SWITCH
PDP-10 'EXT' DEFAULT IS 'SAV'
PDP-11 'EXT' DEFAULT IS 'BIN'
PDP-8 'EXT' DEFAULT IS 'BIN'
DX20 'EXT' DEFAULT IS 'BIN'
KMC11 'EXT' DEFAULT IS 'BIN'
MICRO 'EXT' DEFAULT IS 'MCR'
COMMAND FUNCTION
------- --------
FILE PDP-10 SAVE FILE TO ASCII '.A10' CONVERSION
FILE/T " DEFAULT
FILE/A PDP-10 SAVE FILE TO "SUPER" '.A10' CONVERSION
FILE/S PDP-10 '.A10' FILE BACK TO '.SAV' CONVERSION
FILE/E PDP-11 BINARY FILE TO ASCII '.A11' CONVERSION
FILE/8 PDP-8 BINARY FILE TO ASCII '.A8' CONVERSION
FILE/X DX20 BINARY FILE TO ASCII '.ADX' CONVERSION
FILE/C KMC11 BINARY FILE TO ASCII '.KMC' CONVERSION
FILE/F MINNOW DEBUG MICRO-CODE LISTING TO '.RAM' CONVERSION
FILE/K KS-10 MICRO-CODE LISTING TO '.RAM' CONVERSION
FILE/M MICRO-CODE LISTING TO ASCII '.RAM' CONVERSION
FILE/R MICRO RAM FILE ONLY, NO LISTING
/N DON'T PRINT MICRO CODE ERRORS
/H THIS MESSAGE
If you google for DDQDG you can find sources to other versions of
CONVERT.EXE but I don't think the minnow-specific version...
Now that I see the MICRO2 documentation on bitsavers it may very well
be the case that the VAX version does exactly what you need.
> I'm not sure what your concern is - Are you worried that I'll be
> disappointed if I get a perfectly cloned Minnow and it doesn't
> work? Are you worried that I'll never boot TOPS-x from an
> attached disk drive?
In fact you might define an entirely new way of debugging an
emulator :-). Many real-world emulators are by design not exact clones
of the original - because they had a goal of running the OS and
applications. Someday you'll get to those questions and may come up
with entirely nonstandard but interesting answers!
Certainly there are other microcoded -10's that are maybe not quite as
clean as the Minnow, and with those you'd have the advantage that real
OS's do run. But they're less clean in that they have Unibus, Massbus,
devices, etc. and it would seem that for most purposes a VHDL
description of that stuff would not be as interesting. It would be
interesting in that maybe you could plug in a Massbus device.... wow,
what a concept, 20+ years ago everybody was figuring out how to
migrate off Massbus!!!!
Somewhere on bitsavers I once saw some DEC corporate direction
documents indicating that ideas for mass storage for deskside micros/
minis... the devices that DEC used to fill that niche were IMHO
entirely unsatisfactory. Maybe most contemporary wtih the Minnow
would've been the 11/730 (in my head not too far off from Minnow in
terms of board count and microcoding) with R80 (not too bad) or with
RC25 (really really awful.). I think you'd be able to start with a
clean slate with a Minnow clone.
It's interesting to look at the loadable-microcode minis from the late
70's from a perspective, gees, 30 years later. The difference from
KS10 to Minnow to 11/730 doesn't seem all that huge (compared to
predecessors) although by no means are they identical.
Am I reading the M8267 schematics right, that the Minnow just like the
11/730 was intended to talk to RL02's and R80's? Pretty nifty cross-
architecture wise. The dates on the Minnow schematics seem to be 1979
which would put it well before the 11/730 chronologically... am I
right?
Geeze, now that I'm looking: IS THE 11/730 A WARMED-OVER MINNOW?
Tim.
radi...@gmail.com
I wonder if CONVERT.EXE doesn't do something different. I know that
the microcode fields in the KS-10 hardware are defined differently
(different bits) than are defined in the KS-10 microcode. Similarly,
the KS-10 microcode hardware also has ECC and a checksum that I could
never chase the source of.
This all assumes that a '.RAM' file is what's actually loaded into
the microcode RAM.
> Now that I see the MICRO2 documentation on bitsavers it may very well
> be the case that the VAX version does exactly what you need.
>
>> I'm not sure what your concern is - Are you worried that I'll be
>> disappointed if I get a perfectly cloned Minnow and it doesn't
>> work? Are you worried that I'll never boot TOPS-x from an
>> attached disk drive?
>
> In fact you might define an entirely new way of debugging an
> emulator :-). Many real-world emulators are by design not exact clones
> of the original - because they had a goal of running the OS and
> applications. Someday you'll get to those questions and may come up
> with entirely nonstandard but interesting answers!
>
> Certainly there are other microcoded -10's that are maybe not quite as
> clean as the Minnow, and with those you'd have the advantage that real
> OS's do run. But they're less clean in that they have Unibus, Massbus,
> devices, etc. and it would seem that for most purposes a VHDL
> description of that stuff would not be as interesting. It would be
> interesting in that maybe you could plug in a Massbus device.... wow,
> what a concept, 20+ years ago everybody was figuring out how to
> migrate off Massbus!!!!
OK. I'll bite. Are there any Massbus devices that still needs
running?
I've been thinking about heading the opposite direction. Maybe
adding a Wishbone interface. See:
<http://www.opencores.org/?do=wishbone>
That would get me lots of RAM, Disk, and Ethernet options.
> Somewhere on bitsavers I once saw some DEC corporate direction
> documents indicating that ideas for mass storage for deskside micros/
> minis... the devices that DEC used to fill that niche were IMHO
> entirely unsatisfactory. Maybe most contemporary wtih the Minnow
> would've been the 11/730 (in my head not too far off from Minnow in
> terms of board count and microcoding) with R80 (not too bad) or with
> RC25 (really really awful.).
Why doesn't that surprise me?
> I think you'd be able to start with a clean slate with a Minnow
> clone.
>
> It's interesting to look at the loadable-microcode minis from the late
> 70's from a perspective, gees, 30 years later. The difference from
> KS10 to Minnow to 11/730 doesn't seem all that huge (compared to
> predecessors) although by no means are they identical.
>
> Am I reading the M8267 schematics right, that the Minnow just like the
> 11/730 was intended to talk to RL02's and R80's? Pretty nifty cross-
> architecture wise. The dates on the Minnow schematics seem to be 1979
> which would put it well before the 11/730 chronologically... am I
> right?
M8627 right? But yes. The hardware is present. I don't see any
microcode to support it. Besides, I'd rather have a IDE disk
interface.
> Geeze, now that I'm looking: IS THE 11/730 A WARMED-OVER MINNOW?
>
> Tim.
There really isn't much in Minnow that is PDP-10 specific. Perhaps
just:
1. Extra 4-bit slice to make a 36-bit word size
2. Support for LH,,RH swapping.
3. Some support for indexed and indirect addressing.
4. Paging support instead of VM support.
Bob Doyle
Rich Alderson
> Rich Alderson wrote:
>> For that matter, the sequencer in an XKL Toad-1 is an am29xx, with the rest
>> of the CPU based in two Altera FPGAs. The Toad-2 (unreleased) replaced all
>> that with a single Xilinx chip and a lot of VHDL.
> Was any prototype built, or was it only simulated?
Hmm. I should have written "XKL-1 CPU" and "XKL-2 CPU" instead of "Toad-1" and
"Toad-2". Writing too fast for my own good.
Up to the time that XKL and I parted ways, no boards had been built around the
XKL-2 processor, but it had been tested in silicon via a dev board. It's been
nearly 6 years since I last heard details.
Rich Alderson
> Tim Shoppa wrote:
>> Certainly there are other microcoded -10's that are maybe not quite as
>> clean as the Minnow, and with those you'd have the advantage that real
>> OS's do run. But they're less clean in that they have Unibus, Massbus,
>> devices, etc. and it would seem that for most purposes a VHDL
>> description of that stuff would not be as interesting. It would be
>> interesting in that maybe you could plug in a Massbus device.... wow,
>> what a concept, 20+ years ago everybody was figuring out how to
>> migrate off Massbus!!!!
> OK. I'll bite. Are there any Massbus devices that still needs
> running?
The disk and tape drives on the running KL-10 and KS-10 systems around the
world?
We're putting the finishing touches on a Massbus Disk Emulator right now, and
expect to begin running it in production against the PDPplanet 2065 later this
week. This card emulates up to 8 RP06 drives to the system, with a future
development of RP07 and RM05 drives as well for the RH20 side (RH11 on the
front-end 11/40 can't handle anything faster than an RP06).
Rich Alderson
If anyone is desperate enough to care, I have a disassembly of CONVRT 0.16 (the
Minnow-knowledgeable version) which could be compared to the sources for 0.14
to find the Minnow-specific code. If you're interested, sign up for an account
on the PDPplanet Toad-1 system and include a note in the optional "Why are you
interested?" box mentioning CONVRT; if there are any takers, I'll put all this
in a publicly accessible directory instead of one of my private subdirs.
http://www.pdpplanet.org/TemplateLogin.aspx?contentId=11
I'll even answer TOPS-20 newbie questions if you have them. (NB: I do that
anyway, but thought I'd mention it here.)
glen herrmannsfeldt
> Geeze, now that I'm looking: IS THE 11/730 A WARMED-OVER MINNOW?
That is what I tried to suggest, without actually
knowing much about either.
There are many known cases of IBM reusing old hardware
in new systems in strange ways. The channels of
some later models of S/370 are actually the processors
of earlier models with new microcode.
-- glen
glen herrmannsfeldt
(really big snip)
> There really isn't much in Minnow that is PDP-10 specific.
> Perhaps just:
> 1. Extra 4-bit slice to make a 36-bit word size
> 2. Support for LH,,RH swapping.
> 3. Some support for indexed and indirect addressing.
> 4. Paging support instead of VM support.
But look at it the other way around. To convert
from 36 bits to 32 bit:
1. Remove extra 4-bit slice.
2. Remove support for halfword swapping
3. Remove support for ...
-- glen
Al Kossow
> Geeze, now that I'm looking: IS THE 11/730 A WARMED-OVER MINNOW?
>
The 11/730 disc controller looked like it was derived from the Minnow
design.
Johnny Billquist
Shelby did a MASSBUS<->SCSI adapter. Did you consider making your disk
compatible with that?
RSX only added support for that drive in the 1994-1995 time range. And
it's a variable sized massbus device, which is kindof nice, since all
other massbus devices are pretty small by todays measure.
As far as I can tell, atleast RSX calls that an RM06.
Rich Alderson
> Rich Alderson wrote:
>> We're putting the finishing touches on a Massbus Disk Emulator right now,
>> and expect to begin running it in production against the PDPplanet 2065
>> later this week. This card emulates up to 8 RP06 drives to the system, with
>> a future development of RP07 and RM05 drives as well for the RH20 side (RH11
>> on the front-end 11/40 can't handle anything faster than an RP06).
> Shelby did a MASSBUS<->SCSI adapter. Did you consider making your disk
> compatible with that?
I'm not familiar with a product from Shelby. We looked into the Setasi device
(which came out in the 1980s), but found that it would be as much work to get
it working with 18-bit drives as creating our own (or so we thought). Mike
Ross eventually acquired the Setasi IP.
> RSX only added support for that drive in the 1994-1995 time range. And
> it's a variable sized massbus device, which is kindof nice, since all
> other massbus devices are pretty small by todays measure.
> As far as I can tell, atleast RSX calls that an RM06.
In the 1994-95 time frame, I was hard at work trying to get a Toad-1 out the
door: As pre-sales customer support, part of my job was to get the engineers
to turn loose their creations, after tuning them based on input from potential
customers. (Had I come into the company a bit earlier, we'd have had real tape
support in the SCSI board--READ BACKWARDS, for instance--which an anti-tape
manager prevented getting done.)
Never heard of an RM06, didn't need to worry about RSX from 1993-2003.
Our device is a single board with lots of smarts which processes RH20 commands
on the Massbus and responds with appropriate control, status and data. The
back end is a generic FTP server with lots of disk--we're using Slackware 12.0
and SCSI, but it could be Windows Server 2008 and NAS for all we care--on
100baseT. If/when the Rabbit folks stick a GigE interface on one of their
processors, we'll upgrade the server and continue merrily on our way.
Yes, 100Mbit Ethernet is fast enough to keep up with the RH20 and RH11 (though
the latter is actually where we get stretched!).
Johnny Billquist
> Johnny Billquist <b...@softjar.se> writes:
>
>> Rich Alderson wrote:
>
>>> We're putting the finishing touches on a Massbus Disk Emulator right now,
>>> and expect to begin running it in production against the PDPplanet 2065
>>> later this week. This card emulates up to 8 RP06 drives to the system, with
>>> a future development of RP07 and RM05 drives as well for the RH20 side (RH11
>>> on the front-end 11/40 can't handle anything faster than an RP06).
>
>> Shelby did a MASSBUS<->SCSI adapter. Did you consider making your disk
>> compatible with that?
>
> I'm not familiar with a product from Shelby. We looked into the Setasi device
> (which came out in the 1980s), but found that it would be as much work to get
> it working with 18-bit drives as creating our own (or so we thought). Mike
> Ross eventually acquired the Setasi IP.
Fun. Did he get anything more from Setasi? (I'm thinking about the
PEP70/HC70 stuff.)
Unfortunately I don't have any information about the Shelby stuff,
except from comments in the RSX sources.
>> RSX only added support for that drive in the 1994-1995 time range. And
>> it's a variable sized massbus device, which is kindof nice, since all
>> other massbus devices are pretty small by todays measure.
>
>> As far as I can tell, atleast RSX calls that an RM06.
>
> In the 1994-95 time frame, I was hard at work trying to get a Toad-1 out the
> door: As pre-sales customer support, part of my job was to get the engineers
> to turn loose their creations, after tuning them based on input from potential
> customers. (Had I come into the company a bit earlier, we'd have had real tape
> support in the SCSI board--READ BACKWARDS, for instance--which an anti-tape
> manager prevented getting done.)
>
> Never heard of an RM06, didn't need to worry about RSX from 1993-2003.
Maybe not too surprised about that. :-)
> Our device is a single board with lots of smarts which processes RH20 commands
> on the Massbus and responds with appropriate control, status and data. The
> back end is a generic FTP server with lots of disk--we're using Slackware 12.0
> and SCSI, but it could be Windows Server 2008 and NAS for all we care--on
> 100baseT. If/when the Rabbit folks stick a GigE interface on one of their
> processors, we'll upgrade the server and continue merrily on our way.
>
> Yes, 100Mbit Ethernet is fast enough to keep up with the RH20 and RH11 (though
> the latter is actually where we get stretched!).
Backend sounds fine. I think I consider the fact that emulating more
existing massbus devices means emulating a fixed size, geometry and so
on. And having to pretend you have ten RP07 drives, just to use a 5 GB
drive seems excessive. That I think is a great point in the RM06 favour.
But if no other OS except RSX ever supported it, I guess the point
becomes less interesting.
David Evans
Johnny Billquist <b...@softjar.se> wrote:
>Rich Alderson wrote:
>>
>> I'm not familiar with a product from Shelby. We looked into the Setasi device
>> (which came out in the 1980s), but found that it would be as much work to get
>> it working with 18-bit drives as creating our own (or so we thought). Mike
>> Ross eventually acquired the Setasi IP.
>
>Fun. Did he get anything more from Setasi? (I'm thinking about the
>PEP70/HC70 stuff.)
>
I have a copy of a boot floppy for some Shelby thing (this
http://bcr2.uwaterloo.ca/~dfevans/pickering_b_sim/18.html
in fact) but nobody seems to want it.
--
David Evans dfe...@bbcr.uwaterloo.ca
Research Associate http://bbcr.uwaterloo.ca/~dfevans/
Computer Laboratory, University of Cambridge
Johnny Billquist
> In article <gqcvn5$nvk$1...@Tempo.Update.UU.SE>,
> Johnny Billquist <b...@softjar.se> wrote:
>> Rich Alderson wrote:
>>> I'm not familiar with a product from Shelby. We looked into the Setasi device
>>> (which came out in the 1980s), but found that it would be as much work to get
>>> it working with 18-bit drives as creating our own (or so we thought). Mike
>>> Ross eventually acquired the Setasi IP.
>> Fun. Did he get anything more from Setasi? (I'm thinking about the
>> PEP70/HC70 stuff.)
>>
>
> I have a copy of a boot floppy for some Shelby thing (this
>
> http://bcr2.uwaterloo.ca/~dfevans/pickering_b_sim/18.html
>
> in fact) but nobody seems to want it.
Do you know if the Shelby did 18-bit disks? A random synap in my brain
just fired saying that it could, but this is really stretching my memory
capabilities...
And of course, this begs the question: What happened to the hardware? ;-)
And fun, I don't think I've seen a "VAX 11/780-5" faceplate before. The
11/785 machines I ever played with said "11/785" on the front.
Nice picture, by the way.
Johnny Billquist
> David Evans wrote:
>> In article <gqcvn5$nvk$1...@Tempo.Update.UU.SE>,
>> Johnny Billquist <b...@softjar.se> wrote:
>>> Rich Alderson wrote:
>>>> I'm not familiar with a product from Shelby. We looked into the
>>>> Setasi device
>>>> (which came out in the 1980s), but found that it would be as much
>>>> work to get
>>>> it working with 18-bit drives as creating our own (or so we
>>>> thought). Mike
>>>> Ross eventually acquired the Setasi IP.
>>> Fun. Did he get anything more from Setasi? (I'm thinking about the
>>> PEP70/HC70 stuff.)
>>>
>>
>> I have a copy of a boot floppy for some Shelby thing (this
>>
>> http://bcr2.uwaterloo.ca/~dfevans/pickering_b_sim/18.html
>>
>> in fact) but nobody seems to want it.
>
> 11/785 machines I ever played with said "11/785" on the front.
>
> Nice picture, by the way.
Looking through those pictures, by the way. Interesting. How recent are
they? Looks like a nuclear facility.
Weird. The RM03 drive must obviously be hooked up to the VAX, but the
pack on top of it is marked "XXDP+".
David Evans
Johnny Billquist <b...@softjar.se> wrote:
>Johnny Billquist wrote:
>> David Evans wrote:
>>> I have a copy of a boot floppy for some Shelby thing (this
>>>
>>> http://bcr2.uwaterloo.ca/~dfevans/pickering_b_sim/18.html
>>>
>>> in fact) but nobody seems to want it.
>>
>> And fun, I don't think I've seen a "VAX 11/780-5" faceplate before. The
>> 11/785 machines I ever played with said "11/785" on the front.
>>
Yeah, that is a bit weird. And no idea about 18-bit disks nor what
became of the hardware. For all I know it's still there, chugging
away...
>> Nice picture, by the way.
>
Thanks.
>Looking through those pictures, by the way. Interesting. How recent are
>they? Looks like a nuclear facility.
>
They're from early 2004. The facility is the simulator for training
operators at the Pickering B reactor in, er, Pickering, Ontario.
>Weird. The RM03 drive must obviously be hooked up to the VAX, but the
>pack on top of it is marked "XXDP+".
>
Yeah; didn't see any -11 hardware, though it could have been
hidden...or the pack could be mislabelled. There were no other 780
cabs about so that wouldn't surprise me.
Don North
> In article <gqdn15$ag$1...@Tempo.Update.UU.SE>,
> Johnny Billquist <b...@softjar.se> wrote:
>> Johnny Billquist wrote:
>>> David Evans wrote:
>>>> I have a copy of a boot floppy for some Shelby thing (this
>>>>
>>>> http://bcr2.uwaterloo.ca/~dfevans/pickering_b_sim/18.html
>>>>
>>>> in fact) but nobody seems to want it.
>>> And fun, I don't think I've seen a "VAX 11/780-5" faceplate before. The
>>> 11/785 machines I ever played with said "11/785" on the front.
>>>
>
> Yeah, that is a bit weird. And no idea about 18-bit disks nor what
> became of the hardware. For all I know it's still there, chugging
> away...
If you look at the RM03 is also has a label on it: 'RM03-5'. There were
probably five VAX systems at one time, VAX780-1 ... VAX780-5 and this
is the only one left...
Just guessing.
Don
Johnny Billquist
> Johnny Billquist <b...@softjar.se> writes:
>
>> Rich Alderson wrote:
>
>>> We're putting the finishing touches on a Massbus Disk Emulator right now,
>>> and expect to begin running it in production against the PDPplanet 2065
>>> later this week. This card emulates up to 8 RP06 drives to the system, with
>>> a future development of RP07 and RM05 drives as well for the RH20 side (RH11
>>> on the front-end 11/40 can't handle anything faster than an RP06).
>
>> Shelby did a MASSBUS<->SCSI adapter. Did you consider making your disk
>> compatible with that?
>
> I'm not familiar with a product from Shelby. We looked into the Setasi device
> (which came out in the 1980s), but found that it would be as much work to get
> it working with 18-bit drives as creating our own (or so we thought). Mike
> Ross eventually acquired the Setasi IP.
Ah. Looked around some more, and the "Shelby" is the Setasi solution.
I guess Shelby was the name of the product then, perhaps.
If it came out already in the 80s, then I'm surprised support didn't
come until the mid-90s in RSX. But from the little information I manage
to dig up, it seem it could both emulate existing DEC devices, as well
as pretending to be a "new" device, with a massbus id of 47(8). All
depending on the personality disk, it appears.
And it's the RM06 support which appears in the mid-90s. And that's the
device which have variable size as well.
I guess that could be reverse-engineered from the RSX sources, if we'd
want to.
Johnny Billquist
Nice guess, and there might be something to it. But the "11/780-5" looks
very much like original work from DEC, while the "RM03-5" is a sticker
applied locally. (You have the DEC "RM03" identification below that
sticker.)
My guess would be that this was a very early 11/785, almost
pre-production. Or perhaps a field upgraded machine from 11/780 to
11/785? Hmm, actually I think it's a field upgrade...
But that's just muy guess. :-)
Johnny Billquist
However, to get slightly back on topic, while staying with the massbus.
Do anyone have a list, or remember which drives DEC made which could be
used on 10s?
I know for for that the RP06 and RP07 worked in both 16 and 18 bit
environment. And it's just a question of reformatting the packs.
But what other devices did? I have no clue about any of the RM drives.
And then there was the RP10(?) and RP20. I've only ever seen a few
pictures. Anyone ever used them? I believe they might only have been for
18-bit systems.
I know for the PDP-11 systems, you had the ML11, which was a ram-disk
using the massbus. That was definitely only for 16-bit systems. (Anyone
ever seen one of those?)
Any other massbus devices people know of? (Well, disks I mean.)
Mark Crispin
> Do anyone have a list, or remember which drives DEC made which could be used
> on 10s?
TOPS-20 supported: RP04, RP05, RP06, RP07, RM03, RP20, RA80, RA81, RA60.
RA82 and RA62 are labelled as "future" and their support appears to be
stubs.
With relatively straightforward modifications, TOPS-20 also supported
RM05. I ran the Panda 2020 with two RM05s and three RM03s.
> But what other devices did? I have no clue about any of the RM drives.
> And then there was the RP10(?) and RP20.
TOPS-20 definitely supported the RP20. I met systems that had those.
The RP07 took most of the wind out of the RP20 sails.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Bill Pechter
Johnny Billquist <b...@softjar.se> wrote:
>David Evans wrote:
>> In article <gqcvn5$nvk$1...@Tempo.Update.UU.SE>,
>> Johnny Billquist <b...@softjar.se> wrote:
>>> Rich Alderson wrote:
>>>> I'm not familiar with a product from Shelby. We looked into the
>Setasi device
>>>> (which came out in the 1980s), but found that it would be as much
>work to get
>>>> it working with 18-bit drives as creating our own (or so we thought). Mike
>>>> Ross eventually acquired the Setasi IP.
>>> Fun. Did he get anything more from Setasi? (I'm thinking about the
>>> PEP70/HC70 stuff.)
>>>
>>
>> I have a copy of a boot floppy for some Shelby thing (this
>>
>> http://bcr2.uwaterloo.ca/~dfevans/pickering_b_sim/18.html
>>
>> in fact) but nobody seems to want it.
>
>Do you know if the Shelby did 18-bit disks? A random synap in my brain
>just fired saying that it could, but this is really stretching my memory
>capabilities...
>
>And of course, this begs the question: What happened to the hardware? ;-)
>
>And fun, I don't think I've seen a "VAX 11/780-5" faceplate before. The
>11/785 machines I ever played with said "11/785" on the front.
It's a field installed 11/780->11/780-5 upgrade... I think there were
FCC emissions regulations that required the different nameplate...
>
>Nice picture, by the way.
>
> Johnny
>
>
>--
>Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
>email: b...@softjar.se || Reading murder books
>pdp is alive! || tryin' to stay hip" - B. Idol
Bill
--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org
Bill Pechter
Johnny Billquist <b...@softjar.se> wrote:
>Johnny Billquist wrote:
>> David Evans wrote:
>>> In article <gqcvn5$nvk$1...@Tempo.Update.UU.SE>,
>>> Johnny Billquist <b...@softjar.se> wrote:
>>>> Rich Alderson wrote:
>>>>> I'm not familiar with a product from Shelby. We looked into the
>>>>> Setasi device
>>>>> (which came out in the 1980s), but found that it would be as much
>>>>> work to get
>>>>> it working with 18-bit drives as creating our own (or so we
>>>>> thought). Mike
>>>>> Ross eventually acquired the Setasi IP.
>>>> Fun. Did he get anything more from Setasi? (I'm thinking about the
>>>> PEP70/HC70 stuff.)
>>>>
>>>
>>> I have a copy of a boot floppy for some Shelby thing (this
>>>
>>> http://bcr2.uwaterloo.ca/~dfevans/pickering_b_sim/18.html
>>>
>>> in fact) but nobody seems to want it.
>>
>> And fun, I don't think I've seen a "VAX 11/780-5" faceplate before. The
>> 11/785 machines I ever played with said "11/785" on the front.
>>
>> Nice picture, by the way.
>
>Looking through those pictures, by the way. Interesting. How recent are
>they? Looks like a nuclear facility.
Reminds me of the EAI analog simulators for power plants. I was the
DEC Field Engineer on their stuff in house and sometimes saw the Autodynamics
chemical plant simulations.
>
>Weird. The RM03 drive must obviously be hooked up to the VAX, but the
>pack on top of it is marked "XXDP+".
Interesting. Probably used as a scratch or the drive could be dual ported
to an 11 (not likely in those pictures).
>
> Johnny
>
>--
>Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
>email: b...@softjar.se || Reading murder books
>pdp is alive! || tryin' to stay hip" - B. Idol
Bill
Bill Pechter
Johnny Billquist <b...@softjar.se> wrote:
>This have drifted both from Minnows and PDP10s in general. I apologize.
>However, to get slightly back on topic, while staying with the massbus.
>Do anyone have a list, or remember which drives DEC made which could be
>used on 10s?
>
>I know for for that the RP06 and RP07 worked in both 16 and 18 bit
>environment. And it's just a question of reformatting the packs.
>
>But what other devices did? I have no clue about any of the RM drives.
>And then there was the RP10(?) and RP20. I've only ever seen a few
>pictures. Anyone ever used them? I believe they might only have been for
>18-bit systems.
>
>I know for the PDP-11 systems, you had the ML11, which was a ram-disk
>using the massbus. That was definitely only for 16-bit systems. (Anyone
>ever seen one of those?)
Yup... Installed one at NY Telephone or was it AT&T then... Pre-NYNEX.
Pre-Verizon.
They were used on the 11/70 Unix boxes used for Maintenance purposes on the
telephone network. SCAMOS, COSMOS?... one of those.
I know it wasnt SARTS. Anyway, they were a late life kicker to improve
performance by being used as a swap disk. They used the MK11/MS750
boards for memory and were run through a format program to block out bad
spots with ECC errors. Amazing to see a massbus memory box with a
controller that made it look like a disk and it even had a fault light on it.
Big performance improvement over the 11/70's alone.
>
>Any other massbus devices people know of? (Well, disks I mean.)
>
> Johnny
>
>--
>Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
>email: b...@softjar.se || Reading murder books
>pdp is alive! || tryin' to stay hip" - B. Idol
Bill
Rich Alderson
> Backend sounds fine. I think I consider the fact that emulating more
> existing massbus devices means emulating a fixed size, geometry and so
> on. And having to pretend you have ten RP07 drives, just to use a 5 GB
> drive seems excessive. That I think is a great point in the RM06 favour.
> But if no other OS except RSX ever supported it, I guess the point
> becomes less interesting.
The issue is needing to modify the monitor to accept a different disk geometry.
Since these are not "production" systems we're talking about, sticking a few
images on a disk and serving them up via FTP works for us.
I should probably mention that disks are represented as directories of track
files. A C,H,S access pulls in the appropriate track, and the data handling
processor on the board sends off the desired sector (mutatis mutandis, sends
the modified track file to the server).
Johnny Billquist
> On Wed, 25 Mar 2009, Johnny Billquist posted:
>> Do anyone have a list, or remember which drives DEC made which could
>> be used on 10s?
>
> TOPS-20 supported: RP04, RP05, RP06, RP07, RM03, RP20, RA80, RA81, RA60.
> RA82 and RA62 are labelled as "future" and their support appears to be
> stubs.
Never heard of the RA62 before.
> With relatively straightforward modifications, TOPS-20 also supported
> RM05. I ran the Panda 2020 with two RM05s and three RM03s.
Dang! I should have remembered that you used RM05s on Panda.
Did they use the same packs when 18-bit, or were there different packs?
What needed to be fixed for RM05s to work?
>> But what other devices did? I have no clue about any of the RM drives.
>> And then there was the RP10(?) and RP20.
>
> TOPS-20 definitely supported the RP20. I met systems that had those.
>
> The RP07 took most of the wind out of the RP20 sails.
Yeah, those could/can feed pretty much data. :-)
Mark Crispin
> Dang! I should have remembered that you used RM05s on Panda.
> Did they use the same packs when 18-bit, or were there different packs?
Same packs, just reformatted them.
> What needed to be fixed for RM05s to work?
Basically, just teaching the various pieces of software that know about
disk drive types about RM05: the monitor, BOOT, the formatter, and SYSDPY.
glen herrmannsfeldt
> The issue is needing to modify the monitor to accept a
> different disk geometry. Since these are not "production"
> systems we're talking about, sticking a few images on a
> disk and serving them up via FTP works for us.
I probably would have thought of doing it through NFS
instead of FTP, but either is probably fine.
> I should probably mention that disks are represented as
> directories of track files. A C,H,S access pulls in the
> appropriate track, and the data handling processor on the
> board sends off the desired sector (mutatis mutandis, sends
> the modified track file to the server).
Somehow I hadn't thought that it would be so dependent
on track geometry. IBM's MVS is very dependent
on the length of a track, as programs are allowed to
choose the blocksize for the data. With fixed size
sectors, track geometry shouldn't matter so much,
but it seems that it does.
-- glen
Johnny Billquist
> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>
>> I should probably mention that disks are represented as
>> directories of track files. A C,H,S access pulls in the
>> appropriate track, and the data handling processor on the
>> board sends off the desired sector (mutatis mutandis, sends
>> the modified track file to the server).
>
> Somehow I hadn't thought that it would be so dependent
> on track geometry. IBM's MVS is very dependent
> on the length of a track, as programs are allowed to
> choose the blocksize for the data. With fixed size
> sectors, track geometry shouldn't matter so much,
> but it seems that it does.
It matters a lot, because the massbus interface have registers for each
part. It don't express an abstract sector number. So
cylinder/head/sector is all you get from the massbus, and then you'll
have to make the calculation on what sector that should be. And so the
geometry also (obviously) matters.
jmfbahciv
> On Wed, 25 Mar 2009, Johnny Billquist posted:
>> Do anyone have a list, or remember which drives DEC made which could
>> be used on 10s?
>
> TOPS-20 supported: RP04, RP05, RP06, RP07, RM03, RP20, RA80, RA81, RA60.
> RA82 and RA62 are labelled as "future" and their support appears to be
> stubs.
>
> With relatively straightforward modifications, TOPS-20 also supported
> RM05. I ran the Panda 2020 with two RM05s and three RM03s.
>
>> But what other devices did? I have no clue about any of the RM drives.
>> And then there was the RP10(?) and RP20.
>
> TOPS-20 definitely supported the RP20. I met systems that had those.
>
> The RP07 took most of the wind out of the RP20 sails.
>
I never used one.
/BAH
jmfbahciv
> On Wed, 25 Mar 2009, Johnny Billquist posted:
>> Do anyone have a list, or remember which drives DEC made which could
>> be used on 10s?
>
> TOPS-20 supported: RP04, RP05, RP06, RP07, RM03, RP20, RA80, RA81, RA60.
> RA82 and RA62 are labelled as "future" and their support appears to be
> stubs.
>
> With relatively straightforward modifications, TOPS-20 also supported
> RM05. I ran the Panda 2020 with two RM05s and three RM03s.
>
>> But what other devices did? I have no clue about any of the RM drives.
>> And then there was the RP10(?) and RP20.
>
> TOPS-20 definitely supported the RP20. I met systems that had those.
>
> The RP07 took most of the wind out of the RP20 sails.
>
Oh, and the RS01, a fixed head disk used for swapping in really
aulden days.
/BAH
Johnny Billquist
I've used RP02 on a PDP-11. Sat on an RP11 controller. That was a whole
cabinet of its own. Lots of blinkenlights as well.
None of those disks were massbus.
How did you connect them to a 10?
Al Kossow
> I've used RP02 on a PDP-11. Sat on an RP11 controller. That was a whole
> cabinet of its own. Lots of blinkenlights as well.
> None of those disks were massbus.
> How did you connect them to a 10?
>
> Johnny
>
With an RP-10/MX-10
I have the manual scanned, it should be up under http://bitsavers.org/pdf/dec/pdp10/periph
soon
Mark Crispin
> There were also the RP01s, RP02s, and I seem to remember RP03s but
> I never used one.
Those were TOPS-10 drives. I would not even think of trying to itemize
TOPS-10 drives.
I remember both RP02 and RP03 on a KA10.
The RP02 was a 20MB drive. I forget if the RP03 was 40MB or 80MB.
Bill Pechter
Johnny Billquist <b...@softjar.se> wrote:
>Mark Crispin wrote:
>> On Wed, 25 Mar 2009, Johnny Billquist posted:
>>> Do anyone have a list, or remember which drives DEC made which could
>>> be used on 10s?
>>
>> TOPS-20 supported: RP04, RP05, RP06, RP07, RM03, RP20, RA80, RA81, RA60.
>> RA82 and RA62 are labelled as "future" and their support appears to be
>> stubs.
>
>Never heard of the RA62 before.
>
>> With relatively straightforward modifications, TOPS-20 also supported
>> RM05. I ran the Panda 2020 with two RM05s and three RM03s.
>
>Dang! I should have remembered that you used RM05s on Panda.
>Did they use the same packs when 18-bit, or were there different packs?
Sectoring on the CDC9766 was set by dip switches IIRC... so you could
set any numbers of sectors per track and the sector size would change.
All you needed to do IIRC was reformat them.
So... the 32 sector (iirc) DEC RM05 looked like this to *BSD
(the pa,pb were the Unix file system break down from the physical
drive to the logical file system partitions and blocks).
rm05|RM05|DEC RM05:\
:ty=removable:ns#32:nt#19:nc#823:sf:\
:pa#15884:ba#8192:fa#1024:\
:pb#33440:pc#500384:\
:pd#15884:bd#8192:fd#1024:\
:pe#55936:be#4096:fe#512:\
:pf#86048:bf#4096:ff#1024:\
:pg#158528:bg#4096:fg#512:\
:ph#291346:bh#4096:fh#1024:
Sectors per track=32 19 heads from the BSD disk geometry.
Looks like the PDP10 used 30 sectors and 19 heads with 572 bit sectors.
RM05 30 19 823 =256MB
ftp://ftp.stacken.kth.se/pub/pdp10/v29upd/pdp10_rp.c
>
>What needed to be fixed for RM05s to work?
>
>>> But what other devices did? I have no clue about any of the RM drives.
>>> And then there was the RP10(?) and RP20.
>>
>> TOPS-20 definitely supported the RP20. I met systems that had those.
>>
>> The RP07 took most of the wind out of the RP20 sails.
>
>Yeah, those could/can feed pretty much data. :-)
>
> Johnny
>
>--
>Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
>email: b...@softjar.se || Reading murder books
>pdp is alive! || tryin' to stay hip" - B. Idol
jmfbahciv
> On Thu, 26 Mar 2009, jmfbahciv posted:
>> There were also the RP01s, RP02s, and I seem to remember RP03s but
>> I never used one.
>
> Those were TOPS-10 drives. I would not even think of trying to itemize
> TOPS-10 drives.
<grin> Well, the question was about PDP-10s so I thought I'd
throw in my 2 cents' worth.
>
> I remember both RP02 and RP03 on a KA10.
>
> The RP02 was a 20MB drive. I forget if the RP03 was 40MB or 80MB.
One of the ways I remembered the capacity was starting with 01 and
doubling the capacity as the number increased. I don't know if
that would have worked with the 03s.
/BAH
Rich Alderson
> Looks like the PDP10 used 30 sectors and 19 heads with 572 bit sectors.
> RM05 30 19 823 =256MB
Probably 576 bits--572 is not divisible by 18.
Rich Alderson
> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>> The issue is needing to modify the monitor to accept a different disk
>> geometry. Since these are not "production" systems we're talking about,
>> sticking a few images on a disk and serving them up via FTP works for us.
> I probably would have thought of doing it through NFS
> instead of FTP, but either is probably fine.
There was already an FTP client for the Rabbit processor that does the data
handling on the board. We also like the statefulness of FTP--we KNOW that the
data is written to the disk (well, to the server, with its 4GB memory, dual
power supplies, UPS, etc. usw. ktl.) when we ship it.
glen herrmannsfeldt
> There was already an FTP client for the Rabbit processor
> that does the data handling on the board.
> We also like the statefulness of FTP--we KNOW that the
> data is written to the disk (well, to the server, with
> its 4GB memory, dual power supplies, UPS, etc. usw. ktl.)
> when we ship it.
The tradition of NFS was also that the server doesn't
acknowledge until the data is on disk. (Though with
internal disk cache that isn't always good enough.)
Some people turn off that feature.
Also, I always use hard mounts with NFS, which means
that the transfer can't be interrupted. Some also
turn off that feature.
Do you need a new TCP connection for each transfer?
-- glen
m_tho...@ids.net
> RA82 and RA62 are labelled as "future" and their support appears to be
> stubs.
The RM80 for was supported by ITS on the KS10. I would expect the
slower RM02 to work also.
Rich Alderson
> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>> There was already an FTP client for the Rabbit processor
>> that does the data handling on the board.
>> We also like the statefulness of FTP--we KNOW that the
>> data is written to the disk (well, to the server, with
>> its 4GB memory, dual power supplies, UPS, etc. usw. ktl.)
>> when we ship it.
[ snip NFS details ]
> Do you need a new TCP connection for each transfer?
No. We tune the FTP daemon to remove all timeouts. Since the MDE[1] board is
connected to a dedicated 100baseT port on the server by a crossover cable, and
the server does not reside on a publicly accessible network, this is reasonably
secure.
The Rabbit gets its configuration at startup, opens an FTP session to the
server, and sits on it forever.
[1] Massbus Disk Emulator
radi...@gmail.com
> On Mar 18, 10:57 pm, "radioe...@gmail.com" <radioe...@gmail.com>
> wrote:
[snip]
>> I'm encouraged -
>>
>> Is this the proper forum to ask PDP-10 processor questions?
>
> Probably!
I have a question about the PDP-10 timer.
Looking at the various PDP-10 implementations that I can find,
the time base is a 72-bit counter that increments at 4.096 MHz.
Therefore the top 60 bits represent time in milliseconds and the
lower 12-bits (if implemented) represent fractional milliseconds,
since 2**12 = 4096 and 4.096 MHz / 4096 = 1 KHz.
The comments in the minnow microcode state (incorrectly, I think)
that the time base is in microseconds. More correctly it is in
1/4.096 uS per LSB.
The microcode handles a 27000 Hz interrupt from the timer
hardware. Every 27 timer ticks (one millisecond), the microcode
increments the time base by 4000. I'm guessing that the time base
really should increment by 4096 every millisecond.
Here's where things don't make any sense:
The clock for the hardware runs at 20.277 MHz. A counter divides
the clock by 2167. That's nowhere near 27KHz. A divider of 751
would be exactly 27000 KHz.
Furthermore, why would you want to run the timer interrupt at
27 KHz? It just wastes micro-cycles. Was Minnow so cost sensitive
that they could afford a 12-bit counter and not a 16-bit counter
that could generate 1 millisecond interrupts directly?
Chalk this up to Minnow still being a prototype?
Bob Doyle
Mike Ross
wrote:
<snip>
>I'm not familiar with a product from Shelby. We looked into the Setasi device
>(which came out in the 1980s), but found that it would be as much work to get
>it working with 18-bit drives as creating our own (or so we thought). Mike
>Ross eventually acquired the Setasi IP.
Bzzzz. Late to the party and bringing bad news I'm afraid. Mike Ross was all set
to acquire everything left of Setasi, from John Jones - a bunch of Setasi Shelby
units (the Massbus - SCSI boxes, marketed by DEC as the ??RM10?? ??RP20??), the
development PC used to generate the code for same (including all sources, and
the design files for the board itself and the FPGAs on it), a couple of 11/70s
etc. etc.
Then Mike Ross acquired cancer, and was consequently out of the loop for a
while. By the time he was back in the loop and got round to picking up the
threads with Dr. Jones, everything Setasi had been thrown out...
So Mike will just have to have a chat with Mr. Alderson, just as soon as the new
Massbus emulator is perfected :-)
Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'
Mike Ross
>David Evans wrote:
>> In article <gqcvn5$nvk$1...@Tempo.Update.UU.SE>,
>> Johnny Billquist <b...@softjar.se> wrote:
>>> Rich Alderson wrote:
>>>> I'm not familiar with a product from Shelby. We looked into the Setasi device
>>>> (which came out in the 1980s), but found that it would be as much work to get
>>>> it working with 18-bit drives as creating our own (or so we thought). Mike
>>>> Ross eventually acquired the Setasi IP.
>>> Fun. Did he get anything more from Setasi? (I'm thinking about the
>>> PEP70/HC70 stuff.)
>>>
>>
>> I have a copy of a boot floppy for some Shelby thing (this
>>
>> http://bcr2.uwaterloo.ca/~dfevans/pickering_b_sim/18.html
>>
>> in fact) but nobody seems to want it.
>
>Do you know if the Shelby did 18-bit disks? A random synap in my brain
>just fired saying that it could, but this is really stretching my memory
>capabilities...
There's a story there. They first implemented software to support the thing on,
IIRC, RH70, RH11, and RH780. That went swimmingly. No problem. Then when they
turned to 36-bit, and tried to get it running on RH20, all hell broke loose.
They found there were so many subtle differences between different revisions and
flavours of RH20 (and perhaps also depending on the performance of the CPU it
was hung off?) that it was an absolute bitch to get working reliably. They would
get it going on one machine, and it would turn flaky on another.
By the time they had it (mostly) cracked, the market had vanished. So the 36-bit
code exists, and I have a floppy image of it, but it never got officially
released. That's the story as I recall it being told.
Hah. Just found my own web page! In DEC parlance the box was called an RP12, and
here is one:
http://www.corestore.org/rp12.htm
Mike Ross
Evans) wrote:
<snip>
> They're from early 2004. The facility is the simulator for training
>operators at the Pickering B reactor in, er, Pickering, Ontario.
Hah. Amazing what still runs there... that's the same place my 1800 came from!
http://www.corestore.org/1800-2.htm
Oh and I'd love the Setasi boot floppy, thanks! :-)
Mike Ross
>jmfbahciv wrote:
>> There were also the RP01s, RP02s, and I seem to remember RP03s but
>> I never used one.
>
>I've used RP02 on a PDP-11. Sat on an RP11 controller. That was a whole
>cabinet of its own. Lots of blinkenlights as well.
Hah. Yes, RP11:
http://www.corestore.org/rp11.jpg
For the pdp-15, there was the RP15:
http://www.corestore.org/15a-4.jpg
David Evans
Now I have to dig up the image. :) It must be here somewhere...
--
David Evans dfe...@bbcr.uwaterloo.ca
Research Associate http://bbcr.uwaterloo.ca/~dfevans/
Computer Laboratory, University of Cambridge
David Evans
David Evans <dfe...@bcr10.uwaterloo.ca> wrote:
>In article <fdadu49ek5stkdmod...@4ax.com>,
>Mike Ross <mi...@corestore.org> wrote:
>>
>>Oh and I'd love the Setasi boot floppy, thanks! :-)
>>
>
> Now I have to dig up the image. :) It must be here somewhere...
>
Found it. I seem to have
$Id: RM05 ver. 4.7 16:11:47 Mar 17 1994, Property of SETASI, INC.$
David Evans
David Evans <dfe...@bcr10.uwaterloo.ca> wrote:
> Found it. I seem to have
>
>$Id: RM05 ver. 4.7 16:11:47 Mar 17 1994, Property of SETASI, INC.$
>
...and maybe also
$Id: RM05 ver. 4.7 11:28:56 Sep 10 1999, Property of SETASI, INC.$
!!
radi...@gmail.com
>
> I noticed that some design information to the DEC Minnow was uploaded
> to bitsavers.org. I've spent a couple of days reading the schematic and
> microcode.
>
> Does any know the status of Minnow when it was discontinued? Did it
> boot any OS?
>
> I've always wanted to build a PDP-10 and this looks like a nice, clean,
> FPGA target-able implementation.
>
> Any advice would be appreciated.
>
> Bob Doyle
I've got the Minnow Processor (excluding some RS232 IO and a memory
interface) converted to VHDL, synthesized, and fit in a Xilinx XC3S500E
FPGA.
As I expected, the Control ROM and Dispatch ROM sizes heavily influence
the FPGA choice. Even then, I would categorize the XC3S500E as a small
to medium sized FPGA.
I haven't selected a memory technology. It looks like Minnow supports a
23-bit physical address. I was hoping to find a FPGA evaluation board
with a 72-bit (64-bit w/ ECC) MHz DDR2 DIMM. That would give four
36-bit words per clock cycle of the memory bus. With a memory bus that
fast, there would be no reason for a cache. Unfortunately it looks like
a big, wide DDR/DDR2 bus is fairly difficult to implement in a cheap
FPGA.
Nothing is simulated or debugged, so that is next. I'll start with the
micro-sequencer.
I've put a snapshot of the VHDL design, microcode, and some
documentation on <http://members.cox.net/doyle/>
Rob.
Paul Rubin
> I haven't selected a memory technology. It looks like Minnow supports a
> 23-bit physical address. I was hoping to find a FPGA evaluation board
> with a 72-bit (64-bit w/ ECC) MHz DDR2 DIMM. That would give four
> 36-bit words per clock cycle of the memory bus. With a memory bus that
> fast, there would be no reason for a cache. Unfortunately it looks like
> a big, wide DDR/DDR2 bus is fairly difficult to implement in a cheap
> FPGA.
Given that's a maximum capacity of 32MB or so, why not use SRAM?
Dave Conroy
packaged devices are not as nice as they seem at first blush, because
although they contain a lot of space for logic, they quickly run out
of pins if the data busses are wide (and 36 bits counts as wide).
There are a lot of pins that are input only, and a lot of pins that
less than easy to use because of their dedicated functions during
configuration.
In the end, I decided to spread my design over three PQ208 FPGAS. Each
device has 64 pins to the multiplexed system bus. The connections
between each FPGA and the system bus are the same on all three
designs, so almost everything needs to be on a bi-directional pin; the
only exceptions being the bus clock and one of the two resets (the
power-on one, not the CONO APR,200000 one). The rest of the pins are
unused on the APR device, are just enough to talk to 512KW of SRAM on
the PAG device (and slightly more than enough to talk to DRAM,
although some configuration stuff ends up on an un-natural voltage
rail), and are more than enough on the BIO (line clock, RTC, console
TTY, disk) device.
A nice side effect of putting a little logic in a lot of FPGA is that
the designs place-and-route in a blink.
radi...@gmail.com
> You are now discovering what I discovered, which is that PQ208
> packaged devices are not as nice as they seem at first blush, because
> although they contain a lot of space for logic, they quickly run out
> of pins if the data busses are wide (and 36 bits counts as wide).
> There are a lot of pins that are input only, and a lot of pins that
> less than easy to use because of their dedicated functions during
> configuration.
I've been thinking about going the other direction - a high tech, high
speed, very narrow bus. Maybe some sort of 9-bit wide Synchronous SRAM
(using a burst of four). These devices are surprisingly common.
I haven't waded though the QDR SRAM, DDR SRAM, ZBT SRAM, pros and
cons but it looks promising - only a few very high speed pins which need
special attention, and the bus only gets wide inside the chip.
I think I can get a single chip to handle the full 8MW x 36 or (32M x 9)
Main Memory.
> In the end, I decided to spread my design over three PQ208 FPGAS. Each
> device has 64 pins to the multiplexed system bus. The connections
> between each FPGA and the system bus are the same on all three
> designs, so almost everything needs to be on a bi-directional pin; the
> only exceptions being the bus clock and one of the two resets (the
> power-on one, not the CONO APR,200000 one). The rest of the pins are
> unused on the APR device, are just enough to talk to 512KW of SRAM on
> the PAG device (and slightly more than enough to talk to DRAM,
> although some configuration stuff ends up on an un-natural voltage
> rail), and are more than enough on the BIO (line clock, RTC, console
> TTY, disk) device.
> A nice side effect of putting a little logic in a lot of FPGA is that
> the designs place-and-route in a blink.
Especially nice for those of us with attention deficit disorder...
Bob.
radi...@gmail.com
> You are now discovering what I discovered, which is that PQ208
> packaged devices are not as nice as they seem at first blush, because
> although they contain a lot of space for logic, they quickly run out
> of pins if the data busses are wide (and 36 bits counts as wide).
> There are a lot of pins that are input only, and a lot of pins that
> less than easy to use because of their dedicated functions during
> configuration.
I've been thinking about going the other direction - a high tech, high
speed, very narrow bus. Maybe some sort of 9-bit wide Synchronous SRAM
(using a burst of four). These devices are surprisingly common.
I haven't waded though the QDR SRAM, DDR SRAM, ZBT SRAM, pros and
cons but it looks promising - only a few very high speed pins which need
special attention, and the bus only gets wide inside the chip.
I think I can get a single chip to handle the full 8MW x 36 or (32M x 9)
Main Memory.
> In the end, I decided to spread my design over three PQ208 FPGAS. Each
> device has 64 pins to the multiplexed system bus. The connections
> between each FPGA and the system bus are the same on all three
> designs, so almost everything needs to be on a bi-directional pin; the
> only exceptions being the bus clock and one of the two resets (the
> power-on one, not the CONO APR,200000 one). The rest of the pins are
> unused on the APR device, are just enough to talk to 512KW of SRAM on
> the PAG device (and slightly more than enough to talk to DRAM,
> although some configuration stuff ends up on an un-natural voltage
> rail), and are more than enough on the BIO (line clock, RTC, console
> TTY, disk) device.
> A nice side effect of putting a little logic in a lot of FPGA is that
> the designs place-and-route in a blink.
Especially nice for those of us with attention deficit disorder...
Bob.
glen herrmannsfeldt
>> You are now discovering what I discovered, which is that PQ208
>> packaged devices are not as nice as they seem at first blush, because
>> although they contain a lot of space for logic, they quickly run out
>> of pins if the data busses are wide (and 36 bits counts as wide).
>> There are a lot of pins that are input only, and a lot of pins that
>> less than easy to use because of their dedicated functions during
>> configuration.
> I've been thinking about going the other direction - a high tech, high
> speed, very narrow bus. Maybe some sort of 9-bit wide Synchronous SRAM
> (using a burst of four). These devices are surprisingly common.
The Spartan3E board has a 32Mx16 DDR RAM. With burst mode
that should be fast enough for a pretty fast PDP-10.
-- glen
Dave Conroy
> I've been thinking about going the other direction - a high tech, high
> speed, very narrow bus. Maybe some sort of 9-bit wide Synchronous SRAM
> (using a burst of four). These devices are surprisingly common.
>
> I haven't waded though the QDR SRAM, DDR SRAM, ZBT SRAM, pros and
> cons but it looks promising - only a few very high speed pins which need
> special attention, and the bus only gets wide inside the chip.
>
> I think I can get a single chip to handle the full 8MW x 36 or (32M x 9)
> Main Memory.
I looked at this kind of scheme as well, and could see no
problems with it (and you can actually get x9 and x18 devices) other
then the
fact that most of these devices are in 1.0mm or 0.8mm BGA packages,
which makes building the thing a little more of an adventure.
Morten Reistad
It should be feasible to build a 4MW or even bigger using SRAM
that is normally used for cache. 1.5 ns access times anyone?
The next step is to use SSDs for disk.
How fast is the FPGA anyway?
-- mrr
Dave Conroy
> It should be feasible to build a 4MW or even bigger using SRAM
> that is normally used for cache. 1.5 ns access times anyone?
Most, if not all, of the fast SRAMs you can buy today are intended to
be used
in buffers of networking equipment, rather than caches. It's pretty
rare to see
a board level cache these days. You can get enough cache in the CPU,
and you don't
have the overhead of multiple pad drivers, pad receivers, and loaded
address distribution wires.
FPGA speed is a difficult thing to describe. The raw logic is pretty
fast, but much of the programmable interconnect is dog slow, and sets
the speed.
A high end embedded processor (the kind that would normally run at,
say,
1GHz in a 65nm LP process), when crammed into the biggest, fastest,
and most
expensive FPGA you can get, runs at 30-40MHz. Simpler designs,
which have less logic, and as such, spend less time sending signals
around
on the dog slow wires, slow down less. My APR design, in a -4 or -5
speed
grade (I forget which) timed out at something like 30MHz when I just
tossed it in the tools and pressed the button. These tools can be
mind-numbingly stupid, so there's probably a factor of 2 floating
around
that I can get with some guidance and some work on the logic.
Rob Doyle
I've been making steady progress on the Minnow implementation of the
PDP-10 in an FPGA, although, as expected, it is diverging steadily
away from from the known documentation.
I've taken several detours between the last posting and now: I've
broken down and written a fairly complete microcode assembler that
groks just enough of the Minnow microcode syntax to assemble the code.
The assembler generates the VHDL code for the Control ROM and the
Dispatch ROM directly, and generates a CSV file for Microsoft Excel
where every microcode field is a column and every address is a row.
The microsequencer (including the Control ROM and Dispatch ROM) is
fairly well tested, and has been place and routed at 125 MHz targeting
a Xilinx XC6SLX16.
I'm still working on the ALU. The performance of the original design
which was implemented per the Minnow schematic (single clock
cycle) was about 75 MHz. In order to use the DSP48A1 slices on the
FPGA which have 4 nano-second 18x18 adders and multipliers), I need to
add a pipeline stage. I need to do this without breaking the
microcode compatibility. I'll probably go back and look at the
microsequencer and see what it looks like with a pipeline stage. I
guess it'll route twice as fast but require two clock cycles instead
of one. I'd be happy with a nice, clean 200 MHz to 250 MHz design.
(The PDP-11 FPGA comes in at 225 MHz).
The FPGA has several built-in DDR2 memory controllers - the SP601 Eval
board has a 64Mx16 800 MHz DDR2 RAM. As I suspected, I'll
be using a 9-bit wide memory interface. That will still get me a
16MWx36 memory (pager has 23-bit physical addressing) with a 36-bit
access every 5 nano-seconds.
I've uploaded the latest shapshot of the VHDL design, microcode,
tools, and Processor Manual to: <http://members.cox.net/doyle>
Rob Doyle.