Re: DEC H-500 Computer Lab pins and docs (was Re: Straight 8 up on Ebay just ...

[COURYHOUSE]

I wonder if any of the other digi labs leads are comparable?  We  have  
fabratek  and a few other brands. We got a bit   obsessed  with trainer type  
gear  for electronics and  physics  'this what that got  young people 
interested  back  when'  display. 
 
if there are any list member with a small turret lathe   that would be  
nice   to make  pins  with.   pretty labor intensive.Better would be  small 
Brown  and Sharpe screw machine would  make buckets of them  once you   got 
the machine all set up to make the run.  Or   cnc   machine ( I never ran 
one of those)   --- or as mentioned casting  some.
 
 
I will look and see is  we need any  pins.
 
 
Ed#.
 
 In a message dated 7/19/2016 11:30:10 P.M. US Mountain Standard Time,  
v.slyngs...@frontier.com writes:
 
From:  Karl-Wilhelm Wacker: Tuesday, July 19, 2016 5:21 PM
> This company does  custom tapered pins in brass -
> There are others out there I'm  sure.
> 
> I would find out what their minimum is and get a bulk  order together.
> 
>  http://www.stanlok.com/Taper_Pin_Pages/an386.html
> 
> A place I  worked for in the past had www.mill-max.com do a custon part 
for 
>  them,
> in the 100's - I would talk to them about a part  also.

>From what I can gather from the websites you referred me to,  
the tapered part of the pin's dimensions are very close to the woner if  
fabratecnarrow end of a standard taper #4/0 in the 3/4" length?  Have  
I done the math right on that?

>From there it would seem to be a  matter of getting a way to 
mount the wire, and optionally to shorten the  overall length 
of the pin and wire attachment to .65" from .75".  (Or  maybe 
just slot the pin's fat end, solder in the wire, and call it  good.)

I also thought about using a taper reamer to create molds and  
perhaps casting with solder around the fluxed wire.  (Casting  
brass or bronze seemed to require more heat than I could 
generate  easily.)

(For some reason that I've forgotten over the years, my eBay  
search for suitable pins looks for "42107" and "42279".  Never  
gotten any results for it, though.)

Vince  

Getting rid of books and documentation

[SPC]

Hello everyone. My employer plans to close the data center where I have
been working for several years usually. This involves the destruction or
elimination of all kinds of manuals, books, documents and diverse equipment
considering that this is deprecated. In general the hardware belongs to IBM
for contractual reasons, but not so with the documentation I have mentioned.

In my case I saved from destruction several old manuals and training
courses that I will begin to scan in the coming months. But I can not take
care of all available material. As an example there are enough red books
related IBM OS / 2 and its environment. There are also several CICS 2.1 ...
it is difficult to make an accurate count. I will try to make some more
detailed photos as possible and post them somewhere so that anyone
interested can review. Given my residence in the European Union, I think it
would be easier to send these documents to interested persons who also
reside in the EU, if necessary.

On the other hand I must say that we store yet one IBM 3705 operative until
few years ago. I don't know what plans have IBM for it. But that's another
story.

With kind regards
Sergio

Re: More PDP-11 front console scans

[Rod Smallwood]

Hi Noel
Most interesting and will aid no end with the panel project. 
The Panel Palace is having a top to bottom remodel so no systems for a few days 
more

Rod (Panelman) Smallwood

Sent from my iPad

> On 18 Jul 2016, at 21:21, Noel Chiappa  wrote:
> 
> I recently got access to an orginal PDP-11/70 front console (the one in
> magenta and rose), and also an 'Industrial' -11/70 (blue and red). Scans of
> both of these front panels have been added to my PDP-11 stuff page:
> 
>  http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/PDP-11_Stuff.html
> 
> My A3 scanner won't _quite_ eat the whole thing in one gulp, but it did manage
> to 'see' all the printed stuff. The actual panel is very slightly larger, so
> there are some thin sections on either side missing from the scan, _but_ on
> that page there is a mechanical drawing that gives the dimensions of the whole
> thing. So the two together should enable a complete reproduction.
> 
>   Noel

Re: Cray J932SE (was Re: Straight 8 up on Ebay just now)

[Paul Koning]

> On Jul 19, 2016, at 4:55 PM, Greg Stark  wrote:
> 
> On Tue, Jul 19, 2016 at 5:47 PM, Mouse  wrote:
>> For example, I once had a neighbour who replaced an outlet in his
>> kitchen.  Turned off the breaker, removed the old one, put in the new
>> one, all very nice.  Turned the breaker for that circuit back on and
>> popped the service main breaker.
> 
> Heh, I knew what was coming here and that it must mean you were in
> Canada (and only then checked the sender...)
> 
> But all this seems like a red herring. Surely the three-phase power
> requiring devices only require three phase for the cooling systems?
> Wouldn't it be easier to just use a modern switching power supply to
> provide 5V and feed cold air directly from your home hvac and not try
> to run 50-year old cooling and power?

Three phase power shows up in a bunch of places.  Some high current power 
supplies (pre switching era) use three phase input to increase the ripple 
frequency and reduce its amplitude, which significantly reduces the size of the 
required filter capacitors.  I remember that in the KL-10.  CDC 6000 mainframes 
go further, not only using 3 phase but also 400 Hz power for that reason (that 
also shrinks the transformers).

Cooling systems might run on 3 phase, or not.  The compressors in the 6000 
series CPU cabinets are 3 phase motors.  But the DD60 display uses 3 phase 
power only for the high voltage power supplies; the cooling fans are run off 
230 V 60 Hz single phase.

If I remember right, the RP04 uses 3 phase power for the spindle motor.  
Probably not for the logic power, though.

paul

Re: LASERS! && Freemont Street LED array (was Re: Cray J932SE (was Re: Straight 8 up on Ebay just now))

[Paul Koning]

> On Jul 19, 2016, at 4:58 PM, Wayne Sudol  wrote:
> 
> Laser technology to draw things like this is used in photo typesetters. A
> laser beam is focused onto a thin (about 1/2" thick)  many sided (about 8
> sides i think) spinning mirror. Each facet of the mirror is cut differently
> to deflict the beam up, down or center it on a sheet of moving paper or a
> plate of sensitized aluminum. 

Depending on the typesetter, the spinning mirror might just be horizontal 
deflection, with vertical positioning provided by the film transport motor.  
But in any case, those are raster scan systems.  It's very easy to scan a light 
beam in a regular pattern at high speed, with schemes like this.

DLP (micro-mirror chips) are also raster systems.  

paul

Re: LASERS! && Freemont Street LED array (was Re: Cray J932SE (was Re: Straight 8 up on Ebay just now))

[Mouse]

> As far as sending video from a computer frame buffer, I think it
> might be way too fast.

I wouldn't be doing that.  I cited the cg6 by way of contrast.  How the
points get into the display hardware is still open, but a framebuffer
seems unlikely to be involved.  (I suppose a framebuffer with something
like DVI-D could be used as a way to continuously replay sequences very
fast, but it has its limitations.  I'd rather build a hardware ring
buffer, but I tend towards hardware hackery.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: LASERS! && Freemont Street LED array (was Re: Cray J932SE (was Re: Straight 8 up on Ebay just now))

[Paul Koning]

> On Jul 20, 2016, at 9:12 AM, Mouse  wrote:
> 
>> As far as sending video from a computer frame buffer, I think it
>> might be way too fast.
> 
> I wouldn't be doing that.  I cited the cg6 by way of contrast.  How the
> points get into the display hardware is still open, but a framebuffer
> seems unlikely to be involved.  (I suppose a framebuffer with something
> like DVI-D could be used as a way to continuously replay sequences very
> fast, but it has its limitations.  I'd rather build a hardware ring
> buffer, but I tend towards hardware hackery.)

Given modern processor speeds, an obvious answer is to do it the same way the 
CDC mainframes drive the console: a program loop feeding coordinates to the 
interface.  You just need a loop that takes less than the acceptable refresh 
interval (30-50 ms or so) which isn't hard to do.  Especially since the 
deflection performance is likely to be the limiting factor.

paul

Re: Reproduction micros

[Noel Chiappa]

> From: Paul Koning

>> I always felt that RISC meant 'making the basic cycle time as fast as
>> possible by finding the longest path through the logic - i.e.  the
>> limiting factor on the cycle time - and removing it (thereby making the
>> instruction set less rich); then repeat'.

> "Making the cycle time as fast as possible" certainly applies, in
> spades, to the 6600.  The deeper you dig into its details, the more
> impressed you will be by the many different ways in which it does things
> faster than you would expect to be possible.

My formulation for RISC had two parts, though: not just minizing the cycle
time, but doing so by doing things that (as a side-effect) make the
instruction set less capable. I'm not very familiar with the 6600 - does this
part apply too?

>> RISC only makes (system-wide) sense in an environment in which memory
>> bandwidth is plentiful (so that having programs contain more, simpler
>> instructions make sense)

I should have pointed out that programs of that sort take not just more memory
bandwidth, but more memory to hold them. In this day of massive memories, no
biggie, but back in the core memory days, it was more of an issue.

>> One of the books about Turing argues that the ACE can be seen as a RISC
>> machine (it's not just that it's load-store; its overall architectural
>> philosophy is all about maximizing instruction rates).

I looked, and it's "Alan Turing's Automatic Computing Engine"; in Chapter 8,
"Computer architecture and the ACE computers", by Robert Doran (which is not,
for some reason, listed in the ToC).

> I think a lot of machine designers, though not all, were seriously
> interested in making them go fast.

Again, RISC has two legs, not just making the machine fast, but making them
fast by using techniques that, as a side-effect, make them inscrutable, and
difficult to program. The concept was that they would not, in general, be
programmed in assembler - precisely because they were so finicky.

Remember, the 801 was a combined hardware/compiler project, in which
complexity was moved from the hardware to the compiler; and early RISC
machines has things like no interlocks between pipeline stages. So they really
were not intended to be programmed in assembler - the compiler was critical.

The ACE, on the surface, didn't follow this, as it had no compiler. However,
at a higher level, Turing definitely followed the RISC philosophy of making
the machine as fast as possible, by using techniques that made it very hard to
program; instead of moving the complexity to the compiler, he moved it to the
programmer - the latter not being a problem, if you're Alan Turing! :-)

Noel

RE: DECmate, Rainbow, and Pro 350/380 parts

[Rob Jarratt]

Possibly for a Pro, I haven't actually worked out what it is that doesn't work 
on mine yet though...

Regards

Rob

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Paul
> Anderson
> Sent: 20 July 2016 05:04
> To: General Discussion: On-Topic and Off-Topic Posts
> ; cct...@vax-11.org
> Subject: DECmate, Rainbow, and Pro 350/380 parts
> 
> I just dug out what might be my last extra DECmate II CPU for a list member,
> and now have access to several Pro and Rainbow CPUs and other parts.
> 
> If you have any interest, please contact me off list. Shipping from Illinois.
> 
> Thanks, Paul

Re: LASERS! && Freemont Street LED array (was Re: Cray J932SE (was Re: Straight 8 up on Ebay just now))

[Swift Griggs]

On Tue, 19 Jul 2016, et...@757.org wrote:
> I live in Virginia but go to a number of events every year. I dabble 
> with music a little, have some synths and midi hardware (and of course 
> an Atari ST setup, and a luggable Pentium 200 with a SB/GUS and Voyetra 
> Sequencer!) Also dabble a little with saxophones but it's been a while!

I knew it! Piano, bass, violin, and guitar, here. I play them all badly 
but guitar a little less badly. I've been an amateur for about 10 years 
and I've been taking guitar lessons for about three years, now. 

Sax, eh? Cool. I've never tried a reed-based instrument.

You have all the cool sound gear you need if you have an ST and a machine 
with a GUS! Well maybe an Amiga with Octamed or Protracker, but Scream 
Tracker and Impulse Tracker also rocks fairly hard with a GUS, so never 
mind. :-)

As you can tell, I like trackers. I wrote a few MOD/IT/S3M files "back in 
the day".

> Hmm interesting! https://en.wikipedia.org/wiki/Scala_%28company%29 No 
> mention of freemont street but their current market is digital signage. 
> That would have been one of the earliest LED video screens ever!

Ah... I finally found some mention of it. Check this out:
 
"The light and sound spectacular runs on a master show controller and 
three sub-systems. The controller runs Stage Manager 3000 software on an 
Amiga computer originally installed when the show began in 1995. Murphy 
said the master controller sends commands to the video-display controller, 
light console and digitally automated audio system. The audio system, a 
recently upgraded LCS Matrix 3 system, distributes 550,000W of sound 
through 220 remote amplifiers located throughout the outdoor mall."

From:
http://www.signweb.com/content/night-lights

> I'm sure you know the thing about Garth/Dana Carvey? Him mentioning the 
> Unix book in Waynes World was a nod to his brother, his brother founded 
> NewTek the company behind the Amiga video toaster and the current NewTek 
> Tricaster stuff?

I did know some of that story, but not all. That's really cool. 

> Also, you can put together your own freemont-street-living-room at not 
> totally insane prices now. I put together this LED video screen [...] 

Whoa, very neat. When I was in college I used to run shows out of an old 
machine shop in an industrial part of town. It started as just a practice 
place. However, I knew a bunch of artists. They weren't just other college 
kids but artists who are pretty well known in the area and responsible for 
large public works etc... They all had daughters, you see... Anyhow, they 
talked me into letting them setup some art "openings" at this same little 
dinky venue I had going. One of them was an electrical engineering student 
who would come up from Texas Tech and cover the place with LED matrices 
that he had built. It was really impressive tech for the 1990s. He could 
do things like color cycling, and display static frames, but not 
animation. It always brought in lots of folks (200-800 per show usually) 
who were impressed by our tiny art shows with the "Light Room" display. 
People gave canned food or $$$ to get in and we raised a bit of food and 
money for charity that way, too.

-Swift

Re: LASERS! && Freemont Street LED array (was Re: Cray J932SE (was Re: Straight 8 up on Ebay just now))

[ethan]

I wouldn't be doing that.  I cited the cg6 by way of contrast.  How the
points get into the display hardware is still open, but a framebuffer
seems unlikely to be involved.  (I suppose a framebuffer with something
like DVI-D could be used as a way to continuously replay sequences very
fast, but it has its limitations.  I'd rather build a hardware ring
buffer, but I tend towards hardware hackery.)


Ah gotcha. In the laser show world there are gadgets properly called DACs, 
that usually connect to a host computer via USB, ethernet, or in the old 
days parallel port or PCI/ISA bus. They usually have 8 to 24 bits per 
channel, and will have channels for X, Y, then colors (Red, blue, green 
for diode based systems -- or some have a lot more channels as it's 
possible to have different sets of the same color on different 
wavelengths. 445nm blue looks a lot different than the 473nm blue, etc.)


The Etherdream is the open hobbyist ethernet/USB connected device and runs 
around $200. The Pangolin FB3 is Pangolin's USB and the FB4 is ethernet. 
The pangolin units mostly only work with Pangolin stuff when it comes to 
modern DACs but the Etherdream has more hobbyist type stuff using it. 
There is an "industry" pinout for the DB25 called ILDA that specifies the 
color and XY pins, safety interlocks and what not. Some DACs are 
differential signalling for running over longer cables.


The old school Pangolin hardware is called QuadMod boards, so if you find 
a QuadMod card in an Amiga or a QuadMod32 in an ISA PC that's what those 
are. The QuadMod2000 runs on PCI computers, but still approaching classic 
since it was a Windows 2000 product.



 -- 
Ethan O'Toole

RE: LASERS! && Freemont Street LED array (was Re: Cray J932SE (was Re: Straight 8 up on Ebay just now))

[Swift Griggs]

On Tue, 19 Jul 2016, Mark Green wrote:
> I don't know a lot about data transmission, my main application is 
> display.

Thanks anyway for the informed reply. Do you happen to know the best place 
to view large format holograms? I'm just looking for your personal 
opinion, since you seem to be in the know about such things. I've been 
fascinated with holograms since I was a kid (ie.. the National Geographic 
comment).

> The mathematics behind data transmission and display are similar, they 
> are based on wave propagation and diffraction and lots of Fourier 
> transforms.

FFT is a wonderful and amazing algorithm. It's akin to Diffie-Hellman in 
it's magicalness, to me. Without it, imagine how poor (or non-existent) 
some technologies would be!

> The laser power is not overly important, it's the resolution of 
> diffraction pattern or hologram that you produce.  It's a very redundant 
> coding scheme, so part of the signal can be lost and you can still 
> recover all the information.

Hmm, I'm guessing holograms have their own redundancy methods. I've seen 
Reed-Solomon matrices for such things, but that's the only one I know 
about. People write their Ph.D thesis on such things, so I'm not even a 
hobbyist, just an admirer of such tech. 

-Swift

Re: Reproduction micros

[Pete Turnbull]

On 20/07/2016 14:56, Noel Chiappa wrote:


My formulation for RISC had two parts, though: not just minizing the cycle
time, but doing so by doing things that (as a side-effect) make the
instruction set less capable.


At least for some RISC, that's more than a side effect.  While at Acorn 
in about 1987, I attended talks run by Sophie Wilson and Steve Furber 
where they described some of the design criteria for ARM.  They were 
very clear that the design goal was for every instruction to be executed 
in a single cycle[1], not just discarding longer instructions.  Thus the 
process wasn't about removing instructions but rather about deciding 
what (instructions and hardware) to put in as necessary and useful, so 
that more complex operations could be built up from short sequences of 
very fast instructions.  Kind of like the Unix philosophy of pipelining 
small utilities, in a way.


They also studied what had gone before: IBM 801, the Berkeley RISC 
project, Clipper, and others.  Steve describes some of this in his book 
"VLSI RISC Architecture and Organisation", which is a good read if you 
can find a copy.


[1] actually it's three clock cycles - fetch,decode,execute - but 
there's a three-stage pipeline so although the duration of any given 
instruction is 3 clocks, overall you get one instruction per clock [2].


[2] except I'm simplifying; for example there's only one memory port so 
load and store instructions take an extra cycle, since they need one 
memory access for the instruction fetch and one for the data - or more 
if it's a block data transfer, obviously.  And BTW it does have a mode 
to take advantage of reduced access times for sequential access in 
memories that support it. That's why the data sheets quote instruction 
times in terms of S (sequential) and N (non-sequential) cycles.


--
Pete

Re: LASERS! && Freemont Street LED array (was Re: Cray J932SE (was Re: Straight 8 up on Ebay just now))

[ethan]

I knew it! Piano, bass, violin, and guitar, here. I play them all badly
but guitar a little less badly. I've been an amateur for about 10 years
and I've been taking guitar lessons for about three years, now.
Sax, eh? Cool. I've never tried a reed-based instrument.


Very cool! I'm a.d.d. a bit with hobbies. On the synth side I recently 
picked up a Roland MT-32, so that was an achievement unlocked. Hope to 
find an Oberheim Matrix 6 at some point.



You have all the cool sound gear you need if you have an ST and a machine
with a GUS! Well maybe an Amiga with Octamed or Protracker, but Scream
Tracker and Impulse Tracker also rocks fairly hard with a GUS, so never
mind. :-)


I started computeres on Atari 800XL, then next computer was family's Tandy 
1000SX. At some point ended up with a Sound Blaster 1.0 in that (Still 
have the SB.) I don't remember if there was ever a tracker on that, but I 
remember Scream Tracker on the 386 (same sound card IIRC.) Spent a lot of 
time messing with Scream Tracker and Renaissance Composer 669.



As you can tell, I like trackers. I wrote a few MOD/IT/S3M files "back in
the day".


If you haven't looked, look on the hornet mod archive to see if any are on 
there? There was recently a video from popular artist deadmau5 where he 
was driving around interviewing some DJ and he asked the guy if he used to 
mess with ScreamTracker and all that -- I was pretty shocked.



Ah... I finally found some mention of it. Check this out:
"The light and sound spectacular runs on a master show controller and
three sub-systems. The controller runs Stage Manager 3000 software on an
Amiga computer originally installed when the show began in 1995. Murphy
said the master controller sends commands to the video-display controller,
light console and digitally automated audio system. The audio system, a
recently upgraded LCS Matrix 3 system, distributes 550,000W of sound
through 220 remote amplifiers located throughout the outdoor mall."
From:
http://www.signweb.com/content/night-lights


Interesting! Never seen the show, we tried to go to it once while at 
Defcon but messed up on the time. So they're still running it on an Amiga? 
That's awesome!


Some of the amusement parks had ride simulators that used Amiga + Laser 
disk. It's interesting where the Amiga found it's niche.




Whoa, very neat. When I was in college I used to run shows out of an old
machine shop in an industrial part of town. It started as just a practice
place. However, I knew a bunch of artists. They weren't just other college
kids but artists who are pretty well known in the area and responsible for
large public works etc... They all had daughters, you see... Anyhow, they
talked me into letting them setup some art "openings" at this same little
dinky venue I had going. One of them was an electrical engineering student
who would come up from Texas Tech and cover the place with LED matrices
that he had built. It was really impressive tech for the 1990s. He could
do things like color cycling, and display static frames, but not
animation. It always brought in lots of folks (200-800 per show usually)
who were impressed by our tiny art shows with the "Light Room" display.
People gave canned food or $$$ to get in and we raised a bit of food and
money for charity that way, too.


Very cool! I always think about trying to do some sort of music venue with 
a focus on live music + video recording / live streaming, or arcades + old 
computers. Here in Northern VA everything is crazy expensive tho, so 
coming across commercial space for pennies is difficult (at this moment.)



--
Ethan O'Toole

Re: Reproduction micros

[Paul Koning]

> On Jul 20, 2016, at 9:56 AM, Noel Chiappa  wrote:
> 
>> From: Paul Koning
> 
>>> I always felt that RISC meant 'making the basic cycle time as fast as
>>> possible by finding the longest path through the logic - i.e.  the
>>> limiting factor on the cycle time - and removing it (thereby making the
>>> instruction set less rich); then repeat'.
> 
>> "Making the cycle time as fast as possible" certainly applies, in
>> spades, to the 6600.  The deeper you dig into its details, the more
>> impressed you will be by the many different ways in which it does things
>> faster than you would expect to be possible.
> 
> My formulation for RISC had two parts, though: not just minizing the cycle
> time, but doing so by doing things that (as a side-effect) make the
> instruction set less capable. I'm not very familiar with the 6600 - does this
> part apply too?

Depending on what you mean by "less capable", I don't know that I would agree 
with that.  For example, I doubt that anyone would argue MIPS isn't a RISC 
architecture.  Yet MIPS is certainly very capable, and it certainly has a 
rather large instruction set.  The key point is that those instructions are, by 
and large, conceptually straightforward, and lend themselves to efficient 
(small cycle count, small transistor count) implementation.  Also, RISC does 
not use, or need, microcode.

In that sense, the 6000 certainly qualifies.  It has load/store, integer and 
float arithmetic on registers, boolean ops, and basic transfer of control 
instructions.  That's about it.  And the implementation is certainly 
straightforward.  A 6600 has a fair number of gates, but that stems from its 
multiple functional units, memory scheduling, and intense emphasis on speed, 
not from the inherent complexity of its instruction set.  A 6400, which is a 
single functional unit implementation of the same instruction set, is a whole 
lot smaller.

I recommend the excellent (and rather short) book by Thornton, one of the 6600 
designers: 
http://bitsavers.trailing-edge.com/pdf/cdc/cyber/books/DesignOfAComputer_CDC6600.pdf
  It will take you through the design all the way from transistor 
considerations and circuit elements to the instruction and memory scheduling 
machinery.

>>> RISC only makes (system-wide) sense in an environment in which memory
>>> bandwidth is plentiful (so that having programs contain more, simpler
>>> instructions make sense)
> 
> I should have pointed out that programs of that sort take not just more memory
> bandwidth, but more memory to hold them. In this day of massive memories, no
> biggie, but back in the core memory days, it was more of an issue.

I don't think that's necessarily all that big a delta.  Again using MIPS as an 
example, its program sizes are not that much larger than, say, the PDP11 for 
the same source code. 
> ...
>> I think a lot of machine designers, though not all, were seriously
>> interested in making them go fast.
> 
> Again, RISC has two legs, not just making the machine fast, but making them
> fast by using techniques that, as a side-effect, make them inscrutable, and
> difficult to program. The concept was that they would not, in general, be
> programmed in assembler - precisely because they were so finicky.

It is true that a few RISC architectures are not very scrutable.  Itanium is a 
notorious example, as are some VLIW machines.  But many RISC machines are much 
more sane.  MIPS and ARM certainly are no problem for any competent assembly 
language programmer.   Alpha is a bit harder but definitely doable too.

The burden on compiler optimizers tends to be higher.  But I would argue that's 
true for any high performance design: those have multiple pipelines, caches and 
prefetch, and lots of other stuff that affects performance.  The code optimizer 
has to know about these things.  (So does the assembly language programmer, if 
assembly is used for performance rather than for esoteric bare metal stuff like 
boot or diagnostic code.)  But, with the possible exception of extremely 
bizarre designs like Itanium, that's all perfectly doable.

paul

Re: LASERS! && Freemont Street LED array (was Re: Cray J932SE (was Re: Straight 8 up on Ebay just now))

[Swift Griggs]

On Wed, 20 Jul 2016, et...@757.org wrote:
> Very cool! I'm a.d.d. a bit with hobbies. On the synth side I recently 
> picked up a Roland MT-32, so that was an achievement unlocked. Hope to 
> find an Oberheim Matrix 6 at some point.

I'm not a keyboard guru like some on the list, but I've owned a Roland 
FP-9 and Alesis DG8. Now I use a Yamaha Clavinova. I miss the DG8, but I 
traded it off once it's internal amp started fritzing out. 

> I started computeres on Atari 800XL, then next computer was family's 
> Tandy 1000SX.

I had a friend with an Atari 800XL and I was very impressed with it. I 
remember a few demos (one with a metallic rendered robot walking toward 
you, I remember was most impressive). I was surprised that it was just an 
8bit machine. At first I thought it might have been 16 bit! 

> At some point ended up with a Sound Blaster 1.0 in that (Still have the 
> SB.) I don't remember if there was ever a tracker on that, but I 
> remember Scream Tracker on the 386 (same sound card IIRC.)

The only ones worth using that I'm aware of are Scream Tracker and Impulse 
Tracker and neither was around in the 16 bit ISA days pre-386, IIRC. I 
doubt Scream Tracker would be able to function on a 286 anyhow. It puts a 
486DX2/66 at about 50% CPU load, from my recollection. The Amiga trackers 
were more efficient, but you got fewer channels, too. OctaMED was 
8-channel and that seemed massive until it wasn't.

> Spent a lot of time messing with Scream Tracker and Renaissance Composer 
> 669.

Yes! I almost forgot about Composer, that was another good one.

> If you haven't looked, look on the hornet mod archive to see if any are 
> on there?

Several made it there over the years. I can't remember which ones, but I 
do remember one day I was listening to Nectarine Radio and heard one of my 
own Protracker MODs. That was awesome.

> There was recently a video from popular artist deadmau5 where he was 
> driving around interviewing some DJ and he asked the guy if he used to 
> mess with ScreamTracker and all that -- I was pretty shocked.

He was just showing proper street cred. +1 Deadmou5

> Interesting! Never seen the show, we tried to go to it once while at 
> Defcon but messed up on the time. So they're still running it on an 
> Amiga? That's awesome!

It took some extra hard Googling to find anything about it. The only time 
I'd even heard about it was when I was actually in Vegas working as a Def 
Con goon.

> Some of the amusement parks had ride simulators that used Amiga + Laser 
> disk. It's interesting where the Amiga found it's niche.

Ahhh, those air-car-mounted-on-hydraulics "ride" thingys? Huh. Laser disc 
was always a cool thing, too. Remember "Time Traveler" ? That 
"holographic" (it wasn't really but it looked damn cool) game were the 
characters appeared in front of some kind of curved mirror volumetric 
display uhm, thingamabob? It used a Laserdisc too. Of course I loved Space 
Ace and Dragons Lair along with every other self-respecting geek, too. 
Also, my favorite was called "Thayer's Quest" in which you were a wizard's 
apprentice.

> Very cool! I always think about trying to do some sort of music venue 
> with a focus on live music + video recording / live streaming, or 
> arcades + old computers.


> Here in Northern VA everything is crazy expensive tho, so coming across 
> commercial space for pennies is difficult (at this moment.)

Most commercial real estate weasels think you are the next "sucker" coming 
through the door. They seem to believe that some old crufty warehouse 
that's been empty for a decade is actually worth the ridiculous rents they 
charge. You'd think it'd be better to have the buildings occupied and 
someone giving you a bit or two to cover the property taxes, but they 
still don't seem to see their clients as anything more than walking cash 
registers. It's definitely a hard slog to find a screaming deal on space. 
All the hacker-spaces here in big-D have lots of folks pitching in to make 
ends meet. The first one here with an Ethan-style laser arcade will 
definitely get my membership dues.

Then there is the problem that nobody but old dudes remember how fun/cool 
arcades could be, back in a time when they looked a lot more like 
nightclubs. I remember them so crowded you had to go out for some fresh 
air. Flynn's Arcade may never live again, but it's still a paradigm of 
cool in my mind. Then again, I'm probably too old now to adjudicate "cool" 
for anyone. If you do open an laser-illuminated LED-walled arcade, let us 
all know so we can put you on the cctalk road-trip map. We'll rent a bus 
in Seattle, and drive to your place (or visa versa). I nominate Fred to 
run the logistics. I'll drive. :-P

-Swift

Re: Reproduction micros

[Pete Turnbull]

On 20/07/2016 16:44, Paul Koning wrote:


It is true that a few RISC architectures are not very scrutable.
Itanium is a notorious example, as are some VLIW machines.  But many
RISC machines are much more sane.  MIPS and ARM certainly are no
problem for any competent assembly language programmer.


Indeed.  I've written a modest amount of assembly language code for 
MIPS, and a bit more for ARM, and I didn't find either at all 
inscrutable.  Yes, be aware of pipelining and branches and so on, but 
it's not hard.


--
Pete

RISC assembly by hand dammit was Re: Reproduction micros

[Cameron Kaiser]

> > It is true that a few RISC architectures are not very scrutable.
> > Itanium is a notorious example, as are some VLIW machines.  But many
> > RISC machines are much more sane.  MIPS and ARM certainly are no
> > problem for any competent assembly language programmer.
> 
> Indeed.  I've written a modest amount of assembly language code for 
> MIPS, and a bit more for ARM, and I didn't find either at all 
> inscrutable.  Yes, be aware of pipelining and branches and so on, but 
> it's not hard.

I actually find PowerPC assembly very tractable. No branch delay slots,
for example, and reasonable orthogonality. The major thing that's annoying
about it is the "mscdfr" instructions (Means Something Completely Different
For r0 -- addi(s), for example). I've handwritten a great deal of PPC
assembly over the years, and even written a JIT for it.

The late PA-RISC was also a very sane ISA to handwrite assembly in.

SPARC is a little tricky with the register windows, but I guess that's
really no different than writing for any other particular ABI.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Po-Ching Lives! 

Re: Reproduction micros

[Cameron Kaiser]

> Also, RISC does not use, or need, microcode.

I'm not sure what you mean by this, but (for example) many POWER
implementations have microcode (example: the 970/G5, which is descended from
POWER4).

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- There are three kinds of people: those who can count and those who can't. --

Re: Reproduction micros

[Paul Koning]

> On Jul 20, 2016, at 1:34 PM, Cameron Kaiser  wrote:
> 
>> Also, RISC does not use, or need, microcode.
> 
> I'm not sure what you mean by this, but (for example) many POWER
> implementations have microcode (example: the 970/G5, which is descended from
> POWER4).

What I meant is that I had no idea such things existed.  Very curious.  Learn 
something new every day.  What do they use this for?

The closest to microcode I'd ever heard of before is the "epicode" in Alpha.  
Or was that Prism?  Anyway, a DEC RISC architecture where some privileged stuff 
was done in code running in a corner of the chip.  Not actual microcode because 
it was essentially the standard instruction set, somewhat extended and running 
in a special processor state.

paul

Re: Reproduction micros

[Swift Griggs]

On Wed, 20 Jul 2016, Paul Koning wrote:
> The closest to microcode I'd ever heard of before is the "epicode" in 
> Alpha.  Or was that Prism?

PALcode? That's sort of an amalgamation of microcode and emulation, IIRC. 
I don't know what 'epicode' is, though.

-Swift

Re: Reproduction micros

[Paul Koning]

> On Jul 20, 2016, at 1:53 PM, Swift Griggs  wrote:
> 
> On Wed, 20 Jul 2016, Paul Koning wrote:
>> The closest to microcode I'd ever heard of before is the "epicode" in 
>> Alpha.  Or was that Prism?
> 
> PALcode? That's sort of an amalgamation of microcode and emulation, IIRC. 
> I don't know what 'epicode' is, though.

PALcode sounds right.  I think "epicode" was the same thing, but in PRISM -- 
which was the second RISC chip architecture DEC built, and canceled before 
shipping it.  (Titan was the first; Alpha the third.)

paul

Re: Who Loves IBM Tape?

[Eric Smith]

On Sun, Jul 17, 2016 at 10:41 AM, Al Kossow  wrote:
> 7340 Hypertape was developed for the Stretch project, and were mainly used by 
> NSA.

You might be confusing Hypertape (7340 drive) with the "Tractor"
robotic tape cartridge system (7955), which was designed for the NSA
Harvest system (7950).*  I don't think Hypertape was ever used on
Stretch or Harvest.

Tractor used 1.75 inch tape. Only one Tractor system was built, and
was used from 1962 to 1976 by the NSA.

Hypertape cartridges were physically smaller than Tractor cartridges.
Hypertape used 1 inch tape with phase encoding, at a tape speed of
112.5 inches per second for data transfer and 225 ips for rewind. The
original transfer rate was 170,000 characters per second.

The 7340 Model 1 drive was used on the 7074 and other 70xx systems
with the 7640 control unit. The first customer for the 7340 Model 1
was the National Revenue Service of Canada.

The 7340 Model 3 drive doubled the recording denisty and transfer
rate, and was used on 360 systems with the 2802 control unit. There
were only two 7340 Model 3 installations outside IBM, at the Internal
Revenue Service and Boeing.

Source for Hypertape information: _IBM's 360 and Early 370 Systems_,
by Emerson W. Pugh, Lyle R. Johnson, and John H. Palmer

* The 7950 Harvest system was a 7030 Stretch system with the addition
of the 7951 stream processing unit, 7952 high-performance core memory,
7955 Tractor tape system, and 7959 high-speed exchange.

Re: Cray J932SE (was Re: Straight 8 up on Ebay just now)

[Chuck Guzis]

On 07/20/2016 05:59 AM, Paul Koning wrote:

> Three phase power shows up in a bunch of places.  Some high current 
> power supplies (pre switching era) use three phase input to increase 
> the ripple frequency and reduce its amplitude, which significantly 
> reduces the size of the required filter capacitors.  I remember that 
> in the KL-10.  CDC 6000 mainframes go further, not only using 3
> phase but also 400 Hz power for that reason (that also shrinks the 
> transformers).

Indeed, I was going to mention this.  A full-wave 3-phase rectifier
configuration produces ripple at six times the distribution frequency
and the output is largely DC.   Even more interesting is the use of a
transformer with both wye- and delta-configured secondaries.  This
introduces a bonus phase shift of 30 degrees, with the result that the
ripple frequency is twelve times the mains frequency (e.g. 720Hz on 60Hz
mains).

I remember working summers as a projectionist at a drive-in movie
theater that used carbon-arc lamps.  Many such installations simply used
a motor-DC generator for the arc supply, but one theater used a
transformer-rectifier setup on 3-phase power.  Even above the noise of
the projector and the exhaust fans, you could hear the 360 Hz "whine" of
the arc lamps.

3 phase induction motors are simple in the extreme--no starting
capacitors or coils.  I think (but am not sure) that they also deliver a
lot more starting torque than the typical single-phase induction
motor--at least that's been my experience with machine tools.

FWIW,
--Chuck

Re: Reproduction micros

[Al Kossow]

On 7/20/16 10:34 AM, Cameron Kaiser wrote:
>> Also, RISC does not use, or need, microcode.
> 

this confuses architecture and implementation

the Ridge 32 has a RISC instruction set, but was implemented in micrcode

Re: Reproduction micros

[Cameron Kaiser]

> > > Also, RISC does not use, or need, microcode.
> > 
> > I'm not sure what you mean by this, but (for example) many POWER
> > implementations have microcode (example: the 970/G5, which is descended from
> > POWER4).
> 
> What I meant is that I had no idea such things existed.  Very curious.
> Learn something new every day.  What do they use this for?

A number of instructions on G5 processors are broken down into smaller
uops which are sequenced, and affect execution flow and instruction level
parallelism. The microcode used by the uops is purely internal to the chip
and is stored in a sidecar ROM. Part of my optimizing code for G5 systems
was to avoid microcoded/cracked instructions as much as possible except
where there was no alternative for functionality.

The Cell PPU, also Power ISA, also contains microcoded instructions and
they have similar penalties.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- I've had a wonderful time, but this wasn't it. -- Groucho Marx -

Re: Reproduction micros

[Liam Proven]

On 20 July 2016 at 17:44, Paul Koning  wrote:
> It is true that a few RISC architectures are not very scrutable.  Itanium is 
> a notorious example, as are some VLIW machines.


Hang on. Itanium is not RISC -- it *is* VLIW. Isn't it?

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Liam Proven]

On 20 July 2016 at 19:34, Cameron Kaiser  wrote:
>> Also, RISC does not use, or need, microcode.
>
> I'm not sure what you mean by this, but (for example) many POWER
> implementations have microcode (example: the 970/G5, which is descended from
> POWER4).

Isn't the general belief that many successful architectures that
started out as RISC, and are still marketed as RISC, aren't actually
very RISC-like at all any more?

And, secondarily, that ARM is one of the ones that has stayed closest
to its roots, unlike, e.g., POWER, SPARC and, well, most of the big
hot UNIX workstation chips of the '90s?


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Liam Proven]

