check out http://vmsone.com- looks to have all the layered products up under webpages:OpenVMS Kits. Haven't got my VMS skills to where I have tried them, yet, but it looks like the read deal.
This is John Wisniewski's site, and I'm not sure who has custody of it or how long it will be up now that he's gone, so possibly someone with a high-speed connection could look at mirroring the VMS stuff.
-Scott Quinn
>From: "Paul Koning" <pkoning at equallogic.com>
>
>>>>>> "Tony" == Tony Duell <ard at p850ug1.demon.co.uk> writes:
>
> >> It sounds like the tristate buffers don't do exactly what I would
> >> like, although I think I can make it work with more logic in front
> >> of the control line for the buffer.
> >>
> >> However, doing a bit more research, it looks like what I really
> >> need is a Transmission Gate. The important difference is that a
> >> transmission gate will pass the input regardless of its state, so
> >> L passes L, H passes H and Z passes as Z. The disadvantage is
> >> that if you have a noisy signal, the TG doesn't clean it up at all
> >> the way a TB will.
> >>
> >> The catch is that I cannot find one listed anywhere as a part that
> >> one can actually buy. Are transmission gates purchasable parts?
> >> Or are they just something they discussed in my VLSI textbook?
>
> Tony> An analogue switch IC is a similar device, and those do
> Tony> exist. The problem is finding one that will switch quickly
> Tony> enough (I would guess in a few nanoseconds) for this
> Tony> application.
>
>No problem.
>
>Quickswitches are rated to several hundred Megahertz. If that isn't
>good enough, you can use microwave switch transistors. I don't know
>the max switch rate of either, but presumably any transistor capable
>of carrying microwave frequencies can switch on/off in a nanosecond or
>better.
>
> paul
Hi
The problem is as Tony mentioned, you get no buffering.
This means you can't expect to put the mux too far from
the inputs on either side. You are really better off
using something like '245's.
Dwight
>Date: Tue, 27 Sep 2005 07:54:24 -0700
>From: Eric J Korpela <korpela at ssl.berkeley.edu>
>Subject: Re: Tristate Buffer Output if Input is High-Z?
>On 9/26/05, Jeff Walther <trag at io.com> wrote:
>>
>> If a tristate buffer is enabled by its control line, but the input to
>> the buffer is at high-Z is there a typical output?
>
>
>If there is it probably varies between parts. If you need a defined output
>for tristated inputs you should pull the inputs up or down.
Thanks to everyone for all the replies.
It sounds like the tristate buffers don't do exactly what I would
like, although I think I can make it work with more logic in front of
the control line for the buffer.
However, doing a bit more research, it looks like what I really need
is a Transmission Gate. The important difference is that a
transmission gate will pass the input regardless of its state, so L
passes L, H passes H and Z passes as Z. The disadvantage is that if
you have a noisy signal, the TG doesn't clean it up at all the way a
TB will.
The catch is that I cannot find one listed anywhere as a part that
one can actually buy. Are transmission gates purchasable parts? Or
are they just something they discussed in my VLSI textbook?
If they are real parts, would someone please suggest a part number?
Preferably an octal transmission gate (eight on a chip) divided into
two sets of four with separate control lines (OE) and one OE active
low and the other active high. That's how the SN74ABT241A tristate
buffer is configured and it's perfect for my application, other than
the little detail that a tristate buffer doesn't quite meet my needs.
:-)
Since someone asked, a quick synopsys of my project (for those who
missed the earlier threads) is that I'm trying to build 16 MB SIMMs
for the Mac IIfx (1991) using 16M X 4 parts (Samsung KM44C16100).
The IIfx used unusual 64 pin SIMMs which are 8 bits wide, but keep
the Data In and Data Out pins separate. This is fine, when one is
using X 1 DRAM chips, as X 1 chips have separate Din and Dout (D & Q)
pins. I've checked the IIfx motherboard and it actually does make
use of the divided data pins to allow it to buffer writes, so I can't
just tie the pins together. If I tie the pins together, the data
for buffered writes will go out on the machine's data bus, when it
should just stay between the buffers and the SIMMs.
Using a (one per memory chip) SN74ABT241A, I can buffer the DRAM chip
data pins and make them look like separate in and out pins. The
SN74ABT241A is an octal tristate buffer with two OE lines. Each OE
controls four of the buffers, and one is active high, the other
active low.
So, using WE to control both OE lines of the SN74ABT241A means that
the buffers will only conduct data from the Din SIMM pins to the DRAM
data pins, when WE is low, and will only conduct data from the DRAM
data pins to the Dout SIMM pins when WE is high. There's no way for
data from the SIMM's Din pins to feed back onto the SIMM's Dout pins.
This looks beautiful until one considers what happens when the
computer is trying to use the data bus for other things. If the
computer leaves WE high, then the buffers will be driving some signal
onto the Dout pins of the SIMMs. With normal SIMMs this would be
okay, because the Dout of the DRAM chips should go to High-Z after
CAS goes high at the end of the Read, even if WE is still high
(according to DRAM datasheets).
But in my situation, CAS goes high, the DRAM chip data pins go
high-Z, and if WE stays high, then the buffer takes that high-Z input
and tries to make it into some deterministic H or L output. I need
that high-Z output from the DRAM chips to propagate through the
buffer.
Or I can shut the buffer output down after CAS goes high. So an
alternative is to use an inverter and AND gate to deliver (CAS' AND
WE) to the buffer control line for Data_Out. This will probably
work--barring timing issues--but involves two more components (or
four if I don't want to run a trace cross-board), and the associated
additional layout headaches.
I've actually already laid out the board (in software) with the
inverter and AND gate added, but a transmission gate would be more
elegant and keep the component count down.
But if there aren't actual transmission gate components available,
I'll just produce a set of boards with traces and positions for the
AND gate and inverter, and Vias in close proximity so I can do a bit
of wire wrap modification and experimentation on the first set to see
what control to the tristate buffer works--or doesn't work.
Jeff Walther
The 6800 indeed had HCF and while I forget the opcode
(not a regular 6800 user) it was real. Basically if
the opcode was encountered the chip executed bus cycles
and did nothing else till reset. Story then was it
enabled some level of factory testing of the die for
the is it even alive test.
Allison
>
>Subject: Re: 6800 opcode $02
> From: "J.C. Wren" <jcwren at jcwren.com>
> Date: Tue, 30 Aug 2005 21:45:00 -0400
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
> I'd suggest finding a VHDL or Verilog implementation, and see if
>that provides any insight. Also, Google for '6800 undocumented opcodes'
>(no quotes). There are a number of hits. Most seem to indicate that
>the undocumented opcode (no value given) causes the processor to go into
>a mode where there are no instruction fetchs, but the address bus runs
>incrementing bus cycles.
>
> --jc
>
>Scott Stevens wrote:
>
>>On Mon, 29 Aug 2005 17:53:59 +0100 (BST)
>>ard at p850ug1.demon.co.uk (Tony Duell) wrote:
>>
>>
>>
>>>Does anyone know what Opcode $02 is on a Motorola 6800 processor. It's
>>>
>>>not defined in the data sheet, but I have a device which forces that
>>>instruction onto the data bus in one of the test modes.
>>>
>>>Is it, by any chance, the infamous HCF instruction?
>>>
>>>-tony
>>>
>>>
>>>
>>Hmm, all the other $0x opcodes on the table are inherent instructions
>>that mess with the condition code register. Looking at the order of the
>>bits in the instructions, I don't see an order that corresponds with
>>good old HINZVC (we were required to memorize this, the order of the
>>bits in the condition code register, in tech school)
>>
>>0a clears overflow (V)
>>0b sets overflow (V)
>>0c clears carry (C)
>>0d sets carry (C)
>>0e clears interrupt mask (I)
>>0f sets interrupt mask (I)
>>
>>The lower instructions defined are
>>06 Accumulator A to CCR
>>07 CCR to Accumulator A
>>
>>
>>Is there a bit-level 'Opcode Breakdown' reference for the 6800
>>processor, that defines bit field and gives clues to how the opcodes are
>>translated in hardware, like there is (it's an elaborate table and I
>>even have a machine language Textbook that drags you through it all on
>>an early chapter) for the 8086 processor?
>>
>>The good old 6800. 'Freescale' : bah!
>>
>>
>>
>
>Subject: offlist Re: Looking for: BCC180 schematics and..
> From: Chris M <chrism3667 at yahoo.com>
> Date: Thu, 29 Sep 2005 08:05:45 -0700 (PDT)
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
>
>That sounds like something that was published in Byte
>years ago. As a matter of fact I'm pretty positive.
>Mostly definate. 99% anyway. Provided I have it, would
>that solve your problem?
Yes. I just need the schematic.
I know the SB180 was published in Byte (september '85) as I have the
article and the SB180. The BCC180 was a few years later and by then
I getting Byte as it had become a PC rag.
I've been in the process of moving a small mountain of stuff and this
weekend I hope to assess the multibus boards I have.
Allison
I recently sold an item using the "Vintage Computer Marketplace"
[ http://marketplace.vintage.org/ ] I recommended buyers us check, money order
or PayPal. The buyer was familiar with BidPay - and chose to use it
instead...
BidPay rejected the first payment - as it didn't recognize the auction - and
said they to not pay "individual" to "individual" transactions.
Both the buyer and I responded to BidPay that the "Vintage Computer
Marketplace" was a valid auction and payment should be honored.
When the buyer tried again - the payment got rejected a second time.
DON'T USE BIDPAY!!!!
Regards,
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
Mountain View, CA
http://bickleywest.com
"Black holes are where God is dividing by zero"
Hi,
I find myself, in real work, for money and everything, working on an
ST20 micro.
Little did I know it was a transputer :-)
I recall seeing some messages here from people who seemed to be
interested in transputers.
I'm curious - is there any nice "hints & kinks" on the web for
transputers, or a good book or tutorial? It's not that complex but I am
curious to hear from anyone "in the know" as it where about ways to make
them go fast...
(it's so rare when my hobbies cross my day gig. note to self... :-)
-brad
I recently acquired three ASR-33 teletypes in various conditions. It looks like two of them are complete and one has been scavenged slightly for parts, but appears to be mostly there. I would like to restore at least one and hopefully two of them. I have the technical manual, which I have started reading. I've also googled and found various sites with info, including previous discussions here on CCTALK.
Does anyone have any pointers or good reference sites on testing and bringing one of these things back to life? I want to start at ground zero. One of the TTYs seems to power up fine and the motors run, but I can't get the keyboard to type in local mode. The keys don't press down all the way. The shipping bolt was not in place when these were shipped, and I know they were picked up and tilted and moved around, so things inside may be out of alignment.
All three have the phone dialer options installed on the right hand side. I don't intend to use the phone dialers, but it would be interesting to have one cleaned up for show.
I have another good ASR-33 working and hooked up to my PDP-11/40 on a 20mA DZ11 connection.
Any advice is appreciated. In the meantime, I am going to continue surfing for information and reading the technical manual.
Thanks,
Ashley
Is anyone else getting these? I'm not posting to CCTECH.
--
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 ]
---------- Forwarded message ----------
Date: Thu, 29 Sep 2005 01:14:55 -0500
From: cctech-bounces at classiccmp.org
To: vcf at siconic.com
Subject: Request to mailing list cctech rejected
Your request to the cctech mailing list
Posting of your message titled "Re: PalmOS no more? :("
has been rejected by the list moderator. The moderator gave the
following reason for rejecting your request:
"Non-members are not allowed to post messages to this list."
Any questions or comments should be directed to the list administrator
at:
cctech-owner at classiccmp.org
>
>Subject: Re: PalmOS no more? :(
> From: John Foust <jfoust at threedee.com>
> Date: Thu, 29 Sep 2005 09:49:15 -0500
> To: <cctalk at classiccmp.org>
>
>At 08:38 PM 9/28/2005, William Donzelli wrote:
>>Windows Muntzing.
>
>I hadn't heard the term, but it's an interesting story:
>
>http://www.national.com/rap/Story/0,1562,17,00.html
I've been doing this to winders since dos and V3.1 on an XT clone with a
small hard disk. Before that with RT-11 and VAX/VMS 5.x.
Seriously, if you take say W95b and pare out all the junk it's both small
and surprizingly robust, this appied especially to MS IE and OE. How
small? For W95 with Ip networking it was under 29mb of on disk stuff!
I may add that putting Office97 on a W95b/98 system was by far the fastest
way to bloat it and destabilize it. The real trick is not pruning it out
but changing the install scripts to not put all that cruft in!
Allison
