Announcing: ACCRC Seald-Bid Auction Lot #2
*** This is the last notice that will be sent to the general VCF
mailing list. To ensure you receive further updates regarding this
auction, please visit the VCF website and click the "Mailing List"
link in the navigation tab on the right-hand side or bottom of any
page. Then click on the link to update your contact information and
follow the prompts from there to get into your profile. You should
then select which announcements you want to receive. If you don't
want to receive any more of these auction notices, select "Major
announcements and newsletter only". Otherwise, select "Send me all
VCF announcements".
The Alameda County Computer Resource Center (ACCRC) is forced to
liquidate its computer museum due to the current economic climate.
The VCF has been contracted to auction off the ACCRC museum to raise
needed funds for their non-profit operation.
I have put up the second batch of machines at the following URL:
http://www.vintage.org/special/2008/accrc/
In order to use the system you must have a VCF Community ID. Getting
one is simple: just follow the links and prompts when you visit the
URL above and read the instructions.
The closing time for this lot is Monday, January 5, at 12:00PM PST.
New lots will be posted by noon every Monday on a weekly basis until
all items are depleted. At this rate we expect 4-5 more lots.
ACCRC Sealed-Bid Auction Lot #2
## Description
-- -------------------------------------------------
16 Kaypro 2X
24 Kaypro 1
42 Eagle II
43 HP 41CV Calculator
44 JC Penny Video Sports
45 Timex-Sinclair 1000
46 Stratus V101 Dumb Terminal
47 HP 85
48 Tandy Color Computer 3
49 Calcomp Drawing Board
50 Atari 2600 Video Computer System
51 Tandy CCR-82 Computer Cassette Recorder
52 Generic Lunchbox Portable
53 Atari 830 Acoustic Coupler Modem + 850 Interface
54 Magnavox Odyssey2 Console
55 Commodore Amiga 500
56 GRiDPad 1900
57 Compaq Portable
58 Platinum Apple IIe
59 Processor Technology Sol-20
60 Non-Linear Systems Kaypro 10
Check the item listings at the link above for further information and
details.
All items must be sold. No reasonable offer will be refused. Your
purchases will go towards supporting an organization that over the
years has provided nearly 20,000 refurbished computers to needy
organizations and individuals worldwide. 100% of the proceeds of this
auction will go directly to the ACCRC (minus the handling fees, which
are covering my time...barely).
Best regards,
Sellam Ismail
Proprietor
Vintage Computer Festival
http://www.vintage.org
Ok. To start with the short version. Get back when you really want more
details.
The deal is to fake the MK11 so that it thinks there are four 256KB
cards when you have a 1MB card.
The memory bus is pretty simple. You have address lines, and card select
lines. Address lines are as usual.
Card select lines are like chip selects, or whatever you are used to in
terminology. It selects which card should respond when address and data
and other control signals are on the bus.
Usually only one card select line is active at a time.
So you have three things to deal with:
. Address lines
. Card select lines
. ECC
Address lines are pretty simple. You grab four card select lines, hook a
4-to-2 binary multiplexor in there, and you get A18,A19 from those. This
means that four adjacent cards will cause A18,A19 to be generated.
Card select lines are even simpler. You just OR the four card select
lines together, and output it on one of them. I seem to remember that
you don't need to cut anything on the backplane, but check that to be
sure. Also, you need a total of four of these special cards in order to
get 4 MB working in the MK11, but all four cards will be identical.
With that, the hardware side is done. Now, the one part left is a bit
more tricky, but it's a hardware problem with a software solution.
The MK11 (as well as the 11/750) have ECC memory. In order for the
memory to not scream bloody hell when you access it, the syndrome bits
must be set right. At power up, the MK11 initialize the syndrome bits
for all memory in the box, but it does this in a really clever way. It
runs though all addresses and do a write to them, forcing the ECC
syndrome bits to be updated.
*But*... It does this on all cards in the box in parallell. That is, all
card select lines are active at the same time, at this one instance.
The problem with that is that (obviously) not all the memory in the 1MB
memory board will be reset. By designing your small adapter card the
right way, you can get atleast the first 256KB ECC syndrome bits set
right. The rest you'll have to do by software instead, before the memory
can be used. Otherwise you'll just get parity errors if you try to
access that memory.
And, normal writes to memory won't work! The memory is 32 bits wide, and
a normal write from a PDP-11 will only write 16 bits, so it won't cause
the memory to do a blind write and just set the syndrome bits.
If you read the documentation for the MK11, you'll find that it actually
have a CSR as well, and in that, you can set bits to force writing the
syndrome bits and ignore errors. And for the initialization that's what
you need to do: set the right bits in the CSR, write to all memory
needed, and then reset the CSR again.
The last "funny" thing with this is that the CSR isn't easy to access.
All accesses to the I/O page in an 11/70 will cause the reference to run
out on the Unibus (not surprising). However, the MK11 isn't on the
Unibus. :-)
The trick is to realize that the Unibus map will always direct the
access to the memory bus, even if the final address is in the I/O page.
So, you need to setup the Unibus map to point to the I/O page, and then
access the MK11 CSR through the Unibus map.
After that, you're all done, and the MK11 with 1MB memory boards will be
happy. I've done it in the past, and it really not any more complicated
than that.
Johnny
"Ethan Dicks" <ethan.dicks at gmail.com> wrote:
> On Fri, Dec 26, 2008 at 9:35 PM, Dave McGuire <mcguire at neurotica.com> wrote:
>> On Dec 26, 2008, at 9:26 PM, Ethan Dicks wrote:
>>> Also, I should check the memory in it - ISTR it's limited to 5MB.
>> I think 5MB is correct. And don't they use the same memory array boards as
>> the PDP-11/70?
>
> Yes... same 1MB boards in the 11/70, 11/730, 11/725 and 11/750.
Nope. The MK-11 memory box for the 11/70 (there are others) have the
same memory bus as the 11/750, but the MK-11 don't support 1MB boards.
Believe me, I know...
256 KB memory boards works fine in both MK-11 and 11/750 though.
And if someone *really* have 1MB boards, and an MK-11, and wants to use
them, contact me and I can start explaining what you need to do to
actually get it to work. But it requires both serious hardware hacking
and software fiddling.
Johnny
On Sat, Dec 27, 2008 at 11:39 AM, Dave McGuire <mcguire at neurotica.com> wrote:
> On Dec 26, 2008, at 11:04 PM, Bob Armstrong wrote:
>>
>> I've also got a 11/725 that's in good shape except for a few missing
>> pieces of sheet metal, but like Ethan I've no working RC25 drive.
I don't know about the state of your drive, Bob, but mine is merely
missing a cartridge so I can't spin up the fixed platter. For those
that might not know, the RC25 is 25MB/25MB removable on one spindle.
I think the original idea was that you would put VMS on the internal
platter and swap out the cartridge for either backup/restore, and
perhaps installs, but in practice, VMS got large enough fast enough
that you really needed all 50MB for the OS and a few user dirs.
You _can_ fit 5.0 on it, I've seen it, but 4.x is a better fit.
>> A UNIBUS SMD controller is an option - there are some small 8" SMD disks that mist
>> just fit inside the chassis in place of the RC25 - but a UNIBUS SCSI
>> controller would be a better way to go, since it'd be no problem to fit a
>> SCSI disk in there. Unfortunately neither SMD nor SCSI UNIBUS controllers
>> are easy to come by.
>
> 5.25" SMD drives do exist; Seagate (and possibly others) made them. I had
> a few at one point (1990?) but no more. I know someone who has some but I
> doubt he'd turn loose of them.
I know I've seen SMD-E drives in 5.25" form-factor, but I don't know
if SMD-E drives are happy on an older SMD controller (despite using
SMD drives since 1984, I really don't know lots about their
limitations - I only ever worked with a couple of combinations that
were known to work - I never had to match up settings and cables,
etc., on random configurations as I later did plenty of times with MFM
and ESDI).
Given the drives I do have on hand, I would, of course, love to have a
Unibus SCSI controller (or 3-4 or them, really), but they were really,
really rare back in the day. Every once in a while, I entertain the
idea of turning old COMBOARDs into some form of disk controller (IDE
or SCSI would be the easiest), but I never get past the napkin stage
of designing. What would be far more practical would be an Unibus
ESDI controller, but I don't remember seeing too many of those in the
past (what I did see was "lots" of SMD for Unibus and SMD or ESDI for
Qbus - all popular for those that were happy enough with non-DEC
controllers).
It all comes down to drivers. 2BSD I know can handle Emulex and other
controllers just fine. I'm not as certain about Ultrix-32 (it seemed
to be heavily slanted towards a DEC system disk, at least). I recall
a variety of releases of VMS drivers for SI and Emulex controllers, so
it would be handy, I'd say, to identify what OS and version targets,
seek out ancient driver install kits _then_ go looking for a suitable
controller, but I think in practice, it'll be a case of finding a $50
card and then looking for drivers.
It's this struggle that makes me start to envision what it would take
to turn a COMBOARD into a low-performance disk controller. I say "low
performance" because no matter how one would reasonably hack on the
existing hardware, and though it has a Unibus DMA engine (the 18-bits
of the Unibus are mapped into 1/4 of the memory space of the onboard
68000, so DMA cycles are as easy as a DBcc loop), it's programmed I/O
>from the 68000 side, limiting the max transfer speed to about
200KB/sec. You _could_ stick a disk on it, but it really was designed
as a communications controller. Since you'd have to write the drivers
>from scratch anyway, one might as well start with something that's
_meant_ to talk to disks. I only keep coming back to the idea since I
have a stack of working boards on the shelf and I have 100% of the
engineering info on them (and all the rights).
Thinking of COMBOARDs, ISTR someone (more than one?) on the list found
a COMBOARD in a machine they picked up some time back. I am still
trying to recreate our old test/development environment with simh, but
I'm lacking in a way to bootstrap a simulated 11/780 with VMS 4.x.
Once I get around the issue, I have backup saveset files made from the
last days of Software Results I can restore - all of the source and
tools and textual docs are there, and I'd be able to "cut a tape" of
the install kit for a variety of OSes and COMBOARD products. This is
assuming anyone still wants to talk HASP or 3780 from a real Unibus
box, of course. That's what the board did, and it did do it well.
The disk-controller idea is just something I kick around from time to
time.
-ethan
--- On Sat, 12/27/08, Michael B. Brutman <mbbrutman-
cctalk at brutman.com> wrote:
> I think the best idea at the moment is the conductive ink
> used to fix circuit board traces. I'm going to give
> that a shot - there is a trip to Rat Shack in my near
> future.
To repair keyboards in the past I've picked up a cheap calculator (<
$1) at the dollar store, cut out the conductive pads from the keys,
and pasted them in place of the hardened, non-operational pads. Works
for me...
CRC
I've just purchased a Brian Instruments Brikon 723/4M-QT floppy drive
tester. I've wanted one of these for quite some time, and was pretty
happy to find one on ebay for $20+$23 s/h.
Anyone have a manual? Anyone know what the difference would be from
723B vs 723/4M-QT ?? What's the 4M part? The QT?
Any info would be helpful!
Thanks
Keith
"Ethan Dicks" <ethan.dicks at gmail.com> wrote:
> On Sat, Dec 27, 2008 at 1:29 PM, Bob Armstrong <bob at jfcl.com> wrote:
>>> Ethan Dicks wrote:
>>> I don't know about the state of your drive, Bob, but mine is merely
>>> missing a cartridge so I can't spin up the fixed platter.
>> I've got cartridges, but I really, really, (_really_!) doubt that it'll
>> make your drive work. RC25s were notoriously unreliable even when they were
>> new, and as unsealed (even the fixed platter is open to the air) drives they
>> just don't age well at all. I've got two RC25 drives (well, maybe even
>> three but that's another story) and none will work. I spent a couple of
>> weeks working on them once, and all will now try to spin up and then fault
>> with various error conditions (I've since forgotten the error codes -
>> sorry).
>
> I've owned two 11/725s over the years. As I've posted before, I've
> never had the problems with the RC25 that others report. I know they
> are notorious, but _I_ never had one fail. That being said, of
> course, the chances of mine working are now diminished merely because
> I've said something. ;-)
:-)
I haven't even seen an RC25 in 20 years... But they worked back then.
But then again, I was working at DEC at the time, and needed them for
the work I was doing, so I guess had they failed, I would just have
gotten another one. :-)
>>> Every once in a while, I entertain the
>>> idea of turning old COMBOARDs into some form of disk controller (IDE
>>> or SCSI would be the easiest),
>> Another option would be to build something that plugs into the LESI (aka
>> Aztec) controller and pretends to be a disk. That'd be way cool. But I've
>> never seen any documentation on the LESI interface, either electrical or the
>> protocol, so I've no idea how hard that would be. As long as the interface
>> remains undocumented, I'd guess "really hard". And of course the LESI
>> interface wasn't very popular (it was only ever used for the TU81 and the
>> RC25) so the potential market, outside of you and me, is limited :-)
>
> Yes... that would be an interesting way to go, but as you point out,
> lack of documentation makes that an unlikely path.
Don't the TK50 also use LESI?
Or did I just imagine that?
>> The important thing is that whatever you come up with has to be close
>> enough to a standard MSCP controller so that you can boot it with the
>> standard DU bootstrap and so that VMB can talk to it. Unfortunately some of
>> the third party SMD controllers weren't really MSCP compatible and needed
>> custom bootstraps and VMS drivers (we used to have an SI controller on a 780
>> that fell into this category) - those would be a problem unless a) you can
>> also recover the software (difficult), and b) they supported a 11/730 (even
>> more unlikely!). The LESI approach at least avoids this problem.
>
> Agreed. OS driver support is always foremost in my mind when fiddling
> with 3rd party disks. We always had to wait for SI to release driver
> patches for our SI9900 since a Fuji Eagle is not the same size as any
> DEC disk (in our case, they would patch the geometry table in
> DRDRIVER.EXE to "oversize" the RM05 entry since we didn't have any
> real RM05s on the system).
>
> It sure would be nice to find a Unibus SCSI card that looked to the
> system like a UDA50 - i.e. - true and proper MSCP emulation. I don't
> know if there ever was such a product, but the VAXBI ones I saw years
> later were $10,000 new. :-(
There are/were several. I have a CDU-720/TM. That's CMDs Unibus version
of the CQD-220. Very nice. Works about the same way as the CQD too.
I also have a Viking one, but that only talks TMSCP (but I'm pretty sure
they did exist for disks as well).
>> Of course if you only want to run Un*x then you have more flexibility :-)
>
> True, and I _do_ care about Unix (2BSD for PDP-11 and Ultrix-32 for
> VAX), but I also care about RT-11 and pre-6.0 VMS.
>
> Just thinking back to when I used to do this every day for a living, I
> don't recall there ever being an ideal solution, just solutions that
> fit enough criteria to be acceptable (Re: price-compatibility-capacity
> matrix). If you had money, you paid for DEC disk. If you had a no
> budget, you bought 3rd party and decided what features to give up (the
> ability to seamlessly install the OS and upgrade at will was almost
> always the first thing to go).
>
> Not all of the "good old days" were as good as we'd like to remember.
Sure they were!
But as far as disks go, until good MSCP emulating controllers came out,
it was always a headache with 3rd party disks and controllers.
Johnny
Merry Newtonsday, Christmas, Yule, Midwinter, Winter Solstice or whatever
you choose to celebrate to members of the classic computer list and their
families.
-tony
