OT? Upper limits of FSB

[Jeffrey S. Worley via cctalk]

Apropos of nothing, I've been confuse for some time regarding maximum
clock rates for local bus.

My admittedly old information, which comes from the 3rd ed. of "High
Performance Computer Architecture", a course I audited, indicates a
maximum speed on the order of 1ghz for very very short trace lengths.

Late model computers boast multi-hundred to multi gigahertz fsb's.  Am
I wrong in thinking this is an aggregate of several serial lines
running at 1 to 200mhz?  No straight answer has presented on searches
online.

So here's the question.  Is maximum fsb on standard, non-optical bus
still limited to a maximum of a couple of hundred megahertz, or did
something happen in the last decade or two that changed things
dramatically?  I understand, at least think I do, that these
ridiculously high frequency claims would not survive capacitance issues
and RFI issues. When my brother claimed a 3.2ghz bus speed for his
machine I just told him that was wrong, impossible for practical
purposes, that it had to be an aggregate figure, a 'Pentium rating'
sort of number rather than the actual clock speed.  I envision
switching bus tech akin to present networking, paralleled to sidestep
the limit while keeping pin and trace counts low.?  Something like
the PCIe 'lane' scheme in present use?  This is surmise based on my own
experience.

When I was current, the way out of this limitation was fiber-optics for
the bus.  This was used in supercomputing and allowed interconnects of
longer length at ridiculous speeds.

Thanks for allowing me to entertain this question.  Though it is not
specifically a classic computer question, it does relate to development
and history.



Best,

Technoid Mutant (Jeff Worley)

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

> On Jan 4, 2019, at 5:15 PM, Paul Koning  wrote:
> 
> So the likely answer is that either your INIT.BAC program, or your BASIC.RTS, 
> is damaged ...
> Can you read the RK05 from the machinery you used to fill it originally?  It 
> might make sense simply to read parts of it, or all of it, and verify the 
> contents are correct.

Okay, I’ve managed to pull back an image of the RSTS pack I’ve been trying to 
boot, with PDP11GUI.  A quick look with od and diff shows many differences 
between the two, but that’s not totally surprising I guess since the image on 
the real hardware was reconfigured with ODT, and its swap, error log, and crash 
files may be different?  I’ll have to dig a little deeper there to sort the 
wheat from the chaff.

But what *is* surprising is that the pulled back image boots and runs just fine 
under SIMH! Hmm...

I guess I’ll go ahead and finish up my standalone sector CRC hack and run it 
both on the real hardware and on the just retrieved image with no changes on 
either end and make sure those are really identical.

If that’s the case, it will come down to what’s different between my machine 
and SIMH.  Maybe I’ve got some flaky memory on my machine?  I can push harder 
on diagnostics on the MS11 and see if I can find anything fishy I guess.  
Lurking bug in the RK11 maybe?  All the CPU, FPU, KT11, KW11, and RK11 MAINDECS 
are passing just fine.  Puzzler...

--FritzM.
 

Re: ELTRAN THE COMPILER ANY DOCS? (NOT THE SEMICONDUCTOR STUFF!)))

[Chuck Guzis via cctalk]

On 1/4/19 8:42 PM, Fred Cisin via cctalk wrote:
> Would be  interesting when you find it.
> Not necessarily "tiny"
> Remember WATFOR?   (very impressive!)

I guesss not too many numerical methods types hwere, but ELTRAN is a
subroutine in the EISPACK linear programming set.  Yes, it's all FORTRAN:

>From the subroutine:

c
c this subroutine is a translation of the algol procedure elmtrans,
c num. math. 16, 181-204(1970) by peters and wilkinson.
c handbook for auto. comp., vol.ii-linear algebra, 372-395(1971).
c
c this subroutine accumulates the stabilized elementary
c similarity transformations used in the reduction of a
c real general matrix to upper hessenberg form by  elmhes.

--Chuck