On 19 July 2016 at 17:04, Peter Corlett  wrote:
> From there, it seems to be saying that the essence of the invention is that 
> the
> ARM ISA is RISC, it is a load-store architecture, and the CPU was pipelined.
>
> RISC implies a load-store architecture, so that claim is redundant.

Could you expand on that, please? I think that IKWYM but I'm not sure.

> Pipelining is an older idea: the 1979-vintage 68000 does it, and the 
> 1982-vintage
> 68010 even detects certain string/loop instructions in its pipeline and avoids
> re-fetching them from memory when repeating the sequence.

I don't think that article or anything else is claiming that ARM
invented RISC, was the first RISC processor, or even significantly
advanced the RISC art.

What is says is that ARM was built by a very small team -- which it
was. That part of that is that Wilson did a lot of the design
single-handed -- which is true.

I don't know about her simulating the design in her head; from what
I've heard from several sources, including Wilson herself in a talk at
ROUGOL, was that the first simulation of the ARM instruction set was a
BBC BASIC program running on a BBC Micro. That in itself is quite
remarkable.

I think it's fair to say that ARM was a relatively early RISC
implementation *in term of single chip processors*, that it was
remarkably simple compared to others of that time (as in, smaller,
more reduced, fewer transistors, etc.), that its power consumption
always was remarkably low and its performance, for its first decade or
so, remarkably high.

