woodelf wrote:
> I would have updated the high voltage power supply to a simple
> transistor regulator. I have about 128 AC around here and that
> can really give over voltage on 115 V transformers.
> PS. Where do you find a 300 V transformer ... I may build one
> some day.
If you don't want to scrounge surplus stores, or wind your own, Hammond
currently makes a couple that would work. They are the 269BX and
369BX, depending on whether you want "universal" primaries or not.
Their high voltage secondaries are 300VCT, and they also have the 6.3V
windings. They're a bit larger than necessary, being rated for 2-3
times the power called for in that design.
allan
--
Allan N. Hessenflow allanh at kallisti.com
>>> Dear Ashley,
>>>
>>> Yes, I have them. See
>>> http://www.sonnet.be/dec/computerlab.htm
>>> I can photocopy them for you, if you want.
>>
>> I'd also be interested in a copy of the "Computer Lab Teacher's Guide".
>> (I have copies of the student workbook already.)
>>
>> Thanks,
>>
>> Vince
>
>Phillippe,
>
>I would like a copy of the teacher's guide too. Thanks for your offer
>to photocopy. You can email me off-list at wacarder at usit.net.
>
>Thanks,
>Ashley
Phillippe,
If you want to just make one copy, you can send it to me and I will
copy it and send to the other folks here in the U.S. That will keep you
>from having to pay for multiple shipments across the ocean.
Ashley
Hi,
does anyone have a manual for one of these? It says graphics terminal on it,
is it a vector terminal like the Tektronix units, or some other device?
Thanks
Jim.
Please see our website the " Vintage Communication Pages" at WWW.G1JBG.CO.UK
At 22:03 -0500 9/12/05, Chris wrote:
>From: Chris M <chrism3667 at yahoo.com>
>Subject: DEC *Rainbow* stuph
>...
>I recently obtained a Rainbow 100 with a gaggle of
>disks. ... So where is the archive that has the DECUS stuph?
ftp ftp.update.uu.se
login as anonymous, use your email as a password
cd pub/rainbow
browse and enjoy. Hats off to the update maintainers, they rock!
More generally,
http://www.classiccmp.org/rainbow/files.html
also rocks! Kudos to Jeff Armstrong for that one, and for being too
modest to mention it in his reply (which I read after confirming the
ftp address for update).
--
- Mark
210-522-6025, temporary cell 240-375-2995
Anyone try SimOS to emulate a SGI IRIX environment? I want to use this to
continue with my porting initiative...
http://simos.stanford.edu/
Thanks,
Ram
The best place to find Rainbow software is ftp.update.uu.se under
/pub/rainbow. Tons of software is available there. They appear to have a
complete DECUS disk set archive, but there is other software there that I
believe is not found in the DECUS disks.
-Jeff
-- Original Message: --
> From: Chris M <chrism3667 at yahoo.com>
> Subject: DEC *Rainbow* stuph
> To: cctalk at classiccmp.org
> Message-ID: <20050908040212.48090.qmail at web61018.mail.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> I recently obtained a Rainbow 100 with a gaggle of
> disks. The person had told me there was a complete or
> nearly so set of DECUS disks included. None of them
> imaged w/o errors, so I just became disgusted and gave
> up. Now we know of all the semi-compatible peecees,
> the Rainbow is probably the easiest to find software
> for. So where is the archive that has the DECUS stuph?
> And there is a set of DECUS newsletters on Ebay at
> this very moment.
jba at sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
The following messages does not seem to get through.
"First part of October I will be getting a custom build prom-programmer with
software that programs and reads 2716's. And two Tektronix tube scopes, one
>from 1954 and one from 1960. Also a prototype Commodore 64."
Some day, before I die, I want to get everyone on this list in the same
room (er, bar) and see all their faces, and the reactions on them,
when someone starts a convertsation about a "tit mouse" :-)
that just cracks me up.
(did you ever see "bar fly"? Charles Bukowski is one of my heros) here's
to everyone on this list!
-brad
>Date: Wed, 7 Sep 2005 18:37:39 +0100 (BST)
>From: ard at p850ug1.demon.co.uk (Tony Duell)
>> If the DIN and DOUT are common on the MB
>My guess is that if they are linked, they will be linked by short tracks
>near the SIMM sockets. And you'd be linking them with short tracks on the
>SIMM PCBs. Considering that a light-nanosecond (in free space) is about 1
>foot, and that the velocity factor of a PCB is going to be around 0.6, I
>would guess about 8" of length difference would give 1ns of timing skew.
>I don't know how fast that amachine runs, but I would think you'd have to
>have a right stupid layout for using both pins to matter much.
Well, darn it, they aren't linked. It turns out that the memory
controller on the IIfx buffers the writes, so that the CPU can go do
something else after only 2 cycles instead of 6, unless, of course,
the next operation is a memory access.
So the the data lines from the SIMMs are routed to 74F573 D-type
latches. It appears that the SIMM's DIN comes from the latches'
outputs and DOUT goes to the latches' inputs. I have not confirmed
it yet (must pull the PGA 68030 to get access to the data lines) but
I suspect that the bidirectional databus goes to the input lines of
the latches.
So, on a read, the data would just come out of the memory straight to
the bidirectional data bus. On a write the data bus would take data
to the latches' inputs where it would be buffered, and the memory
controller presumably has control of the LE (latch enable) and OE
(output enable) lines to the latches.
So, if I tied DIN and DOUT together, it looks like there are at least
two potential trouble spots.
1) If the memory controller does not switch the latches to High-Z
(OE inactive) upon completion of Writes, then on a Read, the data
>from the memory would be in contention with the data still held by
the latches from the previous write.
2) While the memory controller is buffering a Write, that data would
feed back from the latches, along the tied together In and Out to the
bidirectional data bus.
So, for example, the CPU signals a Write. The memory controller
takes over, and the data is buffered and held in the latches. The
CPU is done in 2 cycles, but the MC will need 6 cycles total to
complete the write. Now the CPU goes off to do something like an IO
operation during which it will also need the data bus. However,
because the In and Out pins are tied together, the bidirectional
portion of the data bus is being fed the data from the previous Write
operation for four more cycles while the memory controller completes
the write operation. This will interfere with any other use of the
data bus.
So unless the data bus to the memory is seperate from the data bus to
the rest of the computer, I believe that tieing the In and Out pins
together will screw things up.
Does my reasoning seem sound? What did I miss? Was that clear?
Jeff Walther
>Date: Wed, 07 Sep 2005 12:46:20 -0700
>From: Marvin Johnston <marvin at rain.org>
>Subject: Re: Homebrew Circuit Boards: Methods? Supplies?
>To: cctalk at classiccmp.org
>Message-ID: <431F438C.E21624B2 at rain.org>
>Content-Type: text/plain; charset=us-ascii
>
>
>> From: Jeff Walther
>
>> In fact, I have not been able to find precoated board (photoresist
>> coated) in the .050" thickness. So I will either need to use a
>> liquid photoresist or try a toner transfer system.
>
>Personally, I would avoid liquid photoresist and use dry film in its
>place. You could contact Fred at Far Circuits
>(http://www.farcircuits.net/) as he will supply boards precoated with
>dry film photoresist. URL for supplies is
>http://www.farcircuits.net/supplies.htm. According to the site, he will
>supply 0.047 material laminated with Dupont PM115 photo resist film.
Now he tells me?! :-) I'm already down the road with the uncoated
.047" board. If that yields poor results I will try Far Circuits.
Thank you for that source. I searched all over the place and never
found that page. Sigh.
Jeff Walther