Re: ELTRAN THE COMPILER ANY DOCS? (NOT THE SEMICONDUCTOR STUFF!)))

[Fred Cisin via cctalk]

Would be  interesting when you find it.
Not necessarily "tiny"
Remember WATFOR?   (very impressive!)


I had a lot of fun with PDQ FORTRAN on 1620.


. . . and, my reply was meant in jest.  You are nothing like the fellow 
who told us about  Valtrep.  (other than the sparcity of Google hits)


--
Grumpy Ol' Fred ci...@xenosoft.com

On Sat, 5 Jan 2019, ED SHARPE wrote:



have no idea but do have a feeling it might have been like a 'tiny fortran'

Sent from AOL Mobile Mail
On Friday, January 4, 2019 Fred Cisin  wrote:
On Sat, 5 Jan 2019, ED SHARPE via cctalk wrote:

ELTRAN THE COMPILER
ANY DOCS? ANY ONE?? USED IT?
(NOT THE SEMICONDUCTOR STUFF!))


Was?? it?? one?? of the?? ones based?? on Valtrep?


http://www.classiccmp.org/pipermail/cctalk/2017-March/033410.html


--
Grumpy Ol' Fred?? ?? ?? ?? ci...@xenosoft.com

Re: ELTRAN THE COMPILER ANY DOCS? (NOT THE SEMICONDUCTOR STUFF!)))

[ED SHARPE via cctalk]

have no idea but do have a feeling it might have been like a 'tiny fortran'

Sent from AOL Mobile Mail
On Friday, January 4, 2019 Fred Cisin  wrote:
On Sat, 5 Jan 2019, ED SHARPE via cctalk wrote:
> ELTRAN THE COMPILER
> ANY DOCS? ANY ONE  USED IT?
> (NOT THE SEMICONDUCTOR STUFF!))

Was  it  one  of the  ones based  on Valtrep?


http://www.classiccmp.org/pipermail/cctalk/2017-March/033410.html


--
Grumpy Ol' Fred            ci...@xenosoft.com

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

> On Jan 4, 2019, at 5:15 PM, Paul Koning  wrote:
> 
> So the likely answer is that either your INIT.BAC program, or your BASIC.RTS, 
> is damaged ...
> Can you read the RK05 from the machinery you used to fill it originally?  It 
> might make sense simply to read parts of it, or all of it, and verify the 
> contents are correct.

Oh, interesting!

Yeah, I can read the pack back with PDP11GUI (another couple hours, ugh, but 
we’ll see what we see.)

I’m thinking it would be handy to have a bit of standalone code that would just 
read through a pack and dump CRC-16 for each sector out the console for 
purposes like this.  Then I could just blast over single sectors that don’t 
match.  Maybe I’ll work on coding up that bit of MACRO while the longer 
complete dump is running…

   cheers,
 --FritzM.

Re: ELTRAN THE COMPILER ANY DOCS? (NOT THE SEMICONDUCTOR STUFF!)))

[Fred Cisin via cctalk]

On Sat, 5 Jan 2019, ED SHARPE via cctalk wrote:

ELTRAN THE COMPILER
ANY DOCS? ANY ONE  USED IT?
(NOT THE SEMICONDUCTOR STUFF!))


Was  it  one  of the   ones based  on Valtrep?


http://www.classiccmp.org/pipermail/cctalk/2017-March/033410.html


--
Grumpy Ol' Fred ci...@xenosoft.com

ELTRAN THE COMPILER ANY DOCS? (NOT THE SEMICONDUCTOR STUFF!)))

[ED SHARPE via cctalk]

ELTRAN THE COMPILER 
ANY DOCS? ANY ONE  USED IT?
(NOT THE SEMICONDUCTOR STUFF!))