> IMO, it's the predicated instructions that is ARM's special sauce and the real
> innovation that gives it a performance boost. Without those, it'd be just a 32
> bit wide 6502 knockoff.

Do tell...?


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Paul Koning]

> On Jul 20, 2016, at 3:02 PM, Liam Proven  wrote:
> 
> ...
> I think it's fair to say that ARM was a relatively early RISC
> implementation *in term of single chip processors*, that it was
> remarkably simple compared to others of that time (as in, smaller,
> more reduced, fewer transistors, etc.), that its power consumption
> always was remarkably low and its performance, for its first decade or
> so, remarkably high.

I don't remember the earlier ARM designs, but it was my impression that DEC's 
StrongARM was the one that made really large strides in low power (especially 
power per MHz of clock speed).  Interestingly enough, StrongARM was one of the 
few (and the first?) independent designs; it used the ARM architecture 
specification but not the actual logic design as others did.

paul

Re: Getting rid of books and documentation

[Torfinn Ingolfsen]

On Wed, Jul 20, 2016 at 9:46 AM, SPC  wrote:
> Hello everyone. My employer plans to close the data center where I have
> been working for several years usually. This involves the destruction or
> elimination of all kinds of manuals, books, documents and diverse equipment

A longshot: if there is any Norsk Data documentation there, a list of
titles would be interesting.

