This has been relisted several times already, and I imagine the owner is likely to scrap it if it doesn't sell.
http://www.ebay.com/itm/s/380869476221
--Bill
Some time back (too long ago to remember, which lately means > 2
months) I purchased a set of slides marked "(C) Digital Equipment
Corp." They were stuffed in a drawer and forgotten until recently,
when I dug out my slide scanner for a different job. Thanks to
inertia, the scanner stayed where it was and I scanned in the DEC
slides as well. Nothing cohesive here and completely lacking context
but I thought the DECfans among us might find them interesting. They
appear to be part of some sort of training materials:
http://silent700.blogspot.com/2014/03/and-some-more-slides.html
Enjoy!
-jht
--
silent700.blogspot.com
Retrocomputing and collecting in the Chicago area:
http://chiclassiccomp.org
I have five DEC 3000 series machines that came along with a batch of other items. They do not interest me, and I think that their present monetary value per unit weight is low. Model numbers vary, installed cards vary, and I haven't opened them up or studied them carefully. Paint is scratched up and on some of them the vinyl feet have turned to sticky goo. I want them gone, but I'd prefer not to scrap them. These are just the main boxes, with no keyboards, monitors or cables. One of them looks like it has some sort of fiber optic interface card installed. Some look like they have graphic boards installed, some don't. At least one of them appears to have a CD ROM drive.
Does anybody want them? I'm not interested in packing or shipping them. I'll give them away free if you come pick them up at my home in Riverside on a weekend (note, rough dirt road... truck recommended), or sell them for $4 each if I need to load them back up in my truck and bring them to my workplace in Irvine for a weekday pickup. :)
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
Servicing a DECstation 5000, I found this old CAD, Matra Euclide-IS.
I managed to make it start: it use a proprietary DB to store objects.
The problem is this: I can retrieve stored objects (the equivalent of
drawings), but haven't figured out how to display them :P
Menus are not so obvious.
I mean that it loads the drawing with no errors, and I saw only the axes
on the graphic screen.
Tried to recalculate, changed view...
Created a drawing by myself: saved it.
On reopening, it happens the same.
I checked the database, and objects are there...
I'm missing something: did you ever use it?
Thanks!
From: Philipp Hachtmann <hachti at hachti.de>
>No more bus driver discussion, PLEASE!
>Throwing up this bus driver thing again and again
>discourages people.
--- Philipp, I hope you will permit me to answer criticism. I think that if we keep it cordial and constructive, it will serve the useful purpose of answering concerns about Omnibus interfacing. I can show that, in fact, the interface approach being used is completely compatible with DEC Omnibus interface practice.
From: Eric Smith <spacewar at gmail.com>:
>Now consider the same question if the vendor explicitly claimed that it did
>meet the specification, and put on their web site a well-intentioned but
>flawed analysis of that claim. Would you complain about someone that
>pointed out the flaw in the analysis?
--- Hi Eric,
As I pointed out before, I didn't claim in the article that the receivers meet "Omnibus specifications", only that I judged it to be close enough. (The transmitters easily exceed DEC practice.) I apologize if the way I originally presented it was confusing. One of the problems with establishing compatibility with Omnibus specifications is that no comprehensive Omnibus specs have turned up so far. Instead, we have to look at actual DEC design practice.
Since you raised concerns about it, I have rewritten the section to clarify the matter. In doing so, I did additional research which revealed that DEC used various ordinary TTL gates as Omnibus receivers on many occasions. There is a list of twelve citations, involving 58 Omnibus connections, which documents this practice. TTL gates used include 74H87, 74H04, 74153, 7404, 7412, 7439, 7410, 7430, 7474, and 74H11.
These were employed for timing signals, control signals and for data buses. This list is by no means comprehensive, since I only spent a short time searching schematics. No doubt, we could find many other instances. You can see the full table at: http://tronola.com/html/ram_for_pdp-8e.html#Secret
The conclusion from this table is that DEC certainly regarded standard TTL input specs as adequate for an Omnibus receiver. Moreover, the specs on the Omnibus interfaces of the 32K RAM board are as good or better than the cited DEC instances. Since quite a few of these instances involve critical signals of CPU cards, we can say that virtually all PDP-8/e, f and m systems have receivers with standard TTL interface characteristics. Thus, there is no reason to suspect that there will be any limitations in using this design, relative to existing DEC hardware.
I appreciate your giving me an opportunity to clarify things and to hopefully lay to rest, any concerns about the interfaces.
Steve Lafferty
Yes I would be very interested in any Targa related files being placed up for download, thank you Kelly.
I also have been searching for Topas or any of the old utilities listed in the software manual
Cheers
Ryan May
Hello, all,
This morning I did some looking at my RK8E boards, and it appears that
it has been ECO'd to make a change to the clock generation logic for the
Current Address Counter.
This ECO supposedly helped with the issue, but apparently it isn't good
enough for this RK8E to work properly in my 8/e.
I tacked in an extra probe wire to the least significant bit of the
Current Address Counter on the RK8E.
I put things back together, and toggled in my little test program that
loads the Current Address Counter with 0, then loops on itself to
generate scope traces.
When I ran the program, it was instantly obvious that the counter is
indeed incrementing due to the transient in the clock signal.
The LSB of the counter goes to logic 0 for a short time (as a result of
the load operation), then pops up to logic 1 due to the transient
causing a count cycle on the 74161 counter.
You can view the traces here:
http://pail.bensene.com/RK8ECounter.jpg
The top trace is the LOAD signal into the counter, the middle trace is
the CLK signal into the counter, and the bottom trace is the LSB of the
counter.
It's clear that when the CLK signal goes high (the clock triggers on the
positive edge) after the transient, the counter counts up one, causing
the LSB to go to 1.
As David Humphries mentioned, it appears to be a design flaw in this
clock generation circuitry that, depending on small timing variances in
different machines, causes this transient to be generated, messing up
the operation of the RK8E.
A couple of different signals from the master timing of the PDP 8/e are
used to generate this clock signal, and it could be that one of these
signals on my machine is slightly off due to variances in propagation
times in gates and flip flop timing chains that manifests this weakness
in the RK8E Current Address Counter clock circuitry.
The machine where the RK8E was tested as good may have had slightly
different timing that either rendered the transient too short to trigger
a count, or eliminated it completely.
The next step is to try to figure out what I need to modify to make this
transient either go away or such that it is no longer effective in
triggering the Current Address Counter to count up before DMA operations
begin.
Suggestions as to how to clear this up are warmly welcomed.
Thanks to all,
Rick Bensene
Hi folks!
I grabbed my first Osborne I today :)
I powered it and it showed a crisp and vivid monitor :D
I had a bunch of disks, but none of them worked (boot error).
So I tried them elsewhere: they were all Double Density (so I have DD
drives) but almost unreadable: the surface is dirty and covered with
spots, may be fungi :(
I dowloaded some IMD images and gave it a try...
It booted with the Osborne logo and then the screen was slowly filled
with junk, mainly "@". The Osborne stopped responding: I pressed the
Reset button...
Continuous beep on reboot, screen filled with random chars.
I powered off, waited some minutes: no changes, no boot.
Beep and screen junk, the floppy drives lights dance rhythmically :p
I'll able to open it only the next week (the work table is full), but
I'd like to figure out what's happened.
Ram? Rom?
Thanks!
