ALSO, the unit is VERY under powered. The DEC specs say only 16 amps
<> on the 5 volts which also includes the video interface and the AVO optio
<> if you want a full screen 132 character display. I suggest that if you u
<> a Quad 11/73 with the RQDX3, you are probably OK. But not much else.
<
<I no longer need 132 columns to be fulfilled, so the AVO can be omitted.
The AVO option really doesn't draw that much power and in the overall
scheme it's far from enough.
<I'd be attempting a dual 11/73, NS 256Kb, Sigma DLV11, and CMD 220 TM SCSI.
<that doesn't work, I'll try taking out the DL and memory and using an MXV11
<though I recall those only have 32Kb or 128kb, which would make it pretty
<difficult to run RSTS/E.
That should work but the disks will have to be in their own box with their
own power. There isn't enough power there for most disks.
<Good advice for _any_ qbus system. I learned that the hard way, running 4-
<SCSI devices (2 sets mirrored) in a BA23 chassis, and wondering about the
<mysterious lockups. External drive chassis eliminated those, though cable
<lengths became very critical.
I'd limit that comment to ba23. My BA11S 11/73 has a full bus and powers
floppy and two RD52s off a custom harness.
<What I'm really hoping for is what was I think called a BA23-SE or BA11-SE
<'twas a desktop 4-slot enclosure, maybe even 4x2?
You thinking of BA11-VA, dual width by four slots, 4"x13x12 roughly.
That would work but you still need an external disk box. I have several
of those with 11/2, 11/23 cpus. The larger of them is 11/23, 256k, dlv11j,
MRV11B(tu58 boot).
There never was a ba23SE that small as the BA23 was one size (about 5
different backplane and front button combos.
Allison
A friend was cleaning out his garage this weekend and
came up with a few boxes of manuals (no software, alas)
that may be of some interest here. The manuals are free
(you pay postage) but I would like to entertain trades
for other documentation, where possible. Of course, I'll
simply accept "karma points" for later use if you don't
have anything tasty right now <g> (but I do have a good
memory...)
Contact me off-list to make arrangements. First-come
first served. Decision of the judges is final. No refunds.
Some segments may be missing.
The list can be found at:
http://www.ao.com/~go/doclist.txt
Briefly the list includes a set of RT-11 V5 orange binders,
some VT100 docs, some Emulex docs, some TSX-11 manuals
and some miscellany. (Miscellany includes a "service manual"
for an Osborne computer - I *think* Osborne 1.)
As I said, there is ONLY documentation - no software (I guess
I was too late in asking...) But at least these got saved.
If you have trouble accessing this site, let me know and I'll
email a copy of the two lists.
I've also posted my "want list" under
http://www.ao.com/~go/wantlist.txt
-Gary
>> > I think what you are looking for is the BA11-MA. Desktop 4 slot Qbus
the
>> > same approx. size as a dual TU58.
>>
>> I thought that was the BA11-VA? That's what mine say on them anyway,
>
>Yes, I thought it was the BA11-V as well.
>
>> and yeah they look very much like a TU58, but with a 4x2 18-bit
backplane.
OK you got my curiosity up as I was going by my memory. I just looked both
the BA11-V and the BA11-MA up in the microfiche as I sold the last BA11-MA I
had 6 to 9 months ago. The -MA is a quad wide, 4 slot card cage (H9270A
backplane with the H780A power supply) -MA is 115v and -MB is 230v The
other variants are -ME 115v, -MF 230v, -MH 115v w/ no logo, -MJ 230v w/ no
logo.
The BA11-V is dual wide 4 slot card cage with the H9281BA backplane. I have
not had one of these but I have had several of the -MA's.
The BA11-MA's supply looks to have a smaller footprint than the BA11-V. As
best as I can tell from the fiche. I do know the -MA's are physically close
to a dual TU58EX. At most a couple inches larger.
Dan
>I'd be attempting a dual 11/73, NS 256Kb, Sigma DLV11, and CMD 220 TM SCSI.
If
>that doesn't work, I'll try taking out the DL and memory and using an
MXV11,
>though I recall those only have 32Kb or 128kb, which would make it pretty
>difficult to run RSTS/E.
The MXV11 has 8K for the -AA and 32K for the -AC.
>What I'm really hoping for is what was I think called a BA23-SE or BA11-SE,
>'twas a desktop 4-slot enclosure, maybe even 4x2?
I think what you are looking for is the BA11-MA. Desktop 4 slot Qbus the
same approx. size as a dual TU58.
Dan
Hello fellow-subscribers,
I have some 3rd party boards around that I would love to have identified, these are probably all pulled from PDP11 systems.
Versatec Controller 122, full metal handle, one 3M connector marked "differential" (HEX)
Dataram 40871 handwritten: Assy: 65123 S/N: 107, two white handles, one 3M connector (QUAD)
ACT 10198-0 or 10197-0, (c) 1983, two white handles, two 3M connectors, one Z80A (QUAD, most likely UNIBUS)
Thanks in advance,
Erik.
Thursday was a good day. Picked up a minty fresh Apple IIe with
the 80-column vid card, and three different GRiDs.
I know something about GRiD, but would like to do a little more
research. Any pointers? One is a Gridcase 1550 (the tank with the
little roller bar instead of the trackball) which has a bad screen,
unfortunately; a GRiD 386 (similarly-built tank that has a good
screen and is happy to boot); and a 486 convertible with a good
copy of Windows for Pen and a working pen. Very, VERY well-
built little(!) units.
Any help is appreciated.
Thanks.
Paul Braun
NerdWare -- The History of the PC and the Nerds who brought it to you.
nerdware(a)laidbak.com
www.laidbak.com/nerdware
I have a few too many CBM 8032's (12" green screen, full size
non-graphics keyboard, 32K memory) sitting in my closet. Please
contact me if you're nearby, and interested in one. Will trade for
non-vintage Intel stuff.
I also have a Trimm- or Sigma- pedestal style 11/73 system with TK50,
RQDX3/RD53, RX50's. Its a beautiful piece, but I need something much
more compact, like a desktop BA23ish enclosure or VT103.
I only have 700' of living space to play with, and the aesthetics corps
is frowning.
Elmo
Here is someone with a C64 up for grabs. Please reply to the original
sender.
Reply-to: 3web(a)netscape.net
---------- Forwarded message ----------
Date: Sun, 12 Mar 2000 02:29:29 -0700
From: pop <3web(a)netscape.net>
Subject: C-64
Hi,
I have a C-64 with 1541 floppy drive, NX-1000C color
printer, lots of disks and magazines I am getting rid of. I
hate to just throw it all away, but have no further use and
need to get rid of it all. Can you help?
Walt
3web(a)netscape.net
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF Europe: April 29th & 30th, Munich, Germany
VCF Los Angeles: Summer 2000 (*TENTATIVE*)
VCF East: Planning in Progress
See http://www.vintage.org for details!
<I also have a Trimm- or Sigma- pedestal style 11/73 system with TK50,
<RQDX3/RD53, RX50's. Its a beautiful piece, but I need something much
<more compact, like a desktop BA23ish enclosure or VT103.
BA23 is not much smaller and you will not get all of that in a BA23.
The VT103 is ok, but power will severely limit the system you can build
and there is no preovision for mass storage inside. I forget the Vt103.
Also there is the BA123 {stylish end table} and that has room and power.
You'd need a Terminal for that as the VIDEO console if installed wants
a 19" tube that is huge.
Another compact PDP-11 might be the PRO350 or 380 series.
In the end it depends on what you want the system to do.
Allison
< But I've been programming under multiple platforms in C for 10 years now.
<I've learned a thing or two about writing portable code. It's surprising
<how little effort it actually takes to write portable code, but it does tak
<a different mind set that most programmers (in my experience) don't have.
For the last 15-20 years I've been trying to resolve portability. Pascal
and C were clear winners over BASIC always. Keep in mind the platforms
I was trying to hit, CPM{z80}, RT-11 and VAX/VMS and for that carefull use
of C (pay attention to what char, byte, long, double and float were) it was
portable to the limit fo doing direct IO which is never portable. Pascal
never failed to be portable as all objects were the same.
< Careful, strings in C are *character* based (what's this ``byte'' you kee
<talking about? 8-) This is one area where programmers don't quite grasp
<portability issues. While it's true that characters in C must be at least
<bits in size, that doesn't mean they *must* be 8 bits in size; an
<implementation of C that uses Unicode natively could set the size of a
<character to 16 bits (and there is also the issue of whether the character
<is signed or unsigned---a plain char declaration is unspecified---it's
<implementation dependant whether a char is signed or unsigned).
This comes out of the tradidtion of C and unix and for that char is
typically 7-9bits and is really an unsigned BYTE. The 8/16/32 world
really forced a byte to conform to 8bits.
<Intel 386 class takes a penalty if you execute 16-bit instructions in a
<32-bit segment (or vice-versa). So, to move a counted string, you have:
Gee and HLLs were supposed to hide this... ;)
You should see what Z80 code looks like from a C compiler, without the
ability to do the pointer indirection (PDP-11 does index deferred) the
z80 compiler produces a lot of horrid code that resembles some of the
RISC machines but nowhere as efficient. Yet hand coding it in z80 can be
efficient and very few instructions.
< The ANSI C spec states that the Standard C functions can be understood b
<the compiler and treated specially. At least in the 386 line, most str*()
<and mem*() functions compile to inline code and avoid the function call
<overhead (a friend of mine actually triggered a bug in GCC using nested
<strcpy() calls).
<
<> Controll of hardware ? My memory may be fading, just I can not
<> see any reference to hardware controll in my K&R copy. All
<> hardware dependant stuff is proprietary to the compiler you
<> are using. And that's the same way as for example in PASCAL
<
< True---but it depends upon how the hardware is hooked up to the CPU---is
<it memory mapped I/O or I/O mapped I/O? If the former, you just declare a
<pointer to the memory location (mapped to the appropriate size) and go. I
<it's I/O mapped I/O there is probably a wrapper function that the compiler
<knows about and can inline.
K&R C assumes the operators are part of the OS and the language interacts
with the OS for IO. That is a useful concept for nonsystem programming or
end applications. Totally meaningless for driving a A/D card. however,
the right way to do that is to package and isolate the IO so you can use
standard C conventions to interact with the device. This keeps the mainline
code portable.
< But C (the actual language) never defined built-in IO functions, leaving
<I/O to subroutines (or functions). WRITELN is a language element of Pascal
<but printf() is just a function. Depending upon your view, that is either
<good thing or a bad thing (I think the lack of I/O statements in C is an
<elegant solution myself).
Despends. For a application that does standard IO to user and filesystem
Pascal or C {stdio} works fine. If your doing mixed IO to a A/D card and
present results to the user C looks nicer in code but Pascal handles that
effectively. Both fail when the IO is speed critical, say the nondma
floppy of a 200mhz or slower PC or when we are down in the mud of a Z80 or
8051.
<> Things like messing up the whole programm by one wrong ; or }
<> (something impossible on Assembly) or easyly produce memory
<> leaks (hard to do on other HLL).
Thats simple syntax and rules checking. C allows the naster conversion
of datatypes. I've been burned by longints and ints in pointers to
whatever.
< Depends upon what you're used to. Pascal uses those pesky semicolons as
<well, along with those annoying BEGIN and END statements. Assembly on the
<other hand, is fairly structured and tend to avoid the cascade of errors
<prone to compilers (although Microsoft's MASM is also prone to cascade
<errors).
I don't know if that doesn't exist in all of them. I've been smacked
around gross stupidity in ASM, MACRO, PAL, C, PASCAL, BASIC and yes even
fortran. All of them will go off the end of a structure that is pointed
to and hurt something sacred if you care to.
< You're not using C then. While it's possible to do:
<
< char *pd = destpointer;
< char *ps = srcpointer;
<
< for (i = 0 ; i < sizeof(somestruct) ; i++)
< *pd++ = *ps++;
On some system this produses different code (usually bigger)
on say z80 this will produce discrete code that is a monster.
< That's going about things the hard way. Why not:
<
< memcpy(destpointer,srcpointer,sizeof(somestruct));
Than this. Z80 library has enough smarts to use the LDIR/LDDR instruction
that is fast and efficient.
< Or even:
<
< *destpointer = *srcpointer;
Unpredictable how the compiler will do it even if it works.
This can be horrendus!
< One thing---I can't write Assembly on linus.slab.conman.org (an AMD 586)
<and have it run on tweedledum.slab.conman.org (68040). C at least lets me
<write code that will run on both machines.
As would pascal, ADA, basic{maybe}, fortran and heaven help me COBOL.
I find that as the machine gets smaller and resources are less prodigious
the progression is BIG HLL--> smaller language--> ASM, like Pascal, C and
then ASM.
Allison