A few of us are preserving what we can on NDWiki.org
-- 
Regards,
Torfinn Ingolfsen

Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Ian Finder]

I have a few GRiD compass systems and some are suffering from massively
decreased contrast on the edges of the displays:

[See the system on the left]
https://www.instagram.com/p/BIGGzUzgat-/?taken-by=tr1nitr0n

[Or this one:]
http://www.ripstick.com/USCM/images/Grid_Compass_1101_Laptop_in_Box_002.jpg

Meanwhile, other EL systems I have- like my HP integral PC- haven't
succumbed to this.

I have seen similar issues on amLCD displays in my Tadpole, Toshiba and
other machines, so this is something we all may have to confront.

---

I was wondering if the folks here had theories?

I'm thinking moisture (or air) might be leaking in from the edges of the
glass panes, perhaps from a compromised seal- sorry for the silly picture
but you can see the composition of the display here:

https://www.instagram.com/p/6BXaLBtSzd/?taken-by=tr1nitr0n

Does anyone know how one might prevent this from progressing- storage tips?

Could it be reversed?

Better yet, does anyone have ideas on how to rapidly dehydrate the display?
Perhaps there is even a way to re-seal them.

I think all two-glass-pane displays that don't have a vacuum may eventually
succumb to this.

Perhaps it is just oxidation and not moisture, but I'd love to hear any
theories.