ED#

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Jan 4, 2019, at 6:21 PM, Fritz Mueller  wrote:
> 
> 
>> On Jan 4, 2019, at 6:51 AM, Paul Koning  wrote:
>> 
>> Plan B: set a breakpoint at "ERL" (040672 in your map) which is the entry 
>> point to the error logging code.  That's where the display register is 
>> incremented as part of logging an error.  On entry, R0 is the EMT code (a 
>> LOG$xx code, because these are EMTs in kernel mode).  Many of those codes 
>> are fixed and defined in KERNEL.MAC which is in the kit.  The ones that are 
>> configuration-dependent are in the RSTS.MAP listing, for example LOG$KB.  
>> The log code would tell us which device or component is unhappy.
> 
> Okay:
> 
>  BE125652
>  _040672;B
>  _P
>  0B:040672
>  _$0;$7L
>  $0 /00 000400 001764 00 00 00 001730 040672
> 
>  _$S/004340
>  _777400;777412L
>  177400 /004713 00 000344 00 014000 001260

Well, this is VERY interesting.

The error code is LOG$CK, which is "run time system reported error".  There are 
a couple of possibilities.  That code is logged from within the kernel if a 
pseudo-vector (pointer to code in the runtime system) is invalid.  It is also 
generated if the runtime system issues a .ERLOG EMT.  BASIC does so if the .BAC 
file it wants to run has a bad checksum.

So the likely answer is that either your INIT.BAC program, or your BASIC.RTS, 
is damaged.  If you can rename INIT.BAC to something else, you can then try to 
start and you'd expect to see startup messages like this:

...You currently have crash dump enabled.

04-Jan-99? 
08:09 PM? 
?Can't find file or account
?Program lost-Sorry

Ready

If so, then reload INIT.BAC.  Or if you have the source (INIT.BAS) just say 
"old init" and "compile".

If you still get a loop, then I'd suspect [0,1]BASIC.RTS.

Can you read the RK05 from the machinery you used to fill it originally?  It 
might make sense simply to read parts of it, or all of it, and verify the 
contents are correct.

paul

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

> On Jan 4, 2019, at 6:51 AM, Paul Koning  wrote:
> 
> Plan B: set a breakpoint at "ERL" (040672 in your map) which is the entry 
> point to the error logging code.  That's where the display register is 
> incremented as part of logging an error.  On entry, R0 is the EMT code (a 
> LOG$xx code, because these are EMTs in kernel mode).  Many of those codes are 
> fixed and defined in KERNEL.MAC which is in the kit.  The ones that are 
> configuration-dependent are in the RSTS.MAP listing, for example LOG$KB.  The 
> log code would tell us which device or component is unhappy.

Okay:

  BE125652
  _040672;B
  _P
  0B:040672
  _$0;$7L
  $0 /00 000400 001764 00 00 00 001730 040672

  _$S/004340
  _777400;777412L
  177400 /004713 00 000344 00 014000 001260

Re: Microcode, which is a no-go for modern designs

[Eric Smith via cctalk]

On Fri, Jan 4, 2019 at 8:08 AM dwight via cctalk 
wrote:

> May ability to understand these papers is somewhat limited. If I
> understand correctly the following.
> Most divide routines that I've seen allow the remainder to be 1,0,-1
> relative to the normal remainder. The answer will converge as the error of
> the remainder never leaves this range.
> In the case of the pentium, the remainder is 2,1,0,-1,-2. This allows the
> division to converge on the answer quicker. The error was that if the
> remainder was right on one edge it would eventually fall of the edge and
> not converge. From the paper, that would be the 5 1's in a row, of the
> divisor.
>

My interpretation is that with the five table entries with the wrong
values, it always converges, but for some input values it converges to the
wrong answer. I could be wrong, though.

In any case, I'm sure there were a lot of people at Intel that were unhappy
that they couldn't patch this with a microcode fix or workaround. Although
Intel relented and offered to replace ALL affected Pentiums, apparently a
substantial number of the buggy ones were never sent in.

Re: Microcode, which is a no-go for modern designs

[dwight via cctalk]

