< I have looked at Z180's, Z380's and etc.... They are SLOW!!!!!! The
< only availabe packaging for the Z380 is un-useable to me as a hobbist
< (without a lot of headache.)
Slow clock but they use fewer clocks and 16bit fetch. The effective
speed is higher. Also the chip spped in climbing.
The socket is a 25$ item to get from flat pack to wire wrapable.
< I hate the way that Zilog has taken the nice and simple control bus sche
< of the Z-80 and really made it a pain-in-the-butt on the Z-380!.
At first I was of that opinion. Then I started with the z280 (Zbus mode)
and z8000 and looked back at the z380 and it looks worse than it is.
It's advantage is that it puts out advanced timing info making fast
systems possible while using less bus bandwidth.
< size set of bus control lines), Z-80 instruction set and match a DEC Alp
< performance (at a cheap price of-course), I would worship that company.
Why not find and Alpha and write z80 PALcode for it?
< (Oh yes, I want a 64bit data bus and a 128bit address bus). Is this ask
< for too much? Why can't we all just get along?
You don't know why that isn't done. There are things about the z80 that
do not scale well.
< My thoughts are this: If I can find some REALLY SIMPLE mirco-controlle
< that do just the basic microprocessor functions, I can parallel them to
< make them read-in and intrepret Z-80 code.
Like I said it's the sub 1nS memory that will stop you. A z80 at a
theorhetical clock of 100mhz would require the memory *system* to have a
M1 read cycle of less than 10nS. Try and find logic for decode and memory
taht can make that happen in the required time. The Z80 bus provides
little in the way of advanced timing to overlap operations so you need
really fast memory and IO stuff.
For example while z80s at faster than 10mhz are easy to get peripherals
for greater than 8mhz are scarce and some never got faster than 4-6mhz!
< and DEC Alpha) can reach clock speeds of 600 Mcyc and a really simple (o
< accumulator, bare instruction set) microcontroller can't exceed those sp
It's a study in piplelined operations. Simple machines have less to
pipleine so the individual elements have to be faster. You cannot
overlap as many operations as there only a few. Even with current
superfast logic sub 1nS gates are rather scarce. So you hit the speed
limit IE: how fast can you compare two numbers and branch based on the
result.
< If I got some of these micro-controllers and had two or three of them
< reading in instructions ahead of execution (looking for branches) I coul
< do half of the job and speed up the through-put.
Except that they arent avalable that fast. Your trying to discretely
do what a PII does internally. It's in esscence doing several things in
parallel assuming some will be thrown away (branch no taken, add not done
and so on) that take complex archecture so that you have more irons in
the fire and can be more speculative.
< For math, a bunch of stinking fast memory locations acting as look-up ta
That works but to get the speeds you talking about where do these sub
3nS rams/roms come from? Can you wire them on a card so that the lead
lengths are not a significant part of the timing (remember 1ft=1nS).
These become real things when the clock exceeds 100MHz. I know this
>from doing a 20mhz z180 design on paper and I was looking at fast cache
rams chips to keep the memory inline, but for IO wat states were a must
as most periperal chips I could find were limited to 10mhz bus speed
range.
I know I'm a party pooper but, I'm also one of those wacky engineers
that has pushed the z80/z180/z280 to the edge and know what a design
must do to work.
On the other hand running CPM at 12.5MHz z180 is frighteningly fast
but also points out system bottlenecks like disk speed! I've been
putting time into overcomming that using disk caches and the like.
Allison
< >Ok, howabout a Brigeport milling machine with the PDP-8E it was purchas
< >with in 1975, still running the same code.
<
< Sure, I can imagine that. But I can't imagine it will stop working
< on January 1, 2000, or that the clock couldn't be set back to 1975
< without affecting the milling.
Correction, what clock? Most control apps clocks are intervals, time
between events, maybe time of day or week for longer periods and its
rare that they even consider time of year.
Keep in mind that until sometime past 1981ish clocks were not chips that
kept time of day/year. Of ten they were a periodic interrupt that was
totalized for time and date. So if the clock was broken it was software
not hardware.
The one example where Y2K has hit a PDP-8 use was a nuke power plant
and the PDP-8 doing data logging had to print the right time date on
the page. If the time and date were wrong nothing stopped working
but the NRC would be upset with the dataing of the logs. FYI: Y2K
happens to hit every 7-8 years on PDP-8 OSs as they only use 3bits for
relative year. Bits used to be expensive!
< If the source code has existed in some form since the late 50s or
< early 60s, no programmer since its creation has tinkered with it?
< I can imagine a slightly more plausible situation in which the source
< was written in 1961, recompiled and tweaked throughout the Sixties,
< and somehow the source was lost after recompilation in the Seventies
< so only the executable remains, and that it's been running in some
This is likely the commonplace event and the machine by the 70s was
stable platform say like DG Nova, PDP-11 or other that has a lifespan
exceeding 10+ years or still being made.
Lost in some cases means it exists and somewhere on a backup that is
in a room with 10,000 tapes of other backups that no one has looked
at for 7+ years.
Heck my vax archive is over 7 years old and is more than 20 TK50s. I
don't recycle major backups as I've had tapes fail. So the deeper the
archive the less likely the loss and also harder to find a specific
item. This is only hobby use. business should do this far more often.
< It's not that I'm denying Y2K - it's that I think it's overblown,
< especially when it comes to antique computers.
Me too. Many system Y2K is a singular event or non event. The only
ones I even think about in relation to it are the PCs and maybe the
VAXen (I run VMS 5.3 to 5.5). The PDP-11s may not like the date but
most of the stuuff I do is not date centric so unless the OS breaks it
keeps cranking. The PC makes me worry as DOS/Win and internetorking
software may have bombs I don't know nor can fix myself. I've bumped the
clock and it seems to behave though.
Allison
>> field fixings etc. Especialy in the /360.../390 world some
>> of these routiens are older than the OSes where they are used
>> today. Some are dated back to a thime when source was equal to
>> punch cards - at this time only the object code was stored in
>> libraries - source was stored as card boxes - and some of these
>> little helper work just fine when used in complete new projects,
>> 30 years later.
> Good grief, you mean to say that these boxes of source code I have on punch
> cards are finally going to be worth something :).
Yeah - but fast, you have to finde s.o. in need of them :)
<g>
Gruss
H.
--
Ich denke, also bin ich, also gut
HRK
This is kinda off topic, but we've just had a bomb threat!
No joke! Someone phoned in, asked for my boss, and said they
put a bomb in the building! Why would someone bomb an ISP?
Other than my boss is an Afican-American... (Native of Nigeria).
-------
Well, I guess we see this trend of making things less redundant and
less faithful to theory, more faithful to shaving off 1/4 of a cent
universally.
We see bomb threats pretty universally too, and not necessarily for
political reasons. Are you sure it wasn't just a kid whose computer
crashed again?
>
>> This is kinda off topic, but we've just had a bomb threat!
>> No joke! Someone phoned in, asked for my boss, and said they
>> put a bomb in the building! Why would someone bomb an ISP?
>> Other than my boss is an Afican-American... (Native of Nigeria).
>> -------
>
>A sad commentary on a form of 'techno-terrorism' that is likely to
become
>more prevalent as dependency on the 'net' increases.
>
>The commercialization of the Internet has inadvertantly weakened one of
>its major design points that was considered to be so critical when the
>first ARPA designs were worked out. That being redundancy and lack of
>centralization.
>
>Before the major commercial 'backbones' were in place, (set the
'wayback'
>machine; Sherman) most systems had multiple shared dial-up connections
to
>numerous other hosts with which they regularly shared information
(email,
>news, files, etc.)
>
>If a network connection went down, (if you even had one) or a given
host
>was offline, traffic was just routed thru another system that indicated
>connectivity to the system (or systems) that the traffic was destined
for.
>(everyone remember the periodic routing 'maps' that went around?)
>
>So... unless you lost ALL of your phone lines for an extended period,
you
>pretty much always had (some level of) connectivity.
>
>Today, on the other hand (generalization warning!) how many major
systems
>maintain dial-up inter-system capability even as a backup?
>
>The major infrastructures have tended to centralize around the
commercial
>'backbones' and carriers which make them succeptable to interruptions
of
>service when a single connection fails! (Sure... your web servers are
fed
>by dual 'T3s', but both from a single carrier thru a single POP?!?)
>
>So much in money and resources is often committed to create/maintain a
>major (high bandwidth) link onto the net, (useful) redundancy is
>frequently sacrificed.
>
>One attack on a major carrier POP (ok, definition time: POP = Point
>Of Presence) could easily disrupt Internet traffic for a LOT of people
and
>corporations.
>
>Take out a couple of the major authoritative DNS servers, and watch the
>world (generalization) start crashing down!
>
>Or sadly, target one ISP that is suspected of being a major provider?
>
>It happens... more often than you might ever imagine...
>
>-jim
>(I speak for no one but myself... YMMV)
>---
>jimw(a)agora.rdrop.com
>The Computer Garage - http://www.rdrop.com/~jimw
>Computer Garage Fax - (503) 646-0174
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
< THe Z180 is already down to 3 cycle/instruction, and the z380 is
< down to 2 cycle/instr. But since the maximum clock rate of the
< 180 is more than 50% higher than the 280, it's the way to go.
No news to me. I'm running a modifed SB180 (z180) and also working with
z280/12.5Mhz. I've looked at z380.
< > of using. I have z80/10mhz parts however and the 2901s would barely d
< > that.
<
< And if you try, most 10 MHz can run at 12 to 14 MHz.
I've taken the 10Mhz part to 12.5Mhz.
<
< > FYI: z80S180s can be had into the 30+ mhz range.
< :) Jep and 1 Meg is still plenty of RAM when running CP/M
That it is.
< But after all where is the sense of having a Z80 as 64 Bit
< processor ? It's a well usable 8/16 Bit processor. Even the
< 380 isnt really an advantage - you just don't realy need this
< 32 Bit instructions. A set consecutive 16 Bit instructions
Larger flat address space. The z380 would make a real good data handler
(z382 is a PC bus slave version for comms) or possibly a graphics
crunchers. Even in the z80 native mode you can access beyond the 64k
basic addressing in a manor that is more convenient than the basic z80
provides. In most cases the extended mode changes the the effect of
the arithmetic overflow in 16bit ops so that 0FFFFh+1 is not 0000. but
10000h. There are of course extended operations as addressing modes
as well.
< can do it in almost the same time. From my point of usage
< a 16 Bit uP is anything you need - compact code, compact data
< and greater over all performance.
Z380 still has those attributes. It saves the memory management overhead
for apps that need to get at spaces larger than 64k.
I plan to do a bit of serious work with one if I can get my hands on a few
and a socket adaptor.
Allison
> This reminds me of a claim I hear in Y2K discussions, but can hardly
> believe: that businesses are running the same *executables* since
> the 1950s/60s/70s, and that they don't have the source code to fix it.
In fact, this is widely true - Ok, the most cases are not
about the source of the whole programm or the main programm
its more about subroutines that have been used over the years
to solve common things like conversation, key transformations
field fixings etc. Especialy in the /360.../390 world some
of these routiens are older than the OSes where they are used
today. Some are dated back to a thime when source was equal to
punch cards - at this time only the object code was stored in
libraries - source was stored as card boxes - and some of these
little helper work just fine when used in complete new projects,
30 years later.
> Sure, they might not have the source to the OS, but their own apps?
Remember 30 years - have you ever archived all your work for
30 years ? _EVERY_ Programm you did within these 30 years ?
> And that there's been no other reason to change or replace the
> programs in all these years, and Y2K is the only reason they need to do it?
Jep it is - for example lets take a common old application,
for example a salery programm for a big company - the programm
still uses the same algorythms since 30 years - the same way of
I/O and the same basic data - just some modules for tax calculation
have been changed over the years.
After all I bet some of these programms will even survive
the Y2K hype without change :)
Gruss
H.
--
Ich denke, also bin ich, also gut
HRK
Following is a usenet posting from a guy needing some
help with a uVAX II.
It sounds like what I would call a basket case, he hauled it home
in several baskets in this case. I have emailed him answers to the
more basic questions. Since there are a few of you with far
more knowledge on this, I thought maybe some of you could
help him out.
My knowledge of the uVAX II is limited to having gutted out
6 machines being disposed of by former employer. Sorry, that
was before I knew of Classiccmp, snif, snif.
Mike
Please email directly to him.
Subject: secrets of a microvax II
From: siebert(a)berlin.gmd-net.de
Date: Thu, Oct 22, 1998 07:39 EDT
Message-id: <70n5h7$koq$1(a)nnrp1.dejanews.com>
Hi there, I need help...
I got a DEC Microvax II System which is partly disassembled and has the
following coponents:
-------------------
| |
-------------------
| <OO> | < > | 1) looks like a kind of harddisk
-------------------
| < ..I>| 2) MICROVAX II
| < ..I>|
-------------------
| < . >| 3) ? with a TK50 tape unit
| < . >|
-------------------
| | 4) RA81 harddisk
| |
| |
| |
-------------------
| | 5) power supply
-------------------
1) The harddisk (?) is perhaps from FUJITSU and there is place for a
second one. It has to be connected to a EMULEX QD 331040100 controler.
I saw some pictures of the same units on the web!
2) The muVAX II processor has no harddisks or any drives and has one switch,
four buttons and two LEDs on the front panel. It has the following boards:
(back view, top)
------------------------------------------
| M 7606 KA630 CPU |
------------------------------|||||||||---
| M 7608 4MB Memory |
------------------------------|||||||||---
| M 7608 4MB Memory |
------------------------------------------
| |M 7504 DEQNA Ethern.|--cable
------------------------------------------
| |
------------------------------------------
| |
------------------------------------------
| |
------------------------------------------
| |
------------------------------------------
3) The other housing looks like the muVAX processor but has only two
buttons and the built in TK50 tape unit. It has the following boards:
(back view, top)
------------------------------------------
| M 9404 connector | |-- cable to muVAX II
------------------------------------------
| M 3104 8 line serial controler |-- cables
------------------------------------------
| M 7546 TK 50 ctrl.| |-- cable to TK 50
------------------------------------------
| M 7164 QDA processor for KDA 50 |-- cables
----||||||-----------------||||||---------
| M 7165 QDA SDI controller KDA 50 |
------------------------------------------
| |
------------------------------------------
| |
------------------------------------------
| |
------------------------------------------
4) RA 81 456 MB SDI HDD
5) power supply digital 874-F
On the backside are the following connectors:
> 8 serial 25 pin SUBD connectors
> 4 connectors for SDI drives
> 1 DEQNA Ethernet 15 pin SUBD connector with a fuse
> bulkhead with 9 pin SUBD console connector
I have no documentation except from the manual for the serial controller...
Hmm.. now I have some problems/questions...:
- Which was perhaps the use of this system ?
- which was probably the OS (Unix version...) ?
- Was it a single user system ?
- where can I get a "user handbook" for the muVAX (booting, meaning of the
front buttons of all components...) ?
- Which type are the housings for this muVAX (BA23, BA123...) ?
- Why is this muVAX II SO BIG ??? (in comparision to the "under table
systems" which don't have TWO boxes for the cards...)
- What is the difference between a Microvax II and a Vaxstation II ?
I have no Terminal to use as console
- what kind of connector is the 9 pin SUBD connector on the backside
(bulkehead) ?
- What kind of terminals can I connect ? (I have some SS97 Siemens Terminals
or a IBM colour Terminal...)
- Can I use a PC with a TTY or a VT100 emulation and a serial connector
cable ?
- Do I have to use always a console to start the system (with a switch
on it or something like that) ?
Some of the cards are disassembled in the machine
- Where in the muVAX processor housing 2) must I plug in the M 9404 card
coming from the "controller housing" 3) and which side must be on the
top ?
- Where in the "controller housing" 3) must I plug in the EMULEX
controller (it needs only half of the place) ?
I am not firm with RA81 HDD
- Where in the RA81 must I plug in the flat connector ?
- Is only one of the four flat connectors for ONE RAxx drive ?
- what are the two round mini 4 pin din connectors for in the RA81 ?
- in which of the four flat connectors on the back of the system do I have
to plug in the RA81 ?
- Is there any information about the SDI "standard" ?
In both the processor and the controller housing are slots for connecting
HDDs.
- Do I need controllers for connecting drives there?
- Is it MFM standard ?
- When there are no drives in it, do the buttons on the front panel have
any function ?
General...
- How can I use the Ethernet connector (compatibility, wiring...) ?
- What is the power supply for ? (one big INPUT, three OUTPUTS - all
220 V and 4 smaller outs !)
- from which of the two harddisks (RA81, FUJITSU) does the system boot
from ?
- What are the 8 serial connectors for (Terminals...) ?
- For which use was the TK 50 tape for (booting, streamer...) ?
I also got a DEC VR262 screen together with the whole stuff, but I can't
imagine that there is any use with the muVAX.
- how can I use the VR262 ?
I know this are manymanymany questions, but even few ansers would be a
great help,
thanks - Rainer
Well, comparing myself to _most_ of the keds in my school, I'd say 'odd' is
the word. In my school, they have a "freak day", where everyon dresses up
in screwy clothes, and purple hair and everything. Even the teachers do
it.
--
-Jason
(roblwill(a)usaor.net)
ICQ#-1730318
----------
> From: Brett <danjo(a)xnet.com>
> To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
> Subject: Re: Units of measure (Was: discrete transistors
> Date: Tuesday, October 20, 1998 11:38 PM
>
>
> On Tue, 20 Oct 1998, Jason Willgruber wrote:
> > I think the only reason that I know this is that I collect antique
radios.
> > maybe I'm just odd...
>
> Whoa - change that view - You are not odd - just exceptional 8-)
>
> BC
>
> >So, believe it or not my naive young man, people are dumb enough to lose
> >the source code.
> What I don't believe are these claims that the heart of the Y2K
> problem are thousands of businesses running apps as old as I am,
> that haven't had to change, or that can't be changed. How many
> serious businesses are still running the same unchanged sourceless
> app since 1978, much less 1968 or 1958?
Most of them are not completely unchanged, but the changes
are only in some parts that have been changed every year once
or twice - and large parts haven't changed at all for the last
20 or 30 years.
Also don't forget - for some programm parts there might be
a source, but the object code has been patched (not uncomon)
and the source doesn't reflect the programm. Or source tools
(assemblers etc) where used, wich are not availabe today !
Or the source is stored in a library where no LMS needed is
available - or they are stored on tapes no longer readable
(to bee correct no longer readable means in most cases only
they can't be just inserted and read - you know, some of the
Y2K heros don't spend more than 20 minutes before they decide
'Source gone').
Gruss
H.
--
Ich denke, also bin ich, also gut
HRK