Thanks,

- Ian


-- 
   Ian Finder
   (206) 395-MIPS
   ian.fin...@gmail.com

Re: Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Paul Koning]

> On Jul 20, 2016, at 3:52 PM, Ian Finder  wrote:
> 
> ...
> Does anyone know how one might prevent this from progressing- storage tips?
> 
> Could it be reversed?
> 
> Better yet, does anyone have ideas on how to rapidly dehydrate the display?
> Perhaps there is even a way to re-seal them.
> 
> I think all two-glass-pane displays that don't have a vacuum may eventually
> succumb to this.

I don't know how to address that problem.  But FWIW, it doesn't happen to all 
two-glass pane displays; my 1970s era PLATO terminal (with the orange plasma 
panel) still works perfectly.

paul

Re: Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Ian Finder]

Yes, but as I mentioned:

"> I think all two-glass-pane displays that don't have a vacuum may
eventually
> succumb to this."

I have plenty of good displays. It seems like it may happen eventually.
Also aren't plasmas pressurized, unlike LCD and EL?

On Wed, Jul 20, 2016 at 12:56 PM, Paul Koning 
wrote:

>
> > On Jul 20, 2016, at 3:52 PM, Ian Finder  wrote:
> >
> > ...
> > Does anyone know how one might prevent this from progressing- storage
> tips?
> >
> > Could it be reversed?
> >
> > Better yet, does anyone have ideas on how to rapidly dehydrate the
> display?
> > Perhaps there is even a way to re-seal them.
> >
> > I think all two-glass-pane displays that don't have a vacuum may
> eventually
> > succumb to this.
>
> I don't know how to address that problem.  But FWIW, it doesn't happen to
> all two-glass pane displays; my 1970s era PLATO terminal (with the orange
> plasma panel) still works perfectly.
>
> paul
>
>
>


