Re: WordPerfect for VMS
Zane...I had it three days ago but I cant find it at the moment. If you dont find it elsewhere bug me privately. I must.have accidentally taken it to my office and will have to check there Bill On Fri, May 7, 2021, 9:45 PM Zane Healy via cctalk wrote: > Strange question, does anyone happen to have the keyboard overlays for the > VAX/VMS version of Word Perfect that they can photograph, or better yet > scan? I have the manuals, and the green, red, and blue stickers on the VT > keyboard, but no overlays. I *might* have the overlays, but I can’t find > the the VT keyboard I’m thinking of (though after digging, I know I have > more than I thought). > > I’m looking for the VT200/300 version (which should work for my LK401). > > Zane > > > >
Re: 400 Hz
On 5/7/21 4:55 PM, Fred Cisin via cctalk wrote: > Hmmm. If they ever use single phase, instead of 3 phase, . . . > > A4 (A above middle C) is nominally 440Hz, but not everybody agrees. > NY Phil uses 442, Boston uses 441, and many argue for 432. > > But, 400 would be A-flat. With a constant A flat droning in the > background, . . . I used to play (tuba) just below a fluorescent fixture that buzzed at 120 Hz. Very annoying--a flat B-natural or a sharp B-flat. Messed with my head. --Chuck
WordPerfect for VMS
Strange question, does anyone happen to have the keyboard overlays for the VAX/VMS version of Word Perfect that they can photograph, or better yet scan? I have the manuals, and the green, red, and blue stickers on the VT keyboard, but no overlays. I *might* have the overlays, but I can’t find the the VT keyboard I’m thinking of (though after digging, I know I have more than I thought). I’m looking for the VT200/300 version (which should work for my LK401). Zane
Re: 400 Hz
Hmmm. If they ever use single phase, instead of 3 phase, . . . A4 (A above middle C) is nominally 440Hz, but not everybody agrees. NY Phil uses 442, Boston uses 441, and many argue for 432. But, 400 would be A-flat. With a constant A flat droning in the background, . . .
Re: 400 Hz
On 05/07/2021 04:59 PM, W2HX via cctalk wrote: I will add that aircraft are one of the main users of 400 Hz. This is because weight is always an critical design consideration. So with smaller transformers, smaller capacitors, etc, you can save a LOT of weight on electronic devices in an aircraft. 73 Eugene W2HX -Original Message- From: cctalk On Behalf Of Andrew Back via cctalk Sent: Wednesday, May 5, 2021 11:26 AM To: cctalk@classiccmp.org Subject: Re: 400 Hz On 05/05/2021 16:07, Grant Taylor via cctalk wrote: Were the higher frequencies used because it directly effected the amount of time / duration in (fractions of) seconds between peaks of rectified (but not yet smoothed) power? Haven't read the rest of the thread and so at the risk of being profoundly wrong... Benefit of 400Hz mains is that transformers can be much smaller. Think of switching power supplies that rectify to DC and then switch up into kHz, which are then able to use far smaller transformer cores than an old linear PSU. At least this is a key motivation with 115V/400Hz 3-phase aviation power AFAIK. By coincidence we've just built a big 28VDC power supply, so that we can run a vintage 400Hz aircraft rotary inverter, which will then be used to power up old mil surplus kit that wants this. A classic adventure in yak shaving. Anyway, here's the 28VDC bit. https://www.rs-online.com/designspark/constructing-a-high-current-28v-dc-power-supply Andrew Interestingly, a lot of other military gear also uses 400 Hz power for the same reasons. I tore down a Nike radar van a long time ago, everything ran off 400 Hz. Jon
Re: Pipelining and Dec Jupiter thoughts....
On May 7, 2021, at 12:53 PM, Cameron Kaiser via cctalk wrote: > >> Back in the mid-90s, there was an outfit in Britain which made some >> laptops using Alpha processors. > > That was the Tadpole ALPHAbook. Not many of those got to the outside world. > Been watching for one for over a decade. For a period of time it was the > fastest laptop available and it was reportedly not overly unpleasant to use > (my Tadpole Viper, on the other hand, *is* unpleasant to use). > >> There was a rumor inside DECin the same time-frame about DEC engineers >> prototyping an Alpha-based laptop (which never made it to market). >> The rumor included the internal code-name... "BURNS". > > I don't doubt it! I’ve had my eye’s out for one for more like 20+ years. I do have a Tadpole SparcBook 3GS (? something like that), that was a pretty cool system. These if I needed OpenVMS on a laptop, I’d simply run it via emulator or virtualization (not an option for Itanium). I gather that at least some development on OpenVMS 9.2 is being done on VM’s running on the developers laptops. I seem to recall that the Tadpole AlphaBook performance is roughly on par with the DEC Multia, which is to say, not very good. Though I don’t think I ever got OpenVMS running on my Multia. Zane
RE: 400 Hz
I will add that aircraft are one of the main users of 400 Hz. This is because weight is always an critical design consideration. So with smaller transformers, smaller capacitors, etc, you can save a LOT of weight on electronic devices in an aircraft. 73 Eugene W2HX -Original Message- From: cctalk On Behalf Of Andrew Back via cctalk Sent: Wednesday, May 5, 2021 11:26 AM To: cctalk@classiccmp.org Subject: Re: 400 Hz On 05/05/2021 16:07, Grant Taylor via cctalk wrote: > Were the higher frequencies used because it directly effected the > amount of time / duration in (fractions of) seconds between peaks of > rectified (but not yet smoothed) power? Haven't read the rest of the thread and so at the risk of being profoundly wrong... Benefit of 400Hz mains is that transformers can be much smaller. Think of switching power supplies that rectify to DC and then switch up into kHz, which are then able to use far smaller transformer cores than an old linear PSU. At least this is a key motivation with 115V/400Hz 3-phase aviation power AFAIK. By coincidence we've just built a big 28VDC power supply, so that we can run a vintage 400Hz aircraft rotary inverter, which will then be used to power up old mil surplus kit that wants this. A classic adventure in yak shaving. Anyway, here's the 28VDC bit. https://www.rs-online.com/designspark/constructing-a-high-current-28v-dc-power-supply Andrew
Re: 400 Hz
First, thank you to everyone who replied and gave me things to think about and learn from. On 5/5/21 9:26 AM, wrco...@wrcooke.net wrote: Hope this helps. Yes, indeed, very much. Thankfully, your description happened to mesh with the weird way that my brain processes things and your message just clicked confirming what I was learning but still processing what other people had written. Thank you Will. -- Grant. . . . unix || die
Re: Pipelining and Dec Jupiter thoughts....
> Back in the mid-90s, there was an outfit in Britain which made some > laptops using Alpha processors. That was the Tadpole ALPHAbook. Not many of those got to the outside world. Been watching for one for over a decade. For a period of time it was the fastest laptop available and it was reportedly not overly unpleasant to use (my Tadpole Viper, on the other hand, *is* unpleasant to use). > There was a rumor inside DECin the same time-frame about DEC engineers > prototyping an Alpha-based laptop (which never made it to market). > The rumor included the internal code-name... "BURNS". I don't doubt it! -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Famous, adj.: Conspicuously miserable. -- Ambrose Bierce --
Re: cctalk Digest, Vol 80, Issue 5
On 5/6/2021 6:43 PM, Paul Koning via cctalk wrote: I wonder. Consider object oriented programming, where objects that have all manner of stuff inside are treated as a unit and have operations performed on them. I don't buy the class model of OOP. Classes are LIKE each other not someting that can shared between them. If that was the case move X-windows to MS-windows would be just X->XWIN = convert(X->M$WIN) for screen display. > Agreed on stack languages. While there's nothing inherently hard about them, they don't fit the way we're taught to handle formulas all the way from grade one. In fact, while APL is infix, it's right-associative, which is a definite problem. It's unfortunate Iverson didn't fix the assignment operator problem the way POP-2 did, by pointing it to the right so all operators could be left-associative. I think of variables and the stack nesting of variables. I find it confusing. Where are varibles for a=b+c. found. At what level can you find just who defined what with out reading the whole program.How many links must be checked to get your data. Ben.
Re: Motor generator-audiofools
On Fri, May 7, 2021 at 7:20 PM ben via cctalk wrote: > > > Well I am a Audio-Fool. Like they say "A fool and his money.. ". > Secret word of the day "ElectroStatic Speakers". I do not consider that to be audiophoolery. The charateristics of a particular electrostatic speaker are measurable. They are also different in some respects to those of a moving coil cone speaker, no matter what cabinet it is used in (which of course makes a big difference). They will sound different to a movng coil speaker system, and if you prefer that sound then that's what you should listen to. Far too many people forget that the real purpose of your audio system is not to be technically perfect but to reproduce sounds that you enjoy listening to. It is to give pleasure. There is something of an interest in the UK (at least) in the cheap 1960s record players of the 'Dansette' type. Techically they are terrible. A cheap autochanger, a cystal or ceramic cartridge, a simple amplfier based round either an outpur pentode (1 stage) or if you are lucky a triode-pentode (2 stages) and a single small-ish speaker in a cabinet with no acoustical merit whatsoever. BUT... it's nostalgia. People remember listening to such players back in the day, perhaps dancing with a person they later married. Remembering that gives pleasure. Which as I said is the real reason for such a device n the first place. To me audiophoolery is things that can't be measured and can't make a difference to the sound (or if they do, then something is serously wrong with the design). Like special mains cables, when there are several hundred metres (at least) between the final substation transformer and the wall socket outlet. And if the amplifier is so sensitive to small fluctuations of the mains input then the PSU of said amplifier needs to be redesigned properly. -tony
Re: Motor generator-audiofools
On 5/6/2021 8:00 AM, David Barto via cctalk wrote: I don’t refer to them as Audio-phools. They are GESR’s. (pronounced guesser) Golden Eared Sonic Reviewers They guess this sounds better than that, so it must be worth it. David On May 5, 2021, at 6:31 PM, Jay Jaeger via cctalk wrote: I think a lot of the time audio-phools, if they will be honest with themselves, are really trying to recreate the stereo (or even HiFi) sounds of the 1960s because they have fond memories and like it better. THAT I have no problem with whatsoever. What gets annoying is when the phools try and convince others that this old gear somehow more accurately reproduces recordings or that the "fleecy" stuff referred to actually makes things better. Oh well. JRJ Well I am a Audio-Fool. Like they say "A fool and his money.. ". Secret word of the day "ElectroStatic Speakers". I suspect 90% of the old sound is from the distortion of the speakers and the audio equipment clipping. I have had my audio system for the last few years, now to start upgrading to better computer, I have yet to find it. Some how a pie computer emulating a PDP 8 does not feel quite right. Ben.
Re: Motor generator
On 5/7/21 2:36 AM, Curious Marc via cctalk wrote: > The IBM 7090 used a motor generator, IBM model 7618 apparently > http://ed-thelen.org/comp-hist/7090-PowerSupplyControl I mentioned that about a dozen posts back: The 7090 certainly used MG sets. From the "Power Supply and Distribution Manual" (http://bitsavers.org/pdf/ibm/7090/ce/7090%20Power%20Supply%20Control%20and%20Distribution%20223-6904.pdf, page 5): "The IBM 7608, a power converter or motor-generator set which converts incoming 60-cycle three-phase (3Ø), 208v power to regulated 400-cycle 3Ø 208v power."
Re: Pipelining and Dec Jupiter thoughts....
> From: Paul Koning > Message-ID: <9d8bada7-b597-42e1-99c8-4cc751f83...@comcast.net> > Another part of the puzzle was figuring out how to feed 100 watts of power to > a chip, > and get rid of that amount of heat, neither of which were anywhere > close to what was > done at the time. I still have some of the tech reports that describe that > piece (and I >contributed a wild idea -- which unfortunately DEC didn't get > around to patenting >before the project was shut down). Back in the mid-90s, there was an outfit in Britain which made some laptops using Alpha processors. There was a rumor inside DECin the same time-frame about DEC engineers prototyping an Alpha-based laptop (which never made it to market). The rumor included the internal code-name... "BURNS". Dick
Re: Pipelining and Dec Jupiter thoughts....
On 5/7/21 5:10 AM, Paul Koning wrote: Speaking of ECL: DEC did some amazing work with ECL VLSI in the early 1990s. There was an R project called "BIPS" (for "billion instructions per second") -- which aimed to build a single-chip processor that would run at a gigahertz. That was way faster than the clock speeds of the time, and the notion was that to do this you needed to use ECL logic. IBM ran into the same problem in the 60's. The technology they developed with Moto was used by Amdahl in his clones. "biCMOS" was tried in the 90's. I worked with Exponential Technology on their 500MHz PowerPC. The problem with it was the on-chip caches were too small so the CPU spent most of its time stalled.
Re: Pipelining and Dec Jupiter thoughts....
> On May 7, 2021, at 11:45 AM, Jon Elson wrote:
>
> On 05/07/2021 07:10 AM, Paul Koning via cctalk wrote:
>>
>> They built an interesting hybrid system where you could write the design
>> partly as geometries (for things like memory cells), partly as transistors,
>> partly as gates, and partly as C code. I remember an example, where they had
>> a transistor schematic for a single-bit latch, and then wrapped it in a
>> loop: "for (i=0; i < 64; i++) { }". The magic was that (apart
>> from the few bits of explicit geometry-level design) it was all
>> parameterized, so they could regenerate the actual wafer geometry overnight
>> for a new fab.
> That sounds a lot like VHDL, which can be used to synthesize chip layout.
It's a bit different. In VHDL you can do gate level or behavioral modeling,
but the idea of wrapping a picture in a "for" loop was something I haven't seen
anywhere else.
Also, this was 30 years ago, roughly, when chip design technology was a whole
lot more limited.
>> Another part of the puzzle was figuring out how to feed 100 watts of power
>> to a chip, and get rid of that amount of heat, neither of which were
>> anywhere close to what was done at the time. I still have some of the tech
>> reports that describe that piece (and I contributed a wild idea -- which
>> unfortunately DEC didn't get around to patenting before the project was shut
>> down). paul
> IBM was tinkering with high density ECL system construction from 1965 or so,
> as a follow-on to the System 360. They had several aborted projects, FS
> (Future System) and ACS (Advanced Computer System) that were very advanced
> supercomputers. The technology eventually came out as the
> 309x series, with several hundred MSI ECL chips on a ceramic interconnect
> substrate, water-cooled
> with a big plate with copper "nails" that pressed down on the back of the
> ICs. That was the 308x system, introduced in 1984.
The packaging work DEC did included building a heat pipe package that could
handle well over 100 watts with air cooling, and also an investigation of the
current carrying limits of chip bond wires. It turned out gold wires have
really good properties: they handle a whole lot of current and they have a very
clear upper limit; stay even a little below that limit and the wires last
basically forever.
paul
Re: Motor generator
On Friday (05/07/2021 at 09:03AM -0700), Chuck Guzis wrote: > On 5/7/21 5:53 AM, Chris Elmquist wrote: > > > The HQ building (nee BTC) was built just a year before ETA started, > > so 1982 or so. But somehow it ended up with very 70s-ish decor, even > > if it was all new 70s-ish decor. It's possible they wanted all the guys > > that moved down from ARHOPS and ADL to still feel at home... > > Oh, yeah, brightly painted exposed pipes, too. Probably inspired by the > 1970's Centre Pompidou in Paris. > > CDC native decor was the usual 60's drab. The ubiquitous brwon > vinyl-and-fabric Steelcase chairs, for example. Another hangover, > thankfully abandoned, was the OCR-looking typeface on office typewriters. Yup. There were a fair number of the gun-metal grey desks that looked like they had come back from the Korean war or something that some of the guys brought from ADL to ETA. Wanted to keep their own desk! > > I hated the look of that so much that I managed to snag an IBM Model B > Executive with proportional spacing when a GM's secretary moved to a > Selectric. Ha. That really was a CDC trademark in all of their documentation. I must have grown up on the wrong side of the tracks because I remember thinking it was kind of cool. I even went so far as to seek out an OCR type wheel for my Diablo printer so that I could print listings at home that looked like the ones I did at work :-) What can I say? I was young and impressionable then... LOL. cje -- Chris Elmquist
Re: Motor generator
On 5/7/21 5:53 AM, Chris Elmquist wrote: > The HQ building (nee BTC) was built just a year before ETA started, > so 1982 or so. But somehow it ended up with very 70s-ish decor, even > if it was all new 70s-ish decor. It's possible they wanted all the guys > that moved down from ARHOPS and ADL to still feel at home... Oh, yeah, brightly painted exposed pipes, too. Probably inspired by the 1970's Centre Pompidou in Paris. CDC native decor was the usual 60's drab. The ubiquitous brwon vinyl-and-fabric Steelcase chairs, for example. Another hangover, thankfully abandoned, was the OCR-looking typeface on office typewriters. I hated the look of that so much that I managed to snag an IBM Model B Executive with proportional spacing when a GM's secretary moved to a Selectric. --Chuck
Re: Pipelining and Dec Jupiter thoughts....
On 05/07/2021 07:10 AM, Paul Koning via cctalk wrote:
They built an interesting hybrid system where you could
write the design partly as geometries (for things like
memory cells), partly as transistors, partly as gates, and
partly as C code. I remember an example, where they had a
transistor schematic for a single-bit latch, and then
wrapped it in a loop: "for (i=0; i < 64; i++) {
}". The magic was that (apart from the few
bits of explicit geometry-level design) it was all
parameterized, so they could regenerate the actual wafer
geometry overnight for a new fab.
That sounds a lot like VHDL, which can be used to synthesize
chip layout.
Another part of the puzzle was figuring out how to feed
100 watts of power to a chip, and get rid of that amount
of heat, neither of which were anywhere close to what was
done at the time. I still have some of the tech reports
that describe that piece (and I contributed a wild idea --
which unfortunately DEC didn't get around to patenting
before the project was shut down). paul
IBM was tinkering with high density ECL system construction
from 1965 or so, as a follow-on to the System 360. They had
several aborted projects, FS (Future System) and ACS
(Advanced Computer System) that were very advanced
supercomputers. The technology eventually came out as the
309x series, with several hundred MSI ECL chips on a ceramic
interconnect substrate, water-cooled
with a big plate with copper "nails" that pressed down on
the back of the ICs. That was the 308x system, introduced
in 1984.
Jon
Lecture: Forth: from the minicomputer to the microcontroller, 2021-05-08, 19:00
Hi all, you're invited to the Update computer club[0] public lecture series "Updateringar"[1]! Update is a Swedish computer club founded in 1983 whose members tinker with all kinds of computers, from Raspberry Pi to PDP-12. The club has a big collection of historic computers. In this lecture series we'll talk about everything related to computers: Historic and modern computers, operating systems, programming, hardware projects, creating art with computers, building a computer museum, and more. When: 2021-05-08, 19:00 CEST Where: https://bbb.cryptoparty.se/b/upd-0mo-m2u-aq8 Forth: from the minicomputer to the microcontroller Forth is an almost esoteric programming language in the eyes of most modern programmers, but still worth learning if only to expand your horizon. On modern microcontrollers the strengths that made Forth stand out in on 1970s minicomputers are relevant once again: fast enough execution, low worst case latency, full control over the system, powerful metaprogramming, and interactive development. This presentation will show how to overcome the initially near vertical learning curve and get the Mecrisp Stellaris Forth system running on a STM32 microcontroller without breaking the bank. Prior exposure to microcontrollers or assembler is helpful, but not required. Once the Forth system is running we will use it to explore either the hardware it's running on or its implementation and available implementation tradeoffs. Jan Bramkamp (CCCHB) The lecture is free and open to everyone. Upcoming: 2021-06-12, 19:00: How to start and run a computer museum. Thiemo Eddiks (Oldenburger Computer-Museum) Hope to see you there, Anke P.S.: I hope this is not too offtopic, but I assume there are people interested in Forth here. [0] http://www.update.uu.se/index_eng.html [1] https://www.update.uu.se/wiki/doku.php/projekt:updateringar
Re: Motor generator
On Thursday (05/06/2021 at 08:37PM -0700), Chuck Guzis wrote: > On 5/6/21 7:47 PM, Chris Elmquist wrote: > > We had a room on the ground floor at ETA that housed an MG set that > > ran the CY205 (and maybe the 835 and 875 too) in the basement. They > > had isolated the MG from the mounting pretty well in addition to > > sound proofing the room because with door closed, you couldn’t really > > tell it was in there— which was nice because the room was right off > > the main entry hallway :-) > > About all I recall from the few times that I visited the ETA facility > were the chairs upholstered in bright primary colors. The HQ building (nee BTC) was built just a year before ETA started, so 1982 or so. But somehow it ended up with very 70s-ish decor, even if it was all new 70s-ish decor. It's possible they wanted all the guys that moved down from ARHOPS and ADL to still feel at home... cje -- Chris Elmquist
Re: Pipelining and Dec Jupiter thoughts....
> On May 7, 2021, at 2:34 AM, Al Kossow via cctalk
> wrote:
>
> On 5/6/21 7:35 PM, Chris Zach via cctalk wrote:
>
>> Ah well. I don't think it was evil marketing or VAX monsters that killed the
>> KC10, it was simply the fact that the amazing instruction set couldn't be
>> pipelined to make it more efficient for hardware and the memory management
>> system wasn't as efficient as the pdp11/Vax MMU concept.
>
> I've never found any documentation on what System Concepts did to make faster
> systems. Just crank up the clock speed?
> DEC was already using ECL.
Speaking of ECL: DEC did some amazing work with ECL VLSI in the early 1990s.
There was an R project called "BIPS" (for "billion instructions per second")
-- which aimed to build a single-chip processor that would run at a gigahertz.
That was way faster than the clock speeds of the time, and the notion was that
to do this you needed to use ECL logic. But there wasn't any large scale
integration with ECL, so DEC set out to create that. Part of the problem was
that each ECL fab had its own design rules, and those fabs were a shaky
business (not enough volume). That meant creating a CAD system which could
adjust the design to a new set of design rules quickly.
They built an interesting hybrid system where you could write the design partly
as geometries (for things like memory cells), partly as transistors, partly as
gates, and partly as C code. I remember an example, where they had a
transistor schematic for a single-bit latch, and then wrapped it in a loop:
"for (i=0; i < 64; i++) { }". The magic was that (apart from the
few bits of explicit geometry-level design) it was all parameterized, so they
could regenerate the actual wafer geometry overnight for a new fab. The CAD
system also allowed extracting a behavioral model from the design.
The original plan, if I remember right, was to build an Alpha with this
technology. That morphed into building a MIPS, and I think they might have
gotten that to work.
Another part of the puzzle was figuring out how to feed 100 watts of power to a
chip, and get rid of that amount of heat, neither of which were anywhere close
to what was done at the time. I still have some of the tech reports that
describe that piece (and I contributed a wild idea -- which unfortunately DEC
didn't get around to patenting before the project was shut down).
paul
Re: Pipelining and Dec Jupiter thoughts....
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp10/ Has a *lot* of stuff. As I start cranking up my brain to drag BLT out of the shed and start working on it I'm finding this stuff to be a serious refresher. C On 5/7/2021 2:06 AM, Lee Courtney wrote: Chris - great and interesting overview. Do you have a reading list for more details? Thanks! Lee Courtney On Thu, May 6, 2021 at 7:35 PM Chris Zach via cctalk mailto:cctalk@classiccmp.org>> wrote: > Sort of. But while a lot of things happen in parallel, out of order, speculatively, etc., the programming model exposed by the hardware still is the C sequential model. A whole lot of logic is needed to create that appearance, and in fact you can see that all the way back in the CDC 6600 "scoreboard" and "stunt box". Some processors occasionally relax the software-visible order, which tends to cause bugs, create marketing issues, or both -- Alpha comes to mind as an example. Interesting to see this. I've been reading a lot recently about the Jupiter/Dolphin project and the more I read the more I understand why it just could not be done. At the time (and to an extent even now) the only way to really improve a system's performance was to pipeline the processor, and the Pdp10 instruction set just wasn't easy to do that with. They had a great concept: An Instruction fetch/decode system (IBOX), an execution engine (EBOX), the obligitory vector processor or FPU (HBOX) and of course the memory system (MBOX). Break the process up into steps and have the parts all work in parallel to boost performance. Unfortunately they started to find way too many cases where an indirect instruction would be fetched that would be based on the AC, which was being changed by another instruction in the EBOX. This would blow out all the prefetched work in the pipe, forcing the IBOX to do a costly reload. Likewise branch prediction couldn't be done well because most branches and skips depended on the value in the AC which was once again usually being modified in the EBOX down the pipe. As soon as it was modified the pipe had to be flushed and reloaded. It looks like they tried to put that logic into the IBOX to catch these issues, but that resulted in a flat processor that wasn't going to benefit from any parallelism, an endless series of bugs, and an IBOX that was pretty much running with its own EBOX. It got worse when they realized that the Extended memory segments in the 2060 architecture totally wrecked the concept of an instruction decoder/execution box. There were just too many places where an indirect instruction to another section which was then based on the AC's would result in Ibox tossing the queue and invalidating the translation buffers. Increasing the translation buffer helped (I think that's one of the things they did on the final 2065 to make it faster) but they couldn't make that big and fast enough. I guess an indirect jump instruction based on comparing the AC to an indirect address pointing to an extended segment would be enough to make any decoder just cry. It's sad to read, you can almost see then realizing it was doomed. The Foonly F1 was a screamer, but it was basically the KA10 instruction set and couldn't run extended memory segments like the 2060. And when they tried to do the same thing with the F4 it came out to be a little slower than a 2060. I used to think they put only one extended segment in the 2020 to cripple the box, but maybe they started running into the same problem and ran out of microcode space to try and address it. Couple this with the fact that much of the 20 series programs were built in assembler (and why not, it was an amazing thing to program) and you just had too many programs with cool bespoke code that would totally trash a pipeline. Fixing compilers to order instructions properly could have worked, but people just wrote in assembler it wasn't going to happen and they weren't about to re-code their app to please the new scheduler God. The VAX instruction set was a lot less beautiful, but could be pipelined easier especially with the dedicated MMU so they took the people and pipelined the hell out of the 780 resulting in the nifty 8600/8650 and later the 8800's. Dec learned their lesson when they built Alpha, and even Intel realized that their instruction set needed to be pipelined for the Pentium Pro and above processors. Ah well. I don't think it was evil marketing or VAX monsters that killed the KC10, it was simply the fact that the amazing instruction set couldn't be pipelined to make it more efficient for hardware and the memory management system
Re: Motor generator
The IBM 7090 used a motor generator, IBM model 7618 apparently http://ed-thelen.org/comp-hist/7090-PowerSupplyControl Marc > On May 4, 2021, at 5:03 PM, Jon Elson via cctalk > wrote: > > On 05/04/2021 06:06 PM, Donald via cctalk wrote: >> In the deep recesses of my mind I seem to remember something about S/360 >> machines using a motor generator. >> If I am right was this to create a stable power source at a certain >> frequency or voltage? > Nope. I know the 360/50 and 360/65 used a "converter-inverter" that > converted 208 3-phase > to about 280 V DC, then inverted it with a 4-SCR inverter feeding a resonant > transformer to > create 120 V 2.5 KHz regulated single-phase sine wave power. All the > critical loads in the CPU ran off this power. Notably, the I/O power > sequencer and console lamps power supply did not run off this power. The > converter-inverter made an absolutely HORRIBLE whine that could be heard 20+ > feet from the back of the CPU even in a very noisy machine room. > > The only "360" machine I know of that used 415 Hz was the Model 195, although > I can guess that > the 360/85 used 415 Hz also, as it was essentially the prototype of the > 370/165. > > The 370/145 used an internal motor/generator set in the back of the CPU > cabinet to produce 120 V 415 Hz 3-phase power. Larger 370's generally were > provided with UPS's instead of M/G sets to create the 415 Hz power. > > Also, the 709X series ran off 400 Hz from a motor/generator set. > > The 360/50 and /65, at least, were pretty sensitive to noise and short > dropouts in the mains supply. > The 370's with the MG sets rode through pretty severe power dips with no > effect at all, until the disk drives and tape drives went offline. > > Jon
Re: Pipelining and Dec Jupiter thoughts....
On 5/6/21 7:35 PM, Chris Zach via cctalk wrote: Ah well. I don't think it was evil marketing or VAX monsters that killed the KC10, it was simply the fact that the amazing instruction set couldn't be pipelined to make it more efficient for hardware and the memory management system wasn't as efficient as the pdp11/Vax MMU concept. I've never found any documentation on what System Concepts did to make faster systems. Just crank up the clock speed? DEC was already using ECL. It was pretty sad reading all of the memos when I first dug them out of the DEC corporate archive at CHM. I forget now if the architects for Jupiter were originally from IBM and got hired into DEC. Kotok wanted to go in a completely different direction with 36 bit systems.
Re: cctech Digest, Vol 80, Issue 5
Message: 18 > Date: Thu, 6 May 2021 15:18:04 +0200 > From: Liam Proven > To: Jay Jaeger , "General Discussion: On-Topic and > Off-Topic Posts" > Subject: Re: That VAXStation4000vlc 3W3 video connector > Message-ID: > < > camtencgkync++ct2gfpcvvnttjv-frvivhuoxlcjwdesf2w...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 5 May 2021 at 17:59, Jay Jaeger via cctalk > wrote: > > > I, for one, did find this helpful - one could make one of these up to > > test before possibly forking over the funds to build one properly. > > If anyone were up to making a small batch of these, I'd be happy to > pay for a few, plus shipping etc. I have 3 ? 4000VLCs and only 1 > monitor for 'em, and I hope to get them running again sometime... > > > I'd buy at least one, seeing as how it was my original question, and whatever I end up stitching together will be really gross. If whoever is doing it would ALSO do the much simpler DEC 15-pin to VGA adapter, I'd probably buy some of those too. Adam
Re: Pipelining and Dec Jupiter thoughts....
Chris - great and interesting overview. Do you have a reading list for more details? Thanks! Lee Courtney On Thu, May 6, 2021 at 7:35 PM Chris Zach via cctalk wrote: > > > Sort of. But while a lot of things happen in parallel, out of order, > speculatively, etc., the programming model exposed by the hardware still is > the C sequential model. A whole lot of logic is needed to create that > appearance, and in fact you can see that all the way back in the CDC 6600 > "scoreboard" and "stunt box". Some processors occasionally relax the > software-visible order, which tends to cause bugs, create marketing issues, > or both -- Alpha comes to mind as an example. > > Interesting to see this. > > I've been reading a lot recently about the Jupiter/Dolphin project and > the more I read the more I understand why it just could not be done. At > the time (and to an extent even now) the only way to really improve a > system's performance was to pipeline the processor, and the Pdp10 > instruction set just wasn't easy to do that with. > > They had a great concept: An Instruction fetch/decode system (IBOX), an > execution engine (EBOX), the obligitory vector processor or FPU (HBOX) > and of course the memory system (MBOX). Break the process up into steps > and have the parts all work in parallel to boost performance. > > Unfortunately they started to find way too many cases where an indirect > instruction would be fetched that would be based on the AC, which was > being changed by another instruction in the EBOX. This would blow out > all the prefetched work in the pipe, forcing the IBOX to do a costly > reload. > > Likewise branch prediction couldn't be done well because most branches > and skips depended on the value in the AC which was once again usually > being modified in the EBOX down the pipe. As soon as it was modified the > pipe had to be flushed and reloaded. It looks like they tried to put > that logic into the IBOX to catch these issues, but that resulted in a > flat processor that wasn't going to benefit from any parallelism, an > endless series of bugs, and an IBOX that was pretty much running with > its own EBOX. > > It got worse when they realized that the Extended memory segments in the > 2060 architecture totally wrecked the concept of an instruction > decoder/execution box. There were just too many places where an indirect > instruction to another section which was then based on the AC's would > result in Ibox tossing the queue and invalidating the translation > buffers. Increasing the translation buffer helped (I think that's one of > the things they did on the final 2065 to make it faster) but they > couldn't make that big and fast enough. I guess an indirect jump > instruction based on comparing the AC to an indirect address pointing to > an extended segment would be enough to make any decoder just cry. > > It's sad to read, you can almost see then realizing it was doomed. The > Foonly F1 was a screamer, but it was basically the KA10 instruction set > and couldn't run extended memory segments like the 2060. And when they > tried to do the same thing with the F4 it came out to be a little slower > than a 2060. I used to think they put only one extended segment in the > 2020 to cripple the box, but maybe they started running into the same > problem and ran out of microcode space to try and address it. > > Couple this with the fact that much of the 20 series programs were built > in assembler (and why not, it was an amazing thing to program) and you > just had too many programs with cool bespoke code that would totally > trash a pipeline. Fixing compilers to order instructions properly could > have worked, but people just wrote in assembler it wasn't going to > happen and they weren't about to re-code their app to please the new > scheduler God. > > The VAX instruction set was a lot less beautiful, but could be pipelined > easier especially with the dedicated MMU so they took the people and > pipelined the hell out of the 780 resulting in the nifty 8600/8650 and > later the 8800's. Dec learned their lesson when they built Alpha, and > even Intel realized that their instruction set needed to be pipelined > for the Pentium Pro and above processors. > > Ah well. I don't think it was evil marketing or VAX monsters that killed > the KC10, it was simply the fact that the amazing instruction set > couldn't be pipelined to make it more efficient for hardware and the > memory management system wasn't as efficient as the pdp11/Vax MMU concept. > > -- Lee Courtney +1-650-704-3934 cell
