My Apollo DN10000 is finally approaching sunlight, and hopefully will
not go back into my shop. I want to sell it.
It is a bit of a piece of work - no drives, no OS, one side cover
missing (the simple kind - the flip up types are still there). Grimy
as hell. A little surface corrosion. Maybe some missing cards.
Missing cards? They just might be empty, unused slots in the
backplane. I *think* the processor is there. The graphics card is
there, as is the I/O and memory module. The cards are not really
labeled, so I made some guesses. If there are others that are more
familiar, please contact me.
Offers entertained off list.
It is located in NY (10512), and I really do not want to ship it, but
there is a very good chance I can deliver late April/early May along
my roadtrip, hitting Indianapolis, Boulder, Phoenix, LA, the Bay Area,
and many points between.
--
Will
No. He is correct. Book was orange. Used futura
font on cover. Had computer in name. I built and
still have computer for my 6th grade project. Used
telephone dial as input. Had to substitute different
transistors. Had 10 flip-flops, each with a flash
light bulb next to them, and a complementar bulb
which I mounted in board at top of project. It
could add, or subtract, or toggle. I made this
modification by using a very cool rotary switch.
Hardest part of project, other than my two failed
rectifiers (OK, so I got it wrong, I was 11 or 12)
was de-bouncing the telephone dial. My dad had a
friend who was an electrical engineer who designed
a lot of the electronics for Lowrey organs who helped
(told me) where to change values for resistors,
capacitors, and substitute in less expensive, newer
transistors in flip-flops. Each flip flop was two
half adders.
While I am not disputing the existence or similarity
of the magazine article, heck, for all I remember the
author might have said, that this book is based on
article he read or wrote, but this book definitely
existed.
Bradley Slavik
At 16:32 -0600 3/30/07, Jules wrote:
>Anyone know if NeXT monochrome slabs have dual SCSI buses (one internal and
>one external) or not?
I think not, don't know that for sure, but have pretty good evidence
- see below.
>I've got one here that resolutely refuses to talk to any
>internal SCSI device [1], but will happily talk to (and boot from, if
>necessary) external devices. In fact, if anything is plugged into the internal
>bus at all then the system won't even boot from an external device.
I have seen a case where plugging in an external CD drive, with
passive terminator, but *leaving that drive turned off*, allows the
system to run normally from the internal drive, where it would
generate SCSI errors without the external drive in place. I didn't
have a SCSI terminator in 50-pin mini D to plug into the external
connector, but if I'd had one I would have tried it. I'd recommend
trying SCSI cable to external terminator, or cable to unpowered
external drive with passive terminator, and see whether that allows
the internal to work.
If that's productive, I'd play with the termination on the internal drive.
One other possibility is a bent pin on the internal drive or on the
connector, but I assume you checked for that.
>It'd just be nice to get to the bottom of what's
>actually broken!
Absolutely. If you do figure it out, please report back - I'd like to
know what's causing this too, if it's a generic fault.
--
- Mark, 210-379-4635
-----------------------------------------------------------------------
Large Asteroids headed toward planets
inhabited by beings that don't have
technology adequate to stop them:
Think of it as Evolution in Fast-Forward.
I've been looking at various documentation and have come up lacking in
understanding.
Can some one clue me in on the source, behaviour, and routing of the ACLO
DCLO signals on the 11/45 - with expansion boxes? In my digging in the
documentation I seem to be finding contradictions between various printed
sources and advice from people as well. Likely they are all right and I just
don't "get it".
>From what I can gather, it appears that ACLO originates in the H742 power
supply. Actually, it appears that both the upper and lower H742's produce
ACLO and DCLO. I think Tony was saying that ACLO and DCLO on the lower H742
shouldn't be used because they are referenced to -15v instead of ground. But
>from what I can gather, the only signals on the lower H742 which should not
be used because of the 15v to ground change, are LTC and +8v. The lower H742
produces both ACLO and DCLO, and does route them out for use in several
places.
It appears that ACLO originates only in the power supply, and both the cpu
and cards on the unibus monitor it to know if "death is coming". I would
imagine that the cpu uses it to trap to a powerfail routine, and peripheral
interfaces use it to do things like an emergency head unload on a disc
drive, etc. So, what about when the unibus has been extended into an
expansion box like the KB11-F with a DD11-DK, which has it's own supplies
and thus it's own ACLO? Is the ACLO failure in the external expansion box
given to the cpu chassis box and vice versa or are they entirely separate?
DCLO also confuses me. Some things I read (and advice from some people)
indicate it originates in the power supplies, and other devices only monitor
that signal. However, the unibus interfacing manual states clearly that ANY
device on the unibus can assert the DCLO signal. This would mean not just
the power supply, but a controller like an RX02 interface (M8256) could tell
the rest of the system "hey, I'm losing power".
This gets back to my "RL02 faulting upon spinup only if the RX02 is turned
on" problem. Tony suggested checking ACLO and/or DCLO. Note that my RL02 and
RX02 controllers are in the expansion BA11-K, not the cpu box. To do this, I
need to know exactly what pins to look at on the backplane. I figured I
could track this down myself, but in going through all the documentation I
am left very unclear as to exactly where the ACLO & DCLO signals go after
they hit the power distribution board (J2-J10 I think it is) at the top of
the system unit backplane. Since it is a unibus signal, I would think it
would enter the DD11-K in the expansion box at the "unibus in" (slot 1AB). I
would also guess that since (apparently) SPC cards are capable of monitoring
ACLO/DCLO (and perhaps asserting DCLO? See above?) that those two signals
would be wire wrapped from somewhere on 1AB to each of the SPC slots (C-F).
Some documentation showed ACLO and DCLO on row C (some docs show only one of
those is present) of an SPC slot. If that is the case, should I not see some
wire wrapping on my DD11-K that shows ACLO/DCLO (supposedly on B01F1 and
B01F2) getting wrapped to somewhere on row C, and daisychaining to all the
SPC slots on that same pin so they can monitor it? I do not see that wire
wrap on the DD11-DK.
So someone could just tell me what pin to check, to see if ACLO or DCLO is
acting funny around my RX02 controller. But I'd really prefer to understand
the bigger picture with it as to all places that originate these two
signals, what devices can assert them, and most importantly, how those two
signals are routed exactly from power supply to the cpu, to the expansion
box (which has it's own ACLO/DCLO), all the way to the final M9312. Then not
only could I take the measurement, but better understand what I'm seeing.
Any education is most appreciated!
Jay West
My question is which one is first on the bus.
Both are NPR/NPG DMA devices... wonder if one's screwing the bus up for the
second.
Bill
On 3/30/07, John A. Dundas III <dundas at caltech.edu> wrote:
>
> At 11:29 AM -0500 3/30/07, Jay West wrote:
> >Yes, but.... if that's the case... why does the RX02 work perfectly.
> >Separately, each one (RL02 and RX02) works just fine, boots an OS,
> >etc. But if they are both on... RL02 faults after spinup.
>
> I learned that 90% of the time it's cables; 90% of the remainder is
> power supplies. Perhaps one of the bus power supplies is marginal?
> Voltage maybe OK, current is not. Just a thought.
>
> John
>
--
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
pechter-at-gmail.com
I'm considering the launching of a VCF Southwest event, but I'd need a
local coordinator in that region to help with the planning and such.
The ideal location for the event would be Austin.
Is anyone interested in being the VCF Southwest regional coordinator? If
so, please contact me directly.
Thanks!
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
Jules Richardson wrote:
Possibly there was a firmware "feature" in the "smaller" drive which meant
the
full drive capacity wasn't being utilised, but that seems like a pretty
major
flaw in the days when a few MB here and there was precious. If not then why
someone / something (the NeXTstep installer, presumably) would format the
drive below total capacity, I don't know.
cheers
Jules
Billy responds:
Actually this was a very common thing (formatting a drive below rated
capacity). There are several reasons why you might want to do this.
1. One vendor is already qualified with a certain track count. The
next vendor has to match that track count or else a driver has to be
modified by the system provider. Easier (and cheaper) to force the disk
vendor to compensate.
2. A previous capacity point has been obsoleted, but the vendor has
committed to supply drives and spares for X many years. So a new drive is
downgraded to match the old drive, even if means wasting some disk area.
Believe it or not, this is usually cheaper too since the new drive is
further down the cost curve.
3. Performance increase. By only using the outer cylinders, you get a
drive that has more data per track so fewer seeks. And you are only using a
portion of the surface so the seeks are shorter, hence faster.
I remember a couple of times that end users discovered this and would
deliberately damage drives to get warranty replacements. The replacement
drives could give 30-50% performance improvement. (One Special case turned
a 700MB SCSI drive into a 350MB drive. It really screamed through the
benchmarks.)
Billy
A Northstar Dimension is up on Ebay, item #140097327621. I've dealt with the
seller before on VCM, and he is a good guy. This is the first picture I've seen
of the N* Dimension, and it is interesting! Right now, there are about 23 hours
left on the auction.
Does anyone happen to know where I can find a "whole disk" device file within
NeXTstep?
I was going to clone the OS drive of a mono Slab onto another (identical
model) hard disk, figuring I'd just 'dd' the contents from one to the other.
Problem is there's no obvious "whole disk" device under /dev, either for the
OS drive or the "target" drive that I'm hanging off the back of the Slab.
/usr/adm/messages gives me a couple of relevant entries:
<drive name> as sd0 at sc0 target 1 lun 0
<drive name> as sd1 at sc0 target 2 lun 0
... where <drive name> is just the vendor's ID string (Seagate ST1480N) and
the drive's firmware revision. Unfortunately there's no such files as the
obvious /dev/sd0 or /dev/sd1. There are /dev/sd0<a..h> and /dev/sd1<a..h>
files, so maybe one of those (h?) corresponds to the whole disk? (according to
'mount', /dev/sd0a is the root OS partition)
I could just pull the OS drive out of the Slab and hook both drives up to a
Linux box and 'dd' there - but I thought I'd take the route of minimum
dismantling, and of course I assumed it'd be an easy 5 minute job :-)
cheers
Jules