-- 
   Ian Finder
   (206) 395-MIPS
   ian.fin...@gmail.com

Re: Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Paul Koning]

> On Jul 20, 2016, at 4:02 PM, Ian Finder  wrote:
> 
> Yes, but as I mentioned:
> 
> "> I think all two-glass-pane displays that don't have a vacuum may
> eventually
>> succumb to this."
> 
> I have plenty of good displays. It seems like it may happen eventually.
> Also aren't plasmas pressurized, unlike LCD and EL?

They aren't vacuum, but close.  I don't know what the pressure is, but it's way 
below outside air pressure.

paul

Re: Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Cameron Kaiser]

> > Better yet, does anyone have ideas on how to rapidly dehydrate the display?
> > Perhaps there is even a way to re-seal them.
> > 
> > I think all two-glass-pane displays that don't have a vacuum may eventually
> > succumb to this.
> 
> I don't know how to address that problem.  But FWIW, it doesn't happen to
> all two-glass pane displays; my 1970s era PLATO terminal (with the orange
> plasma panel) still works perfectly.

My Solbourne S3000 (also flaring orange gas plasma) looks great too, ca. 1991.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Talk sense to a fool and he calls you foolish. -- Euripedes 

Re: Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Ian Finder]

I'm happy for everyone with great displays, but I have never seen a repro
on plasma because they are pressurized. And I've seen plenty of EL displays
that still look great... So far.