May ability to understand these papers is somewhat limited. If I understand 
correctly the following.
Most divide routines that I've seen allow the remainder to be 1,0,-1 relative 
to the normal remainder. The answer will converge as the error of the remainder 
never leaves this range.
In the case of the pentium, the remainder is 2,1,0,-1,-2. This allows the 
division to converge on the answer quicker. The error was that if the remainder 
was right on one edge it would eventually fall of the edge and not converge. 
From the paper, that would be the 5 1's in a row, of the divisor.
At least that is my understanding. It is to early in the morning for me.
Dwight


From: Eric Smith 
Sent: Thursday, January 3, 2019 11:55 PM
To: dwight; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Microcode, which is a no-go for modern designs

And the original analysis paper, "It Takes Six Ones to Reach a Flaw":
http://www.acsel-lab.com/arithmetic/arith12/papers/ARITH12_Coe.pdf

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Jan 3, 2019, at 10:08 PM, Fritz Mueller via cctalk  
> wrote:
> 
> 
>> On Jan 3, 2019, at 5:17 PM, Paul Koning  wrote:
>> 
>> So in this example, 55230 is the error logging entry point for the RK11 
>> driver. ... If you have a breakpoint at this location, you'll be able to 
>> capture the controller CSR contents which -- I hope -- will explain why the 
>> system is not happy.
>> 
>> The way to set the breakpoint is simply to enter control/P for ODT, then 
>> 55230;B to set the breakpoint, then P to proceed.
> 
> Thanks, Paul!  Tried but no luck:
> 
> ...
> 
> (...system starts looping error behavior; type ^P...)
> 
>BE125652
>_55230/004537
>_55230;B
>_P
> 
> (...system resumes looping error behavior without hitting breakpoint; sadness)
> 
> Any additional or different recommended breakpoints to try?  Or did I miss 
> setting this up (I’m new to ODT.)
> 
>   thanks much,
> --FritzM.

The ODT command syntax is correct.  I confirmed by setting a breakpoint at 
DSQ$DK, the "queue a disk request" driver entry point, and that breaks 
correctly -- just to make sure my memory hasn't faded.

Plan B: set a breakpoint at "ERL" (040672 in your map) which is the entry point 
to the error logging code.  That's where the display register is incremented as 
part of logging an error.  On entry, R0 is the EMT code (a LOG$xx code, because 
these are EMTs in kernel mode).  Many of those codes are fixed and defined in 
KERNEL.MAC which is in the kit.  The ones that are configuration-dependent are 
in the RSTS.MAP listing, for example LOG$KB.  The log code would tell us which 
device or component is unhappy.

paul

Re: music dec tapes? (paper)

[allison via cctalk]

On 01/03/2019 11:15 PM, Kyle Owen wrote:
> On Thu, Jan 3, 2019, 17:48 allison   wrote:
>
>> I don't think this album has been forgotten; I have a copy, and I
>> know others with copies, too. It seems as though "Unplayed by
>> Human Hands" (both versions) are less well-known. I would like to
>> work on getting the original software archived, assuming it's
>> still out there, as it ran on a Straight-8.
>>
> ITs also on line.
>
>
> The recordings, or the software? If you're referring to the latter,
> please send a link! I know someone has a GitHub repository, but it's
> missing any and all PDP-8 files. 
>
> Kyle
>
Recording as in record album on Vinyl. 

HP music [was: music dec tapes? (paper)]

[Christian Corti via cctalk]

On Thu, 3 Jan 2019, Bill Degnan wrote:

I have tapes with labels

[...]

"Start 8 Music"  (hand-written, no printed label)


Speaking of PDP-8 music: there was also a music program for the HP 21xx 
computers. There are only absolute binary papertape images available. Does 
someone happen to have the source listing or program documentation for 
that? This music program plays on a MW radio just like the PDP-8 MUSIC 
program, but it plays only two notes a time. It runs well on our 2116B and 
2100S.


Christian