So can we stay on topic a little :)

On Wed, Jul 20, 2016 at 1:15 PM, Cameron Kaiser 
wrote:

> > > Better yet, does anyone have ideas on how to rapidly dehydrate the
> display?
> > > Perhaps there is even a way to re-seal them.
> > >
> > > I think all two-glass-pane displays that don't have a vacuum may
> eventually
> > > succumb to this.
> >
> > I don't know how to address that problem.  But FWIW, it doesn't happen to
> > all two-glass pane displays; my 1970s era PLATO terminal (with the orange
> > plasma panel) still works perfectly.
>
> My Solbourne S3000 (also flaring orange gas plasma) looks great too, ca.
> 1991.
>
> --
>  personal:
> http://www.cameronkaiser.com/ --
>   Cameron Kaiser * Floodgap Systems * www.floodgap.com *
> ckai...@floodgap.com
> -- Talk sense to a fool and he calls you foolish. -- Euripedes
> 
>



-- 
   Ian Finder
   (206) 395-MIPS
   ian.fin...@gmail.com

Re: Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Ian Finder]

If anyone has a plasma that *DOES* repro, that would be very interesting,
but I expect the technology is different enough that that won't happen due
to the pressurization.

Re: Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Brent Hilpert]

On 2016-Jul-20, at 12:52 PM, Ian Finder wrote:

> I have a few GRiD compass systems and some are suffering from massively
> decreased contrast on the edges of the displays:
> 
> [See the system on the left]
> https://www.instagram.com/p/BIGGzUzgat-/?taken-by=tr1nitr0n
> 
> [Or this one:]
> http://www.ripstick.com/USCM/images/Grid_Compass_1101_Laptop_in_Box_002.jpg
> 
> Meanwhile, other EL systems I have- like my HP integral PC- haven't
> succumbed to this.
> 
> I have seen similar issues on amLCD displays in my Tadpole, Toshiba and
> other machines, so this is something we all may have to confront.
> 
> ---
> 
> I was wondering if the folks here had theories?
> 
> I'm thinking moisture (or air) might be leaking in from the edges of the
> glass panes, perhaps from a compromised seal- sorry for the silly picture
> but you can see the composition of the display here:
> 
> https://www.instagram.com/p/6BXaLBtSzd/?taken-by=tr1nitr0n
> 
> Does anyone know how one might prevent this from progressing- storage tips?
> 
> Could it be reversed?
> 
> Better yet, does anyone have ideas on how to rapidly dehydrate the display?
> Perhaps there is even a way to re-seal them.
> 
> I think all two-glass-pane displays that don't have a vacuum may eventually
> succumb to this.
> 
> Perhaps it is just oxidation and not moisture, but I'd love to hear any
> theories.


Are you convinced this is a panel problem rather than a driver electronics 
problem?

In one picture it looks like the sort of thing that happens when you have to 
turn up the brightness (for some types of display), resulting in partial 
illumination in other areas of the screen.

I've never had opportunity to repair or work on EL flat-panel displays, I'm not 
familiar with the driving techniques and requirements, so this is just a 
query/guess. (I see it's an X/Y matrix drive scheme, but the voltages & timing 
& phasing I don't know about.)

Re: Reproduction micros

[Pete Turnbull]

On 20/07/2016 20:29, Paul Koning wrote:


I don't remember the earlier ARM designs, but it was my impression
that DEC's StrongARM was the one that made really large strides in
low power (especially power per MHz of clock speed).  Interestingly
enough, StrongARM was one of the few (and the first?) independent
designs; it used the ARM architecture specification but not the
actual logic design as others did.


That's almost right.  An ARM2 dissipates less than 2W (according to my 
data sheet, but that's maximum allowed dissipation and I think typical 
consumption is much less than 1W) with its normal 5V supply, averaging 
some 6-8 MIPS with a 12MHZ clock.  It's a 2micron CMOS process.  The 
original ARM used a 3micron process but was only used for testing and 
development; I can't remember what ARM3 used but IIRC it was a lot 
smaller though still the same core design, and it's certainly low power 
(under 1W) despite having a lot more transistors (largely for cache) and 
a higher clock speed.


StrongARM SA-110 uses roughly 450mW, but with Vcc around 1.75V it 
claimed about 100 MIPS at 100MHz, in a 0.35micron process.  It was a 
collaboration between ARM and Digital, but AIUI the hardware design was 
done mainly or perhaps completely by Digital.  Yes, it was the first 
independent design, as far as I know.  Earliest designs were done by 
Acorn and later I think by Acorn with VLSI, and ARM with Digital 
(ARM6/7).  I had access to early SA-110 development stuff for a project 
in 1996 but I had to go to Digital to get it, not Acorn/ARM.


--
Pete

Re: Reproduction micros

[Paul Koning]

> On Jul 20, 2016, at 6:28 PM, Pete Turnbull  wrote:
> 
> On 20/07/2016 20:29, Paul Koning wrote:
> 
>> I don't remember the earlier ARM designs, but it was my impression
>> that DEC's StrongARM was the one that made really large strides in
>> low power (especially power per MHz of clock speed).  Interestingly
>> enough, StrongARM was one of the few (and the first?) independent
>> designs; it used the ARM architecture specification but not the
>> actual logic design as others did.
> 
> That's almost right.  An ARM2 dissipates less than 2W (according to my data 
> sheet, but that's maximum allowed dissipation and I think typical consumption 
> is much less than 1W) with its normal 5V supply, averaging some 6-8 MIPS with 
> a 12MHZ clock.  It's a 2micron CMOS process.  The original ARM used a 3micron 
> process but was only used for testing and development; I can't remember what 
> ARM3 used but IIRC it was a lot smaller though still the same core design, 
> and it's certainly low power (under 1W) despite having a lot more transistors 
> (largely for cache) and a higher clock speed.
> 
> StrongARM SA-110 uses roughly 450mW, but with Vcc around 1.75V it claimed 
> about 100 MIPS at 100MHz, in a 0.35micron process.  It was a collaboration 
> between ARM and Digital, but AIUI the hardware design was done mainly or 
> perhaps completely by Digital.  Yes, it was the first independent design, as 
> far as I know.  Earliest designs were done by Acorn and later I think by 
> Acorn with VLSI, and ARM with Digital (ARM6/7).  I had access to early SA-110 
> development stuff for a project in 1996 but I had to go to Digital to get it, 
> not Acorn/ARM.

Thanks for the backup data.  I have the impression that power gating and clock 
gating (essentially only running small parts of the chip rather than all of it 
all the time) is one big reason why the SA-110 is so power-efficient.

I still have an SA-110 eval board tucked away in the workshop.

paul

Re: Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Ian Finder]

No, I'm not convinced the EL repro isn't a driver electronics issue.

I'm just a little confused about why the issue congregates at the edges of
the displays. Any ideas why that might be?

I may try swapping the panels around this evening if I am feeling brave.

On Wednesday, July 20, 2016, Brent Hilpert  wrote:

> On 2016-Jul-20, at 12:52 PM, Ian Finder wrote:
>
> > I have a few GRiD compass systems and some are suffering from massively
> > decreased contrast on the edges of the displays:
> >
> > [See the system on the left]
> > https://www.instagram.com/p/BIGGzUzgat-/?taken-by=tr1nitr0n
> >
> > [Or this one:]
> >
> http://www.ripstick.com/USCM/images/Grid_Compass_1101_Laptop_in_Box_002.jpg
> >
> > Meanwhile, other EL systems I have- like my HP integral PC- haven't
> > succumbed to this.
> >
> > I have seen similar issues on amLCD displays in my Tadpole, Toshiba and
> > other machines, so this is something we all may have to confront.
> >
> > ---
> >
> > I was wondering if the folks here had theories?
> >
> > I'm thinking moisture (or air) might be leaking in from the edges of the
> > glass panes, perhaps from a compromised seal- sorry for the silly picture
> > but you can see the composition of the display here:
> >
> > https://www.instagram.com/p/6BXaLBtSzd/?taken-by=tr1nitr0n
> >
> > Does anyone know how one might prevent this from progressing- storage
> tips?
> >
> > Could it be reversed?
> >
> > Better yet, does anyone have ideas on how to rapidly dehydrate the
> display?
> > Perhaps there is even a way to re-seal them.
> >
> > I think all two-glass-pane displays that don't have a vacuum may
> eventually
> > succumb to this.
> >
> > Perhaps it is just oxidation and not moisture, but I'd love to hear any
> > theories.
>
>
> Are you convinced this is a panel problem rather than a driver electronics
> problem?
>
> In one picture it looks like the sort of thing that happens when you have
> to turn up the brightness (for some types of display), resulting in partial
> illumination in other areas of the screen.
>
> I've never had opportunity to repair or work on EL flat-panel displays,
> I'm not familiar with the driving techniques and requirements, so this is
> just a query/guess. (I see it's an X/Y matrix drive scheme, but the
> voltages & timing & phasing I don't know about.)
>
>

-- 
   Ian Finder
   (206) 395-MIPS
   ian.fin...@gmail.com

Re: Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Ian Finder]

Hmm. I suppose recapping is a logical next step. There are also four
adjustable inductors and a single trimpot inside the display assembly.

I haven't been able to find a single clue about what they do.

On Wednesday, July 20, 2016, Ian Finder  wrote:

> No, I'm not convinced the EL repro isn't a driver electronics issue.
>
> I'm just a little confused about why the issue congregates at the edges of
> the displays. Any ideas why that might be?
>
> I may try swapping the panels around this evening if I am feeling brave.
>
> On Wednesday, July 20, 2016, Brent Hilpert  > wrote:
>
>> On 2016-Jul-20, at 12:52 PM, Ian Finder wrote:
>>
>> > I have a few GRiD compass systems and some are suffering from massively
>> > decreased contrast on the edges of the displays:
>> >
>> > [See the system on the left]
>> > https://www.instagram.com/p/BIGGzUzgat-/?taken-by=tr1nitr0n
>> >
>> > [Or this one:]
>> >
>> http://www.ripstick.com/USCM/images/Grid_Compass_1101_Laptop_in_Box_002.jpg
>> >
>> > Meanwhile, other EL systems I have- like my HP integral PC- haven't
>> > succumbed to this.
>> >
>> > I have seen similar issues on amLCD displays in my Tadpole, Toshiba and
>> > other machines, so this is something we all may have to confront.
>> >
>> > ---
>> >
>> > I was wondering if the folks here had theories?
>> >
>> > I'm thinking moisture (or air) might be leaking in from the edges of the
>> > glass panes, perhaps from a compromised seal- sorry for the silly
>> picture
>> > but you can see the composition of the display here:
>> >
>> > https://www.instagram.com/p/6BXaLBtSzd/?taken-by=tr1nitr0n
>> >
>> > Does anyone know how one might prevent this from progressing- storage
>> tips?
>> >
>> > Could it be reversed?
>> >
>> > Better yet, does anyone have ideas on how to rapidly dehydrate the
>> display?
>> > Perhaps there is even a way to re-seal them.
>> >
>> > I think all two-glass-pane displays that don't have a vacuum may
>> eventually
>> > succumb to this.
>> >
>> > Perhaps it is just oxidation and not moisture, but I'd love to hear any
>> > theories.
>>
>>
>> Are you convinced this is a panel problem rather than a driver
>> electronics problem?
>>
>> In one picture it looks like the sort of thing that happens when you have
>> to turn up the brightness (for some types of display), resulting in partial
>> illumination in other areas of the screen.
>>
>> I've never had opportunity to repair or work on EL flat-panel displays,
>> I'm not familiar with the driving techniques and requirements, so this is
>> just a query/guess. (I see it's an X/Y matrix drive scheme, but the
>> voltages & timing & phasing I don't know about.)
>>
>>
>
> --
>Ian Finder
>(206) 395-MIPS
>ian.fin...@gmail.com
> 
>
>

-- 
   Ian Finder
   (206) 395-MIPS
   ian.fin...@gmail.com

The emulator that needs 3GHz

[Liam Proven]

*Accuracy takes power: one man’s 3GHz quest to build a perfect SNES
emulator*

*Emulators for playing older games are immensely popular online, with
regular arguments breaking out over which emulator is best for which game.
Today we present another point of view from a gentleman who has created the
Super Nintendo emulator **bsnes**. He wants to share his thoughts on the
most important part of the emulation experience: accuracy.*

http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/1/

-- 
Sent from my phone - please pardon brevity & typos.

memory map for RT-11 v 5

[william degnan]

Is there a minimum memory requirement for RT-11 v5?  I was discussing with
Ray Fantini about it today, unsure...anyone know if 16K will work (from
00).

Bill

-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio