Re: MINC is going to Pete Turnbull

[Camiel Vanderhoeven]

Op 20 mei 2016 8:12 a.m. schreef "tony duell" :
>
>
> Well, the Subject: line gives the result of by decision.  I have decided
(after
> much thought, it was not easy!) to give the surplus MINC to Pete. I wish
I had
> more spare MINCs so I could give each of you one.

Perfect. Thanks for letting us know.

Camiel.

Re: C standards and committees (was Re: strangest systems I've sent email from)

[Chuck Guzis]

Oh, foo--in 40 years, "C" will be just a quaint recollection in the
minds of the old-timers.  Like JOVIAL.

--Chuck

Re: strangest systems I've sent email from

[Sean Conner]

It was thus said that the Great William Donzelli once stated:
> >   First off, can you supply a list of architectures that are NOT 2's
> > complement integer math that are still made and in active use today?  As far
> > as I can tell, there was only one signed-magnitude architecture ever
> > commercially available (and that in the early 60s) and only a few 1's
> > complement architectures from the 60s (possibly up to the early 70s) that
> > *might* still be in active use.
> 
> There are probably a couple hundred Unisys 2200 systems left in the
> world (no one really knows the true number). Of course, when the C
> standards were being drawn up, there were many more, with a small but
> significant share of the mainframe market.

  Oh my!  I'm reading the manual for the C compiler for the Unisys 2200 [1]
system and it's dated 2013!  And yes, it does appear to be a 36-bit non-byte
addressable system.  

  Wow!

  I am finding chapter 14 ("Strategies for Writing Efficient Code") amusing
("don't use pointers!" "don't use loops!")  I suppose this is 1's complement
but I see nothing about that in the manual, nor do I see any system limits
(like INT_MAX, CHAR_MAX, etc).  

  -spc (Color me surprised!)

[1] https://public.support.unisys.com/2200/docs/cp15.0/pdf/78310430-016.pdf

Re: Passing of R. Tomlinson

[Chuck Guzis]

On 05/20/2016 09:54 PM, Adrian Stoness wrote:
> 100 yrs ago people gather around sign boards to get the latest and
> word would spread from that. News papers used to print several times
> a day in that time as well amazing how computers changed things that
> fast :)

Unfortunately, the larger volume of information seems not to have
improved the general mental condition.

Kind of like today's television--lots of channels, mostly not worth
watching.

--Chuck

Re: Passing of R. Tomlinson

[Adrian Stoness]

100 yrs ago people gather around sign boards to get the latest and word
would spread from that. News papers used to print several times a day in
that time as well amazing how computers changed things that fast :)
On May 20, 2016 8:12 PM, "Chuck Guzis"  wrote:

> On 05/20/2016 05:49 PM, Torfinn Ingolfsen wrote:
> > On Fri, May 20, 2016 at 2:41 AM, Eric Christopherson
> >  wrote:
> >> OH! He invented the at sign!
> >>
> >> ;)
> >
> > More or less funny names for the commercial at-sign: in Norwegian:
> > krøll-alfa ("curled alpha") in Swedish: kanelbulle ("cinnamon bun"?)
> > :-)
>
> Another very interesting term to file away with German "Gaensefuesschen"
> for quotation marks (usually the << and >> ones).
>
> "Little goose feet".
>
> --Chuck
>
>

Re: C standards and committees (was Re: strangest systems I've sent email from)

[Sean Conner]

It was thus said that the Great Mouse once stated:
> 
> > 3) It's slower.  Two reasons for this:
> 
> Even to the extent this is true, in most cases, "so what"?
> 
> Most executables are not performance-critical enough for dynamic-linker
> overhead to matter.  (For the few that are, or for the few cases where
> lots are, yes, static linking can help.)

  I keep telling myself that whenever I launch Firefox after a reboot ...

> > I use the uintXX_t types for interoperability---known file formats
> > and network protocols, and the plain (or known types like size_t)
> > otherwise.
> 
> uintXX_t does not help much with "known file formats and network
> protocols".  You have to either still serialize and deserialize
> manually - or blindly hope your compiler adds no padding bits (eg, that
> it lays out your structs exactly the way you hope it will).

  First off, the C standard mandates that the order of fields in a struct
cannot be reordered, so that just leaves padding and byte order to deal
with.  Now, it may sound cavalier of me, but of the three compilers I use at
work (gcc, clang, Solaris Sun Works thingy) I know how to get them to layout
the structs exactly as I need them (and it doesn't hurt that for the files
and protocols we deal with are generally properly aligned anyway for those
systems that can't deal with misaligned reads (generally everything *BUT*
the x86)) and that we keep everything in network byte order. [1]

  -spc 

[1] Sorry Rob Pike [2], but compilers aren't quite smart enough [3]
yet.

[2] https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html

[3] https://news.ycombinator.com/item?id=3796432

Re: strangest systems I've sent email from

[William Donzelli]

>   First off, can you supply a list of architectures that are NOT 2's
> complement integer math that are still made and in active use today?  As far
> as I can tell, there was only one signed-magnitude architecture ever
> commercially available (and that in the early 60s) and only a few 1's
> complement architectures from the 60s (possibly up to the early 70s) that
> *might* still be in active use.

There are probably a couple hundred Unisys 2200 systems left in the
world (no one really knows the true number). Of course, when the C
standards were being drawn up, there were many more, with a small but
significant share of the mainframe market.

--
Will (C sucks)

Re: strangest systems I've sent email from

[Sean Conner]

It was thus said that the Great Mouse once stated:
> >   -spc (Wish the C standard committee had the balls to say "2's
> >   complement all the way, and a physical bit pattern of all 0s is a
> >   NULL pointer" ... )
> 
> As far as I'm concerned, this is different only in degree from `Wish
> the C standard committee had the balls to say "Everything is x86".'.

  First off, can you supply a list of architectures that are NOT 2's
complement integer math that are still made and in active use today?  As far
as I can tell, there was only one signed-magnitude architecture ever
commercially available (and that in the early 60s) and only a few 1's
complement architectures from the 60s (possibly up to the early 70s) that
*might* still be in active use.

  Second, are there any architectures still commercially available and used
today where an all-zero bit pattern for an address *cannot* be used as NULL? 
Because it comes across as strange where:

char *p = (char *)0;

  is legal (that is, p will be assigned the NULL address for that platform
which may not be all-zero bits) whereas:

char *p;
memset(,0,sizeof(p));

isn't (p is not guarenteed to be a proper NULL pointer) [1].

  My wish covers yes, the x86, but also covers the 68k, MIPS, SPARC,
PowerPC and ARM.  Are there any others I missed?

  -spc (Also, the only portable exit codes are EXIT_SUCCESS and EXIT_FAILRE
[2][3])

[1] I know *why* this happens, but try to explain this to someone who
hasn't had *any* exposure to a non-byte, non-2's complement,
non-8-32-64bit system.

[2] From my understanding, it's DEC that mandated these instead of 0 and
1, because VMS used a different interpretation of exit codes than
everybody else ...

[3] I only bring this up because you seem to be assuming my position is
"all the world's on x86" when it's not (the world is "2's complement
byte oriented machines").  And because of this, I checked some of
your C code and I noticed you used 0 and 1 as exit codes, which,
pedantically speaking, isn't portable.

Yes, I'll admit this might be a low blow here ...

Re: C standards and committees (was Re: strangest systems I've sent email from)

[Mouse]

>   I'm generally not a fan of shared libraries as:

>   1) Unless you are linking against a library like libc or
>   libc++, a lot of memory will be wasted because the *entire*
>   library is loaded up, unlike linking to a static library where
>   only those functions actually used are linked into the final
>   executable

Yes and no.  (Caveat: the following discussion assumes a number of
things which are true in currently-common implementations; in cases
where they are false, the balance may well tip the other way.)

First, except for pages touched by dynamic linking (which should be
very few if the library was built properly), the library is shared
among all copies of it in use.  In a statically linked program, this is
true only across a single executable, with shared objects, it is true
across all executables linked with that library.

Second, even if the executable is the only one using the library, most
of it is demand-paged, occupying no physical memory unless/until it's
referenced.  (It still occupies virtual memory; if virtual memory is
tight - eg, you're doing gigabyte-sized datasets on a 32-bit machine -
then this can matter.)

>   2) because of 1, you have a huge surface area exposed that can
>   be exploited.

True.

Also, it exposes more attack surface in another way: it means there are
two files, not one, the modification of which can subvert the
application.  (The executable itself and the shared object.)  Add one
more for each additional shared object used.

>   3) It's slower.  Two reasons for this:

Even to the extent this is true, in most cases, "so what"?

Most executables are not performance-critical enough for dynamic-linker
overhead to matter.  (For the few that are, or for the few cases where
lots are, yes, static linking can help.)

> I use the uintXX_t types for interoperability---known file formats
> and network protocols, and the plain (or known types like size_t)
> otherwise.

uintXX_t does not help much with "known file formats and network
protocols".  You have to either still serialize and deserialize
manually - or blindly hope your compiler adds no padding bits (eg, that
it lays out your structs exactly the way you hope it will).

/~\ 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: strangest systems I've sent email from

[Mouse]

>   -spc (Wish the C standard committee had the balls to say "2's
>   complement all the way, and a physical bit pattern of all 0s is a
>   NULL pointer" ... )

As far as I'm concerned, this is different only in degree from `Wish
the C standard committee had the balls to say "Everything is x86".'.

> [3]   Often to disasterous results.  An agressive C optimizer can
>   optimize the following right out:

>   if (x + 1 < x ) { ... }

>   Because "x+1" can *never* be less than "x" (signed overflow?
>   What's that?)

More precisely, because signed overflow invokes undefined behaviour,
meaning that, for values of x where x+1 overflows, the program can
behave in any way whatever and still be within spec.  Including, say,
skipping the stuff inside the { } block.

/~\ 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: C standards and committees (was Re: strangest systems I've sent email from)

[Sean Conner]

It was thus said that the Great Swift Griggs once stated:
> On Fri, 20 May 2016, Sean Conner wrote:
> > By the late 80s, C was available on many different systems and was not 
> > yet standardized.
> 
> There were lots of standards, but folks typically gravitated toward K or 
> ANSI at the time. Though I was a pre-teen, I was a coder at the time.  
> Those are pretty raw and primitive compared to C99 or C11, but still quite 
> helpful, for me at least. Most of the other "standards" were pretty much a 
> velvet glove around vendor-based "standards", IMHO.

  In 1988, C had yet to be standardized.

  In 1989, ANSI released the first C standard, commonly called ANSI C or
C89.  

  I stared C programming in 1990, so I started out with ANSI C pretty much
from the start.  I found I prefer ANSI-C over K (pre-ANSI C), because the
compiler can catch more errors.

> > The standards committee was convened in an attempt to make sense of all 
> > the various C implementations and bring some form of sanity to the 
> > market.
> 
> I'm pretty negative on committees, in general. However, ISO and ANSI 
> standards have worked pretty well, so I suppose they aren't totally 
> useless _all_ the time.
> 
> Remember OSI networking protocols? They had a big nasty committee for all 
> their efforts, and we can see how that worked out. We got the "OSI model" 
> (which basically just apes other models already well established at the 
> time). That's about it (oh sure, a few other things like X.500 inspired 
> protocols but I think X.500 is garbage *shrug* YMMV). Things like TPx 
> protocols never caught on. Some would say it was because the world is so 
> unenlightened it couldn't recognize the genius of the commisar^H^H^H 
> committee's collective creations. I have a somewhat different viewpoint.

  The difference between the two?  ANSI codified existing examples where as
ISO created a standard in a vacuum and expected people to write
implementaitons to the standard.

> > All those "undefined" and "implementation" bits of C?  Yeah, competing 
> > implementations.
> 
> Hehe, what is a long long? Yes, you are totally right. Still, I assert 
> that C is still the defacto most portable language on Earth. What other 
> language runs on as many OS's and CPUs ? None that I can think of.

  A long long is at least 64-bits long.

  And Lua can run on as many OSs and CPUs as C.  

> > And because of the bizarre systems C can potentially run on, pointer 
> > arithmetic is ... odd as well [4].
> 
> Yeah, it's kind of an extension of the same issue, too many undefined grey 
> areas. In practice, I don't run into these types of issues much. However, 
> to be fair, I typically code on only about 3 different platforms, and they 
> are pretty similar and "modern" (BSD, Linux, IRIX).

  Just be thankful you never had to program C in the 80s and early 90s:

http://www.digitalmars.com/ctg/ctgMemoryModel.html

  Oh, wait a second ...


http://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models

> > It also doesn't help that bounds checking arrays is a manual process, 
> > but then again, it would be a manual process on most CPUs [5] anyway ...
> 
> I'm in the "please don't do squat for me that I don't ask for" camp. 

  What's wrong with the following code?

p = malloc(sizeof(somestruct) * count_of_items);

  Spot the bug yet?  

  Here's the answer:  it can overflow.  But that's okay, because sizeof()
returns an unsiged quantity, and count_of_items *should* be an unsigned
quantity (both size_t) and overflow on unsigned quantities *is* defined to
wrap (it's signed quantities that are undefined).  But that's *still* a
problem because if "sizeof(somestruvt) * count_of_items" exceeds the size of
a size_t, then the result is *smaller* than expected and you get a valid
pointer back, but to smaller pool of memory that expected.

  This may not be an issue on 64-bit systems (yet), but it can be on a
32-bit system.  Correct system code (in C99) would be:

if (count_of_items > (SIZE_MAX / sizeof(somestruct)))
  error();
p = malloc(sizeof(somestruct) * count_of_items);

  Oooh ... that reminds me ... I have some code to check ... 

> I know that horrifies and disgusts some folks who want GC and auto-bounds
> checking everywhere they can cram it in. Would SSA form aid with all kinds
> of fancy compiler optimizations, including some magic bounds checking? 
> Sure. However, perhaps because I'm typical of an ignorant C coder, I would
> expect the cost of any such feature would be unacceptable to some. 

  Don't discount GC though---it simplifies a lot of code


> Also,
> there are plenty of C variants or special compilers that can do such
> things. Also, there are a few things that can be run with LD_PRELOAD which
> can help to find issues where someone has forgot to do proper bounds
> checking. 

  I'm generally not a fan of shared libraries as:

1) Unless you are linking against a library 

Re: Passing of R. Tomlinson

[Chuck Guzis]

On 05/20/2016 05:49 PM, Torfinn Ingolfsen wrote:
> On Fri, May 20, 2016 at 2:41 AM, Eric Christopherson 
>  wrote:
>> OH! He invented the at sign!
>> 
>> ;)
> 
> More or less funny names for the commercial at-sign: in Norwegian:
> krøll-alfa ("curled alpha") in Swedish: kanelbulle ("cinnamon bun"?) 
> :-)

Another very interesting term to file away with German "Gaensefuesschen"
for quotation marks (usually the << and >> ones).

"Little goose feet".

--Chuck

Re: Passing of R. Tomlinson

[Mike Stein]

Not one of Kodi's better nights...
- Original Message - 
From: "Torfinn Ingolfsen" 
To: "General Discussion: On-Topic and Off-Topic Posts" 
Sent: Friday, May 20, 2016 8:49 PM
Subject: Re: Passing of R. Tomlinson


On Fri, May 20, 2016 at 2:41 AM, Eric Christopherson
 wrote:
> OH! He invented the at sign!
>
> ;)

More or less funny names for the commercial at-sign:
in Norwegian: krøll-alfa ("curled alpha")
in Swedish: kanelbulle ("cinnamon bun"?)
 :-)

-- 
Regards,
Torfinn

Re: Best LCDs for retrocomputing - Was: Re: New *square* 1:1 26.5" LCD monitor 1920x1920

[Ian Finder]

I will do some tests of the composite input this weekend with and without
TBC and see what I find.
I'll have to do a bit of digging for composite devices but I should have a
few.

On Fri, May 20, 2016 at 5:05 PM, Ian Finder  wrote:

> I mostly use the display for its fantastic handling and scaling of RGB
> formats via the VGA connector.
> I collect mostly old workstation class hardware and I care a lot about
> image quality.
>
> I'm not much of a microcomputer collector, and have used the composite
> input very, very sparingly.
>
> However, I have had enough issues in the past with the composite video
> "standard" on various non-analog CRT display devices that I keep a timebase
> corrector nearby and readily available. I find this a "must" for anyone
> relying on composite stuff in this day and age.
>
> I can try a IIgs- the only things I've tried over composite, I listed in
> the other post.
>
> Cheers,
>
> - Ian
>
> On Fri, May 20, 2016 at 3:16 PM, Adrian Graham <
> wit...@binarydinosaurs.co.uk> wrote:
>
>> On 16/05/2016 20:13, "Ian Finder"  wrote:
>>
>> > I dunno if it's relevant or not, but my go-to LCD for retro stuff is the
>> > Dell 2007FP-
>> > There was a panel lottery, some are TN, some IPS. Both are solid.
>> >
>> > They are 4:3, 1600x1200 native.
>> >
>> > They have DVI, VGA, Composite and S-Video inputs, and very stellar
>> scalers.
>> >
>> > They sync to SoG, and have no trouble with oddball resolutions like
>> > 1152x8-whatever.
>> >
>> > My SGI stuff can drive it at native resolution. As an added bonus, you
>> can
>> > disable scaling if you want black bars and native resolution.
>> >
>> > These are readily available for ~$35, and I have at least 6.
>>
>> Hi Ian (and list),
>>
>> Quick question, have you ever used a plain ol' composite input on yours?
>> Turns out my problem isn't just my problem, people have been having the
>> same
>> issue since the screens were new - composite input just doesn't work
>> unless
>> it's a very specific set of circumstances. That or there's a particular
>> setup required that isn't documented anywhere...
>>
>> So far I've tried:
>>
>> Spectrum (composite)
>> ZX81 (composite)
>> Raspberry Pi B
>> Apple ][GS
>> Amiga 1200
>> Amiga CD32 (this one *nearly* works, I get the splash screen)
>> Playstation 1 (ditto)
>> EACA VideoGenie
>>
>> Have you got any of those kicking around you could plug in and test for
>> me?
>>
>> Cheers,
>>
>> --
>> Adrian/Witchy
>> Binary Dinosaurs creator/curator
>> Www.binarydinosaurs.co.uk - the UK's biggest private home computer
>> collection?
>>
>>
>>
>
>
> --
>Ian Finder
>(206) 395-MIPS
>ian.fin...@gmail.com
>



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

Re: Best LCDs for retrocomputing - Was: Re: New *square* 1:1 26.5" LCD monitor 1920x1920

[Ian Finder]

I mostly use the display for its fantastic handling and scaling of RGB
formats via the VGA connector.
I collect mostly old workstation class hardware and I care a lot about
image quality.

I'm not much of a microcomputer collector, and have used the composite
input very, very sparingly.

However, I have had enough issues in the past with the composite video
"standard" on various non-analog CRT display devices that I keep a timebase
corrector nearby and readily available. I find this a "must" for anyone
relying on composite stuff in this day and age.

I can try a IIgs- the only things I've tried over composite, I listed in
the other post.

Cheers,

- Ian

On Fri, May 20, 2016 at 3:16 PM, Adrian Graham  wrote:

> On 16/05/2016 20:13, "Ian Finder"  wrote:
>
> > I dunno if it's relevant or not, but my go-to LCD for retro stuff is the
> > Dell 2007FP-
> > There was a panel lottery, some are TN, some IPS. Both are solid.
> >
> > They are 4:3, 1600x1200 native.
> >
> > They have DVI, VGA, Composite and S-Video inputs, and very stellar
> scalers.
> >
> > They sync to SoG, and have no trouble with oddball resolutions like
> > 1152x8-whatever.
> >
> > My SGI stuff can drive it at native resolution. As an added bonus, you
> can
> > disable scaling if you want black bars and native resolution.
> >
> > These are readily available for ~$35, and I have at least 6.
>
> Hi Ian (and list),
>
> Quick question, have you ever used a plain ol' composite input on yours?
> Turns out my problem isn't just my problem, people have been having the
> same
> issue since the screens were new - composite input just doesn't work unless
> it's a very specific set of circumstances. That or there's a particular
> setup required that isn't documented anywhere...
>
> So far I've tried:
>
> Spectrum (composite)
> ZX81 (composite)
> Raspberry Pi B
> Apple ][GS
> Amiga 1200
> Amiga CD32 (this one *nearly* works, I get the splash screen)
> Playstation 1 (ditto)
> EACA VideoGenie
>
> Have you got any of those kicking around you could plug in and test for me?
>
> Cheers,
>
> --
> Adrian/Witchy
> Binary Dinosaurs creator/curator
> Www.binarydinosaurs.co.uk - the UK's biggest private home computer
> collection?
>
>
>


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

C standards and committees (was Re: strangest systems I've sent email from)

[Swift Griggs]

On Fri, 20 May 2016, Sean Conner wrote:
> By the late 80s, C was available on many different systems and was not 
> yet standardized.

There were lots of standards, but folks typically gravitated toward K or 
ANSI at the time. Though I was a pre-teen, I was a coder at the time.  
Those are pretty raw and primitive compared to C99 or C11, but still quite 
helpful, for me at least. Most of the other "standards" were pretty much a 
velvet glove around vendor-based "standards", IMHO.

> The standards committee was convened in an attempt to make sense of all 
> the various C implementations and bring some form of sanity to the 
> market.

I'm pretty negative on committees, in general. However, ISO and ANSI 
standards have worked pretty well, so I suppose they aren't totally 
useless _all_ the time.

Remember OSI networking protocols? They had a big nasty committee for all 
their efforts, and we can see how that worked out. We got the "OSI model" 
(which basically just apes other models already well established at the 
time). That's about it (oh sure, a few other things like X.500 inspired 
protocols but I think X.500 is garbage *shrug* YMMV). Things like TPx 
protocols never caught on. Some would say it was because the world is so 
unenlightened it couldn't recognize the genius of the commisar^H^H^H 
committee's collective creations. I have a somewhat different viewpoint.

> All those "undefined" and "implementation" bits of C?  Yeah, competing 
> implementations.

Hehe, what is a long long? Yes, you are totally right. Still, I assert 
that C is still the defacto most portable language on Earth. What other 
language runs on as many OS's and CPUs ? None that I can think of.

> And because of the bizarre systems C can potentially run on, pointer 
> arithmetic is ... odd as well [4].

Yeah, it's kind of an extension of the same issue, too many undefined grey 
areas. In practice, I don't run into these types of issues much. However, 
to be fair, I typically code on only about 3 different platforms, and they 
are pretty similar and "modern" (BSD, Linux, IRIX).

> It also doesn't help that bounds checking arrays is a manual process, 
> but then again, it would be a manual process on most CPUs [5] anyway ...

I'm in the "please don't do squat for me that I don't ask for" camp. I 
know that horrifies and disgusts some folks who want GC and auto-bounds 
checking everywhere they can cram it in. Would SSA form aid with all kinds 
of fancy compiler optimizations, including some magic bounds checking? 
Sure. However, perhaps because I'm typical of an ignorant C coder, I would 
expect the cost of any such feature would be unacceptable to some. Also, 
there are plenty of C variants or special compilers that can do such 
things. Also, there are a few things that can be run with LD_PRELOAD which 
can help to find issues where someone has forgot to do proper bounds 
checking. Once people get on the "C sucks, put on some baby gates" bus, 
most of the actual working C coders get off at the next stop. Not judging, 
just observing. I've seen this over and over and over and ... 

>   -spc (Wish the C standard committee had the balls to say "2's complement
>   all the way, and a physical bit pattern of all 0s is a NULL pointer"
>   ... )

I'm right there with you on this one! 

> Because "x+1" can *never* be less than "x" (signed overflow?  What's 
> that?)

Hmm, well, people (me included in days gone by) tend to abuse signed 
scalars to simply get bigger integers. I really wish folks would embrace 
uintXX_t style ints ... problem solved, IMHO. It's right there for them in 
C99 to use.

> Except for, say, the Intel 432.  Automatic bounds checking on that one.

You can't always rely on the hardware, but perhaps that's your point.

> Trapping on signed overflow is still contentious today.  While some 
> systems can trap immediate on overflow (VAX, MIPS), the popular CPUs 
> today can't.

Hmmm, well I'm guessing most compilers on those platforms would support 
that (and hey, great!). 

> It's not to say they can't test for it, but that's the problem---they 
> have to test after each possible operation.

That's almost always the case when folks want rubber bumpers on C. That's 
really emblematic of my issues with that seemly instinctual reaction some 
folks have to C.

-Swift

Re: Best LCDs for retrocomputing - Was: Re: New *square* 1:1 26.5" LCD monitor 1920x1920

[Adrian Graham]

On 16/05/2016 20:13, "Ian Finder"  wrote:

> I dunno if it's relevant or not, but my go-to LCD for retro stuff is the
> Dell 2007FP-
> There was a panel lottery, some are TN, some IPS. Both are solid.
> 
> They are 4:3, 1600x1200 native.
> 
> They have DVI, VGA, Composite and S-Video inputs, and very stellar scalers.
> 
> They sync to SoG, and have no trouble with oddball resolutions like
> 1152x8-whatever.
> 
> My SGI stuff can drive it at native resolution. As an added bonus, you can
> disable scaling if you want black bars and native resolution.
> 
> These are readily available for ~$35, and I have at least 6.

Hi Ian (and list),

Quick question, have you ever used a plain ol' composite input on yours?
Turns out my problem isn't just my problem, people have been having the same
issue since the screens were new - composite input just doesn't work unless
it's a very specific set of circumstances. That or there's a particular
setup required that isn't documented anywhere...

So far I've tried:

Spectrum (composite)
ZX81 (composite)
Raspberry Pi B
Apple ][GS
Amiga 1200
Amiga CD32 (this one *nearly* works, I get the splash screen)
Playstation 1 (ditto)
EACA VideoGenie

Have you got any of those kicking around you could plug in and test for me?

Cheers,

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: strangest systems I've sent email from

[Sean Conner]

It was thus said that the Great Liam Proven once stated:
> On 29 April 2016 at 19:49, Mouse  wrote:
> > 
> > It's true that C is easy to use unsafely.  However, (a) it arose as an
> > OS implementation language, for which some level of unsafeness is
> > necessary, and (b) to paraphrase a famous remark about Unix, I suspect
> > it is not possible to eliminate the ability to do stupid things in C
> > without also eliminating the ability to do some clever things in C.
> 
> I think that the key thing is not to offer people alternatives that
> make it safer at the cost of removal of the clever stuff. It's to
> offer other clever stuff instead. C is famously unreadable, and yet
> most modern languages ape its syntax.

  By the late 80s, C was available on many different systems and was not yet
standardized.  The standards committee was convened in an attempt to make
sense of all the various C implementations and bring some form of sanity to
the market.  All those "undefined" and "implementation" bits of C?  Yeah,
competing implementations.

  For instance, why is signed integer arithmetic so underspecified?  So that
it could run on everything from a signed-magnitude machine [1] to a
pi-complement machine (with e-states per bit [2]).  Also, to give C
implementors a way to optimize code [3][6].

  And because of the bizarre systems C can potentially run on, pointer
arithmetic is ... odd as well [4].

  It also doesn't help that bounds checking arrays is a manual process, but
then again, it would be a manual process on most CPUs [5] anyway ... 

  -spc (Wish the C standard committee had the balls to say "2's complement
all the way, and a physical bit pattern of all 0s is a NULL pointer"
... )

[1] I think there was only one signed-magnitude CPU commercially
available, ever!  From the early 60s!  Seriously doubt C was ever
ported to that machine, but hey!  It could be!

[2] 2.71828 ... 

[3] Often to disasterous results.  An agressive C optimizer can optimize
the following right out:

if (x + 1 < x ) { ... }

Because "x+1" can *never* be less than "x" (signed overflow?  What's
that?)

[4] Say, a C compiler an 8088.  How big is a pointer?  How big of an
object can you point to?  How much code is involved with "p++"?

[5] Except for, say, the Intel 432.  Automatic bounds checking on that
one.  

[6] Trapping on signed overflow is still contentious today.  While some
systems can trap immediate on overflow (VAX, MIPS), the popular CPUs
today can't.  It's not to say they can't test for it, but that's the
problem---they have to test after each possible operation.  And not
all instructions that manipulate values affects the overflow bit
(it's not uncommon on the x86, for instance, to use an LEA
instruction (which does not affect flags) to multiple a value by
small constants (like 17 say) which is faster than a full multiple
and probably uses fewer registers and prevents clogging the
piplelines).

Re: Classics long overdue a Boot.

[Swift Griggs]

On Fri, 20 May 2016, David Brownlee wrote:
> Could be, though NeXTSTEP 3.x (for x>0) was definitely available on 
> Intel hardware - I remember helping support a bunch of Pentium 133 
> "workstations" at Dreamworks running custom software under NeXTSTEP 3.3. 

I know they do, too because I've run it myself. I have a copy of 3.3. See 
the directory tree below my sig. You just need to select your hardware 
*very* carefully.

> They also mainly had Micropolis disks ("For all your data loss needs").

Oh, s*** ya, those things were total garbage. I'm convinced they made them 
from recycled blender parts and rust to save on materials cost. I had a 
few throughout the years. It got to the point that if I found any in a 
machine, I'd just convince management to replace them before they took 
someone's data out of commission like a Takada airbag in a Jamaican Summer.

> This combined with NeXTSTEP's baroque install process and tendency to 
> occasionally crap out and destroy its own disk (I believe this was more 
> of an x86 only feature), meant production support spent a fair amount of 
> time reinstalling boxes.

I've experienced this. It's very easy to mess up as you say. Use a 
sacrificial lamb of a box with nothing you care about. I'd recommend 
against trying it with a virtual machine. It runs slower than a 
octogenarian with ankle weights in a VM for whatever reason (once you 
spend hours fiddling with it to get it working).

-Swift

Swift's NextStep 3.3 collection:

|-- 3.3_Boot_Disk.floppyimage
|-- NextSTEP\ 3.3\ CISC\ (Intel\ x86+Motorola\ 68k).iso
|-- drivers
|   |-- beta
|   |   |-- AMDPCnet32.pkg.compressed
|   |   |-- ATIRageDisplay.pkg.compressed
|   |   |-- Adaptec1542BSCSI.pkg.compressed
|   |   |-- Adaptec2940SCSI.pkg.compressed
|   |   |-- BusLogicFPSCSI.pkg.compressed
|   |   |-- DECChip21040net.pkg.compressed
|   |   |-- DECChip21140Net.pkg.compressed
|   |   |-- DECChip21142Net.pkg.compressed
|   |   |-- DECChip21x4xNet.pkg.compressed
|   |   |-- DiamondStealth.pkg.compressed
|   |   |-- EIDE.pkg.compressed
|   |   |-- EISABus.pkg.compressed
|   |   |-- ES1x88Audio.pkg.compressed
|   |   |-- EtherExpress16.pkg.compressed
|   |   |-- EtherLink3.pkg.compressed
|   |   |-- EtherLinkXL.pkg.compressed
|   |   |-- HPXU_Display.pkg.compressed
|   |   |-- IBMTokenRing.pkg.compressed
|   |   |-- Intel82365PCIC.pkg.compressed
|   |   |-- Intel82557Net.pkg.compressed
|   |   |-- Intel82595Net.pkg.compressed
|   |   |-- MatroxMGA2064W.pkg.compressed
|   |   |-- Num9Imagine128s2.pkg.compressed
|   |   |-- Number9Motion331.pkg.compressed
|   |   |-- PCMCIABus.pkg.compressed
|   |   |-- S3GenericDisplay.pkg.compressed
|   |   |-- S3ViRGEDisplay.pkg.compressed
|   |   |-- SCSITape.pkg.compressed
|   |   |-- SoundBlaster16.pkg.compressed
|   |   |-- ThinkPad760CD.pkg.compressed
|   |   |-- ThinkPad760ED.pkg.compressed
|   |   |-- TridentGeneric.pkg.compressed
|   |   |-- WD90C24Display.pkg.compressed
|   |   |-- XircomIIps.pkg.compressed
|   |   |-- XircomNewave.pkg.compressed
|   |   `-- YamahaOPLAudio.pkg.compressed
|   `-- released
|   |-- AIC6X60SCSI.pkg.compressed
|   |-- AMDPCnet32.pkg.compressed
|   |-- AMD_PC_SCSI.pkg.compressed
|   |-- ATIMach32.pkg.compressed
|   |-- ATI_Mach64.pkg.compressed
|   |-- Adaptec2740SCSI.pkg.compressed
|   |-- Adaptec2940SCSI,pkg.compressed
|   |-- BusLogicSCSI.pkg.compressed
|   |-- CL_GD5434.pkg.compressed
|   |-- CT_Wingine_64300.pkg.compressed
|   |-- Compaq_QVision.pkg.compressed
|   |-- DECChip21040.pkg.compressed
|   |-- DECChip21140.pkg.compressed
|   |-- DPTSCSI.pkg.compressed
|   |-- DiamondStealth.pkg.compressed
|   |-- EIDE.pkg.compressed
|   |-- EISABus.pkg.compressed
|   |-- ESS1x88Audio.pkg.compressed
|   |-- FTGISALightPen.pkg.compressed
|   |-- FTGSerLightPen.pkg.compressed
|   |-- IBMTokenRing.pkg.compressed
|   |-- ISA_Serial_Port.pkg.compressed
|   |-- Intel82365PC.pkg.compressed
|   |-- Intel824x0.pkg.compressed
|   |-- Intel82556.pkg.compressed
|   |-- Intel82557Net.pkg.compressed
|   |-- Intel82595Net.pkg.compressed
|   |-- Intel82596Net.pkg.compressed
|   |-- Matrox_MGA_Mill.pkg.compressed
|   |-- MedVisionJazz16.pkg.compressed
|   |-- Num9GXE64Pro.pkg.compressed
|   |-- Num9Motion771.pkg.compressed
|   |-- Num9_Imagine128.pkg.compressed
|   |-- PCMCIABus.pkg.compressed
|   |-- PS2Mouse.pkg.compressed
|   |-- Pegasus_Display.pkg.compressed
|   |-- PortServer.pkg.compressed
|   |-- S3_Generic.pkg.compressed
|   |-- SMC16.pkg.compressed
|   |-- SMCUltra.pkg.compressed
|   |-- SYM53c8.pkg.compressed
|   |-- SerialPointer.pkg.compressed
|   |-- SoundBlaster16.pkg.compressed
|   |-- ThinkPad755CX.pkg.compressed
|   |-- WeitekPower9100.pkg.compressed
|   |-- XircomNetwave.pkg.compressed
|   `-- XircomPerf.pkg.compressed
|-- floppies
|   |-- 3.2_Addl_Drivers.floppyimage

Test software on machines customers actually use - was Re: strangest systems I've sent email from

[Toby Thain]

On 2016-05-20 3:03 PM, Fred Cisin wrote:

I don't know if that was a specific market ploy based on Moore's Law,


an actually quite smart move, . . .


or just the generally accepted practice of getting an initial version
with the API working any which way, then refactoring to improve
performance/correctness in later versions.


For decades, I used to rant that the biggest problem with Microsoft
software was that they treated their programmers "too well".

That if Microsoft programmer had space problems, they would immediately
replace his machine with one with more RAM and bigger drive, and he
wouldn't learn to be memory or disk space efficient.

That if his programs were too slow, that they would immediately replace
his machine with a faster one, and he would never learn to write fast or
efficient code.


This is still a huge problem that afflicts web development as much as it 
did desktop development.


Devs should have down-specced machines (say, 5+ years old) or at the 
very least, should be regularly testing on them.


--Toby



If there was ever a hardware problem, they would immediately replace the
machine.  Accordingly, Microsoft programmers NEVER actually experienced
hardware issues, and had to IMAGINE what disk errors, etc. would be
like, resulting in software that couldn't properly handle them when they
happened. ...

OK, so development should be targeted for next generation hardware.
BUT, testing should be done with what is actually out in the real world.

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

Hamvention

[Alex McWhirter]

Anyone spot anything list related at hamvention? I'm around trying to find 
anything cool. Particularly sun and ibm stuff.

Sent from my T-Mobile 4G LTE Device

Re: Classics long overdue a Boot.

[ethan]

Damn, Ethan, you have had more SGI's than I have. That's freakin' saying
something, and you don't seem to mind the big ones, either. Then again,
all you British folks live in large country estates, right? :-)


Bought my first Indigo from Reputable Systems. I then started to go to the 
auctions at NASA Langley Research Center. From there I'd pick up odds and 
ends, and from time to time trade some hardware for others and such. I'd 
sell the stuff I didn't want that was bundled into the lots (you had to 
buy whole lots.) Eventually I ended up working in the supercomputing 
facility at NASA as an IRIX admin/Solaris admin/Linux admin. When SGI shut 
their Hampton Va office down I ended up with some of the excess. Because 
it was given to me, I never sold any of it I paid it forward and gave it 
away to others. As my personal stuff aged I ended up giving some of it 
away as well, mainly Indys and such.



"Blokehappy Hollow" etc.. However, despite the name, they frequently don't
have 220v L630 twist lock whips, 3-phase power, or anything else that
makes life as a Big-SGI collector easy. :-P


I used to plug the Onyx into a normal outlet, I just had it lightly 
loaded? I have tons of pics of stuff from them days, I just need to sort 
it all.


The way I ended up at NASA is someone I knew from the BBS scene who also 
messed around in the DOS virus scene (loong story) came to visit and he 
saw the stacks of SGI Indys in the dining room running ISP functions and 
was like, "EWWW YOU LIKE THIS SHIT?" I said yea, he said give me your 
resume then. Boom, NASA contractor. He was pro linux anti SGI/Sun. Heh.



My favorite is actually the Tezro. I love the crossbar architecture, and
it's basically (same procs same RAM etc..) a mini Origin 3k supercomputer.
It's just a brusin' bad-dude of a graphics workstation. Stick a dmedia rig
on there and it's graphics/video heaven (even HD). The machine feels much
faster than 4x1Ghz. Even browsers run fast. To me, this is the "high art"
intersection of electrical engineering, Unix, and design-friendly
philosophy. I just need to get mine to 16GB of RAM and I'll be in
hog-heaven (a very loud fan-blown heaven, but still). I've got my Tezro
all beefed up with SSD drives too (acard 3.5" converters used and work
very nicely). Yesterday I put it on my living room coffee table to cheer
me up when I come home from work (I have no kids, dog, life, hehe). Is
that a bit much ?

The Octane is also a really wonderful platform for many of the same
reasons as the Tezro. I don't currently own one, but I've got room for one
more SGI, and I think it'll be either a Fuel or an Octane2. I just need to
find one with skins in good condition and a decent CPU. It'll probably be
an Octane2 because the Fuel reminds me too much of a PeeCee. It's like
when Sun came out with UltraSPARCs and started in with cheapened PeeCee
sparcstations (my opinion from looking at the guts of those machines and
comparing with older machines such as the venerable SS10). Still, the
Fuels are fast and take commodity hardware very easily.


Tezros look killer! I think an Origin 350 would be my other SGI.


PS: I'm never selling my SGIs unless something exceedingly horrible
happens. I've even got them in my will. I want them to go to people I
trust. etc... Nutty? Probably. Such is my life.


I think I know someone that wants to be buried in his. I'm not sure if 
it's strange humor or not?



--
Ethan O'Toole

Re: strangest systems I've sent email from

[Austin Pass]

On 20 May 2016, at 20:03, Fred Cisin  wrote:

>> I don't know if that was a specific market ploy based on Moore's Law,
> 
> an actually quite smart move, . . .
> 
>> or just the generally accepted practice of getting an initial version
>> with the API working any which way, then refactoring to improve
>> performance/correctness in later versions.
> 
> For decades, I used to rant that the biggest problem with Microsoft software 
> was that they treated their programmers "too well".
> 
> That if Microsoft programmer had space problems, they would immediately 
> replace his machine with one with more RAM and bigger drive, and he wouldn't 
> learn to be memory or disk space efficient.
> 
> That if his programs were too slow, that they would immediately replace his 
> machine with a faster one, and he would never learn to write fast or 
> efficient code.
> 
> If there was ever a hardware problem, they would immediately replace the 
> machine.  Accordingly, Microsoft programmers NEVER actually experienced 
> hardware issues, and had to IMAGINE what disk errors, etc. would be like, 
> resulting in software that couldn't properly handle them when they happened.  
> For exaample, when SMARTDRV was causing MANY problems with write-caching 
> (TOTAL failure and data loss if even a minor disk error occurs), Microsoft 
> was in denial, and couldn't understand that their software needed to be able 
> to recover, or at least sanely handle the situation when an error occurred.
> They did not CARE ("well, that's a hardware problem, not out problem.") that 
> a single bad sector (unfound by SPINRITE) in the disk space occupied by the 
> WINGBATS font, totally prevented installation of Windoze 3.10.
> [cf. "disk compression problems" due to SMARTDRV, and their need to replace 
> DOS6.00 with 6.20]
> 
> 
> I used to rant that if Microsoft were to "trade machines with us", and give 
> their programmers current or old, rather than newest, machines, that their 
> programmers might finally learn how to write robust compact fast software.

The rumour was that Bill Gates insisted programmers used 386's when writing 
Windows '95, although I'm struggling to find a single shred of evidence 
supporting this statement, so it may be mis-remembered fantasy.

-Austin.

Re: Classics long overdue a Boot.

[Sean Caron]

On Thu, 19 May 2016, Jerry Kemp wrote:


+1

Been looking for a Crimson for about 8 years now.

A couple have come up, but none anywhere close to me.  Due to size and weight 
shipping has been prohibitive.


:(


Jerry


On 05/19/16 06:25 PM, Ian Finder wrote:

You parted a Crimson into wall hangings just because the PSU blew? They're
super easy to work on.

Sometimes this list makes me {m,s}ad.





Hey, it is what it is ... I must have been 16 and my boss at the shop had 
an engineering background ... no stranger to board-level repair. He wasn't 
too keen to dive in and attempt to troubleshoot a multi-kW switcher and I 
honestly don't know too many guys that are. We had no idea if the boards 
may have been damaged in the PSU failure so even if we did put the time 
and effort into the PSU and did successfully manage to repair, there was 
no guarantee that we'd end up with a working machine.


It was a bit big to haul to just be a doorstop ... I didn't see any real 
chance of getting a replacement PSU or repair in the immediate future. I 
just decided to save what I could ... the most interesting bits, and the 
rest, well, you can't save it all.


As I say, it was a very basic machine, no RealityEngine. Really all that 
was in there was the CPU board and an IO3B. LG1 graphics right out of an 
Indigo, with a little VME interposer board. Friends and family generally 
consider me a packrat, but I guess even I have my limits ;)


Best,

Sean

Re: strangest systems I've sent email from

[Fred Cisin]

I don't know if that was a specific market ploy based on Moore's Law,


an actually quite smart move, . . .


or just the generally accepted practice of getting an initial version
with the API working any which way, then refactoring to improve
performance/correctness in later versions.


For decades, I used to rant that the biggest problem with Microsoft 
software was that they treated their programmers "too well".


That if Microsoft programmer had space problems, they would immediately 
replace his machine with one with more RAM and bigger drive, and he 
wouldn't learn to be memory or disk space efficient.


That if his programs were too slow, that they would immediately replace 
his machine with a faster one, and he would never learn to write fast or 
efficient code.


If there was ever a hardware problem, they would immediately replace the 
machine.  Accordingly, Microsoft programmers NEVER actually experienced 
hardware issues, and had to IMAGINE what disk errors, etc. would be like, 
resulting in software that couldn't properly handle them when they 
happened.  For exaample, when SMARTDRV was causing MANY problems with 
write-caching (TOTAL failure and data loss if even a minor disk error 
occurs), Microsoft was in denial, and couldn't understand that their 
software needed to be able to recover, or at least sanely handle the 
situation when an error occurred.
They did not CARE ("well, that's a hardware problem, not out problem.") 
that a single bad sector (unfound by SPINRITE) in the disk space occupied 
by the WINGBATS font, totally prevented installation of Windoze 3.10.
[cf. "disk compression problems" due to SMARTDRV, and their need to 
replace DOS6.00 with 6.20]



I used to rant that if Microsoft were to "trade machines with us", and 
give their programmers current or old, rather than newest, machines, that 
their programmers might finally learn how to write robust compact fast 
software.



OK, so development should be targeted for next generation hardware.
BUT, testing should be done with what is actually out in the real world.

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

Re: Commodore C2N datasette belts (was Re: Classics long overdue a Boot.)

[Ethan Dicks]

On Fri, May 20, 2016 at 1:11 PM, Adrian Graham
 wrote:
> On 20/05/2016 17:18, "Ethan Dicks"  wrote:
>> Do you have the dimensions on that belt handy?  All of my Commodore
>> tape drives are erratic due to aged belts.
>
> These are the ones I bought, 80mm diameter:
>
> http://www.ebay.co.uk/itm/301304228049

Perfect.  Thanks!  I didn't want to trust the exact sizes on my
stretched and flabby belts.

So 80mm dia/251mm length, 1.2mm across, square belt.

What's odd is I'm finding plenty of UK sellers and essentially no
sellers based in the States.  How strange.

Thanks!

-ethan

Re: Classics long overdue a Boot.

[Austin Pass]

> On 20 May 2016, at 19:04, David Brownlee  wrote:
> 
> They also mainly had Micropolis disks ("For all your data loss
> needs").

Drink duly spat over exterior of SPARCclassic laughing at this!

I remember wondering who the $¥€%#<^* had brought a cement mixer into the 
workshop c. 1996, only to realise the noise was coming from the Micropolis 
5.25" HDD in our Novell Netware 3.12 server.  Nasty, nasty things. We renamed 
them Necropolis due to their propensity toward the data afterlife.

-Austin.

NEXTSTEP/OPENSTEP history - was Re: Classics long overdue a Boot.

[Toby Thain]

On 2016-05-20 2:04 PM, David Brownlee wrote:

On 20 May 2016 at 15:50, Toby Thain  wrote:

On 2016-05-20 3:39 AM, Adrian Graham wrote:


On 19/05/2016 23:10, "Sean Caron"  wrote:
...
My NeXT slab also hadn't been powered up for 10 years so I checked that
one
and all was ok, only it wasn't my slab! I picked up a load of NeXT gear
from
an ex-employee many years ago including a colour turbo, cube, slab and
Elonex SCSI PC running the x86 version of NeXTSTEP (NeXTSTART by then?).
At


OPENSTEP?



Could be, though NeXTSTEP 3.x (for x>0) was definitely available on
Intel hardware - I remember helping support a bunch of Pentium 133


Sure. I just hadn't heard of NeXTSTART.

--Toby


"workstations" at Dreamworks running custom software under NeXTSTEP
3.3. They also mainly had Micropolis disks ("For all your data loss
needs").

This combined with NeXTSTEP's baroque install process and tendency to
occasionally crap out and destroy its own disk (I believe this was
more of an x86 only feature), meant production support spent a fair
amount of time reinstalling boxes.

The solution was BSD boot floppy which asked for their pager id, then
downloaded and blatted a compressed NeXTSTEP disk image onto the local
disk, emailed their pager and then rebooted into a nearly complete
NeXTSTEP system, so they could walk away and be pinged to come back to
finish off the config some time later.

Re: Classics long overdue a Boot.

[David Brownlee]

On 20 May 2016 at 15:50, Toby Thain  wrote:
> On 2016-05-20 3:39 AM, Adrian Graham wrote:
>>
>> On 19/05/2016 23:10, "Sean Caron"  wrote:
>> ...
>> My NeXT slab also hadn't been powered up for 10 years so I checked that
>> one
>> and all was ok, only it wasn't my slab! I picked up a load of NeXT gear
>> from
>> an ex-employee many years ago including a colour turbo, cube, slab and
>> Elonex SCSI PC running the x86 version of NeXTSTEP (NeXTSTART by then?).
>> At
>
> OPENSTEP?
>

Could be, though NeXTSTEP 3.x (for x>0) was definitely available on
Intel hardware - I remember helping support a bunch of Pentium 133
"workstations" at Dreamworks running custom software under NeXTSTEP
3.3. They also mainly had Micropolis disks ("For all your data loss
needs").

This combined with NeXTSTEP's baroque install process and tendency to
occasionally crap out and destroy its own disk (I believe this was
more of an x86 only feature), meant production support spent a fair
amount of time reinstalling boxes.

The solution was BSD boot floppy which asked for their pager id, then
downloaded and blatted a compressed NeXTSTEP disk image onto the local
disk, emailed their pager and then rebooted into a nearly complete
NeXTSTEP system, so they could walk away and be pinged to come back to
finish off the config some time later.

Re: strangest systems I've sent email from

[David Brownlee]

On 20 May 2016 at 17:24, Liam Proven  wrote:
>
> On 18 May 2016 at 21:40, Fred Cisin  wrote:
> > But, "Moore's Law" held that it wouldn't be much longer.
> > Just one doubling of the speed of the Lisa's hardware would have been enough
> > to silence the speed complaints.
>
> A general point, really.
>
> One of Microsoft's strokes of brilliance was selectively exploiting
> this. I think maybe it learned it from the 80286 OS/2 1.x débacle.
>
> NT 3.1 was brilliant if a bit bulky and unoptimised. Fair enough, it
> was a v1.0 OS. It was way way WAY too heavy for the average 1993 PC,
> but power users played, partly 'cos it fixed serious problems with
> Windows 3.1.
>
> [[make it work, ship version, then make it fast, then ship new version]]

I don't know if that was a specific market ploy based on Moore's Law,
or just the generally accepted practice of getting an initial version
with the API working any which way, then refactoring to improve
performance/correctness in later versions.

I seem to recall a comment that when select() was introduced in BSD4.2
it was implemented by an in kernel loop of polling each filedescriptor
so they could ship something with the API they wanted, and then in 4.3
the implementation was refactored to... how should we say... be much
more performant :)

Re: Commodore C2N datasette belts (was Re: Classics long overdue a Boot.)

[Austin Pass]

Sent from my iPhone
> On 20 May 2016, at 18:11, Adrian Graham  wrote:
> 
>> On 20/05/2016 17:18, "Ethan Dicks"  wrote:
>> 
>> On Thu, May 19, 2016 at 7:11 PM, Adrian Graham
>>  wrote:
>>> Last ones?! EVAR?!1one. Horrors. Don't tell Modern-Radio-Bolton otherwise
>>> the belts I bought recently for my Commodore C2N/1530s etc might evaporate
>>> in a puff of logic
>> 
>> Do you have the dimensions on that belt handy?  All of my Commodore
>> tape drives are erratic due to aged belts.  I can't get good reads and
>> I have some PET Rabbit-format tapes to read (long ago, I digitized my
>> standard CBM tapes).
>> 
>> I'll likely order from this side of the pond, but I just need to know
>> what size(s) work(s).
> 
> These are the ones I bought, 80mm diameter:
> 
> http://www.ebay.co.uk/itm/301304228049
> 
> Perfect fit for both the 1530 and black C2N and I'm sure there are different
> sizes available for floppy drives, I'll soon be breaking out my Spectrum +3
> 128K and I can be almost certain that the new belt I fitted in 2001 has gone
> south in the intervening years.
> 
> -- 
> Adrian/Witchy
> Binary Dinosaurs creator/curator
> Www.binarydinosaurs.co.uk - the UK's biggest private home computer
> collection?
> 
> 

I bought CPC's entire remaining stock of Amstrad/Hitachi 3" drive belts in 2007.

Assuming they aren't goo I can happily post you some?

-Austin.

Re: Commodore C2N datasette belts (was Re: Classics long overdue a Boot.)

[Adrian Graham]

On 20/05/2016 17:18, "Ethan Dicks"  wrote:

> On Thu, May 19, 2016 at 7:11 PM, Adrian Graham
>  wrote:
>> Last ones?! EVAR?!1one. Horrors. Don't tell Modern-Radio-Bolton otherwise
>> the belts I bought recently for my Commodore C2N/1530s etc might evaporate
>> in a puff of logic
> 
> Do you have the dimensions on that belt handy?  All of my Commodore
> tape drives are erratic due to aged belts.  I can't get good reads and
> I have some PET Rabbit-format tapes to read (long ago, I digitized my
> standard CBM tapes).
> 
> I'll likely order from this side of the pond, but I just need to know
> what size(s) work(s).

These are the ones I bought, 80mm diameter:

http://www.ebay.co.uk/itm/301304228049

Perfect fit for both the 1530 and black C2N and I'm sure there are different
sizes available for floppy drives, I'll soon be breaking out my Spectrum +3
128K and I can be almost certain that the new belt I fitted in 2001 has gone
south in the intervening years.

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: strangest systems I've sent email from

[Liam Proven]

On 18 May 2016 at 21:40, Fred Cisin  wrote:
> But, "Moore's Law" held that it wouldn't be much longer.
> Just one doubling of the speed of the Lisa's hardware would have been enough
> to silence the speed complaints.


A general point, really.

One of Microsoft's strokes of brilliance was selectively exploiting
this. I think maybe it learned it from the 80286 OS/2 1.x débacle.

NT 3.1 was brilliant if a bit bulky and unoptimised. Fair enough, it
was a v1.0 OS. It was way way WAY too heavy for the average 1993 PC,
but power users played, partly 'cos it fixed serious problems with
Windows 3.1.

(You could run a Win3.1 16-bit app in its own memory space & thus
slightly get round Win3.1's terrible low resource limitations. Source:
my customers did it, and paid GBP 5K for a PC to run it on for that
reason.)

NT 3.5 fixed some of that and now the PC was £3.5K or so.

NT 3.51 was pretty good and now the PC was £2.5-£2K -- in other words,
accessible to a high-end power user. The Win3 UI kept the proles away
-- they wanted the friendlier Win95.

NT 4 brought the UI, and now, a plain vanilla high-end PC could run it.

The cycle sort of repeated with XP and Vista -- they were aimed a bit
above the vanilla cheapo turn-of-the-century PC and its successor. The
market caught up as they matured.

Selectively aiming a bit ahead of where the ordinary PC was allowed MS
to refine the OSes in public, so they were ready for prime-time by the
time that the market had caught up.

IBM, OTOH, aimed at the thousands of boxes /it had already sold/ and
so totally torpedoed its own product.


-- 
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)

Commodore C2N datasette belts (was Re: Classics long overdue a Boot.)

[Ethan Dicks]

On Thu, May 19, 2016 at 7:11 PM, Adrian Graham
 wrote:
> Last ones?! EVAR?!1one. Horrors. Don't tell Modern-Radio-Bolton otherwise
> the belts I bought recently for my Commodore C2N/1530s etc might evaporate
> in a puff of logic

Do you have the dimensions on that belt handy?  All of my Commodore
tape drives are erratic due to aged belts.  I can't get good reads and
I have some PET Rabbit-format tapes to read (long ago, I digitized my
standard CBM tapes).

I'll likely order from this side of the pond, but I just need to know
what size(s) work(s).

-ethan

Re: strangest systems I've sent email from

[Liam Proven]

On 29 April 2016 at 19:49, Mouse  wrote:
>>> True, but again, *you shouldn't have to*. It means programmer
>>> effort, brain power, is being wasted on thinking about being safe
>>> instead of spent on writing better programs.
>
> True, but...
>
>> One side effect of this is that it makes a lot of C programmers
>> pedants.
>
> ...this is also true, and it means the development of a mindset that's
> better equipped to catch higher-level mistakes as well as the low-level
> mistakes.

My points are:

* not everyone is _able_ to develop that mindset.
* some (many) that cannot, think that they can.
* humans are fallible.
* modern codebases are _vast_ and hugely complex -- to big for any
individual to absorb & comprehend.

> It's true that C is easy to use unsafely.  However, (a) it arose as an
> OS implementation language, for which some level of unsafeness is
> necessary, and (b) to paraphrase a famous remark about Unix, I suspect
> it is not possible to eliminate the ability to do stupid things in C
> without also eliminating the ability to do some clever things in C.

I think that the key thing is not to offer people alternatives that
make it safer at the cost of removal of the clever stuff. It's to
offer other clever stuff instead. C is famously unreadable, and yet
most modern languages ape its syntax.

> Of course, the question is not whether C has flaws.  The question is
> why it's still being used despite those flaws.  The answer, I suspect,
> is what someone said about it being good enough.

"Worse is better."

>> My value system doesn't jive with smart phones.
>
> I would have no problem with them if they were documented.  But I've
> yet to find one that is.  I worked on a project writing code for a new
> Android phone, once, and even as developers we had to use binary blob
> drivers for important pieces.  (It also taught me how horrible the
> Android build system is.)
>
> Mind you, if/when I find one that _is_ documented

There _are_ FOSS offerings. The Jolla Sailfish devices, for instance.

-- 
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: Classics long overdue a Boot.

[Swift Griggs]

On Fri, 20 May 2016, John Willis wrote:
> I had an opportunity to get four Origin 3000s and two Cray J-90s in the 
> 2008-9 timeframe. Could never arrange for transportation though, so they 
> got away.

That wasn't by chance at NOAA or NREL, was it? One of those DoE sub-org 
folks had a similar rig IIRC, for a while. Exxon had six O3k's or 
something like that for a while.

-Swift

Re: Classics long overdue a Boot.

[Swift Griggs]

On Fri, 20 May 2016, et...@757.org wrote:
> FWIW, everyone loves the Crimson. I like the Challenge L and Onyx 
> deskside better.

They love them because they are Awesome. :-)

> I know that one of my old Onyx's is in New Mexico, not sure where the 
> others are these days.

People love them. I just wish folks would take better care of the skins.

> I gave away *four* Challenge Ls. Not sure if the one guy still uses them 
> as a table end or not.

Damn, Ethan, you have had more SGI's than I have. That's freakin' saying 
something, and you don't seem to mind the big ones, either. Then again, 
all you British folks live in large country estates, right? :-) 

In the USA, we just name apartment complexes like we wish it was medieval 
times in rural Britain. Ie.. "Willowmanor Estates", "Manorwood Manor", 
"Blokehappy Hollow" etc.. However, despite the name, they frequently don't 
have 220v L630 twist lock whips, 3-phase power, or anything else that 
makes life as a Big-SGI collector easy. :-P 

My favorite is actually the Tezro. I love the crossbar architecture, and 
it's basically (same procs same RAM etc..) a mini Origin 3k supercomputer. 
It's just a brusin' bad-dude of a graphics workstation. Stick a dmedia rig 
on there and it's graphics/video heaven (even HD). The machine feels much 
faster than 4x1Ghz. Even browsers run fast. To me, this is the "high art" 
intersection of electrical engineering, Unix, and design-friendly 
philosophy. I just need to get mine to 16GB of RAM and I'll be in 
hog-heaven (a very loud fan-blown heaven, but still). I've got my Tezro 
all beefed up with SSD drives too (acard 3.5" converters used and work 
very nicely). Yesterday I put it on my living room coffee table to cheer 
me up when I come home from work (I have no kids, dog, life, hehe). Is 
that a bit much ?

The Octane is also a really wonderful platform for many of the same 
reasons as the Tezro. I don't currently own one, but I've got room for one 
more SGI, and I think it'll be either a Fuel or an Octane2. I just need to 
find one with skins in good condition and a decent CPU. It'll probably be 
an Octane2 because the Fuel reminds me too much of a PeeCee. It's like 
when Sun came out with UltraSPARCs and started in with cheapened PeeCee 
sparcstations (my opinion from looking at the guts of those machines and 
comparing with older machines such as the venerable SS10). Still, the 
Fuels are fast and take commodity hardware very easily.

-Swift

PS: I'm never selling my SGIs unless something exceedingly horrible 
happens. I've even got them in my will. I want them to go to people I 
trust. etc... Nutty? Probably. Such is my life. 

PPS: You guys got me all paranoid with your battery horror stories. I 
stayed up late last night powering on Indys. Whew! Everything is working, 
including my Sega 32X! 

Re: Classics long overdue a Boot.

[John Willis]

>
> I've owned 3 Crimsons and 3 or 4 Onyx desksides. I wonder where they are
> now? I know one Crimson buyer drove to Virginia Beach from Atlanta GA.
>
> FWIW, everyone loves the Crimson. I like the Challenge L and Onyx deskside
> better.
>
> I know that one of my old Onyx's is in New Mexico, not sure where the
> others are these days.
>
> I gave away *four* Challenge Ls. Not sure if the one guy still uses them
> as a table end or not.
>
>
I had an opportunity to get four Origin 3000s and two Cray J-90s in the
2008-9 timeframe.
Could never arrange for transportation though, so they got away.

Re: Classics long overdue a Boot.

[ethan]

+1
Been looking for a Crimson for about 8 years now.
A couple have come up, but none anywhere close to me.  Due to size and weight 
shipping has been prohibitive.

:(
Jerry


I've owned 3 Crimsons and 3 or 4 Onyx desksides. I wonder where they are 
now? I know one Crimson buyer drove to Virginia Beach from Atlanta GA.


FWIW, everyone loves the Crimson. I like the Challenge L and Onyx deskside 
better.


I know that one of my old Onyx's is in New Mexico, not sure where the 
others are these days.


I gave away *four* Challenge Ls. Not sure if the one guy still uses them 
as a table end or not.

Re: Classics long overdue a Boot.

[Adrian Graham]

On 20 May 2016 at 15:50, Toby Thain  wrote:

> On 2016-05-20 3:39 AM, Adrian Graham wrote:
>
>> On 19/05/2016 23:10, "Sean Caron"  wrote:
>> ...
>> My NeXT slab also hadn't been powered up for 10 years so I checked that
>> one
>> and all was ok, only it wasn't my slab! I picked up a load of NeXT gear
>> from
>> an ex-employee many years ago including a colour turbo, cube, slab and
>> Elonex SCSI PC running the x86 version of NeXTSTEP (NeXTSTART by then?).
>> At
>>
>
> OPENSTEP?
>

That's the kiddie. It's on a DEC RZ25. Unfortunately said drive's rubber
mounts turned to goo and infiltrated the PSU, we discovered this in the
bloke's flat when he turned the machine on and it promptly went pop. I
powered the machine up using a normal PSU (the Elonex one is a proprietary)
but I need a boot floppy which I don't have.


> some point I must've accidentally swapped the slabs...
>>
>>
> I'm not sure I understand the shell game here. If you swapped them, what
> happened to yours?


All the kit I picked up with some exceptions was destined for TNMOC at
Bletchley Park. I guess my slab ended up there. Doesn't matter anyway
because I replaced the drive in mine before installing NeXTSTEP 3.3.

-- 
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk

Re: Classics long overdue a Boot.

[Toby Thain]

On 2016-05-20 3:39 AM, Adrian Graham wrote:

On 19/05/2016 23:10, "Sean Caron"  wrote:
...
My NeXT slab also hadn't been powered up for 10 years so I checked that one
and all was ok, only it wasn't my slab! I picked up a load of NeXT gear from
an ex-employee many years ago including a colour turbo, cube, slab and
Elonex SCSI PC running the x86 version of NeXTSTEP (NeXTSTART by then?). At


OPENSTEP?


some point I must've accidentally swapped the slabs...



I'm not sure I understand the shell game here. If you swapped them, what 
happened to yours?


--Toby

MSI 6800

[Brad H]

Hi there,
I have acquired an MSI 6800 (SS50) computer and am trying to figure out how to 
get it going.  I am reaching out everywhere hoping to find someone with 
knowledge of these as I have searched around extensively and cannot find a 
manual.
With a null modem cable connected to a PC I can get a response from the 
computer by typing things or resetting it, but the output is garbled.  I know 
the baud rate but at present have no way to determine the other settings like 
bit, parity, etc.
Any help/advice would be appreciated!
Brad
Sent from my Samsung device

Re: RSTS/E

[Paul Koning]

> On May 20, 2016, at 2:47 AM, Rod Smallwood  
> wrote:
> 
> ...
> 1. The system is going into an exhibit. There will be an assortment of DEC 
> terminals attached
> 
> 2. The guy who is going to look after it has years of RSTS user knowledge.
> 
> 3, There are several systems available all 11/83.  All with RD54
> 
> 4. They are working and boot RSX .
> 
> 5.   I cant remember how to remember how to prepare a bootable RSTS install 
> tape (I last did the course in 1983)

Install tapes for V9 or later are weird constructs; they are partly DOS and 
partly ANSI format.  I don't remember the messy details.

> 6. I do have a copy of RSTS V9 and I know the version supports TK50.  Its a 
> .tap image

If you have a TAP image of a good installation tape, the best answer is to copy 
that to the physical tape, because then it will definitely work.  Trying to 
construct one out of pieces isn't as easy.

> 7.  So its a case move the image over to my VAX  from my PC. My network can 
> do that.
> 
> 8.  Then make the tape boot and install RSTS
> 
> 9 . How do I do that?

If you have a way to make TK50 tapes from TAP images, then I'd suggest this:

1. Make a TK50 install tape from a TAP image of a known good install tape.  
Remember that installation tapes have to be write locked when you boot them to 
be recognized as an install tape.

2. Do just the first steps of the install, just what's needed to copy the 
sysgen environment to the disk.

3. Do a full backup of your SIMH setup to tape (TAP image), with the Backup 
command.  That will create a simple tape, nothing nearly as strange as a kit 
tape.  Then copy that image to another TK50.

4. Put the backup TK50 into your 11/83 system and do a full restore.

5. Reboot and use the INSTALL command in Init to select the regular system SIL 
that you copied in step 4.  Proceed with startup; you should now be all set.

paul

Re: RSTS/E

[Jerome H. Fine]

>Rod Smallwood wrote:>


On 20/05/2016 05:19, Jerome H. Fine wrote:


>Rod Smallwood wrote:

I'm not overly worried about it being on TK50 other than knowing 
that was one of the distribution mediums.
So a quick rephrase of the question. I have an 11/83 system with an 
RX50 and an RD54. How do I install RSTS on  it?



Why do you want to use the PDP-11/83?  Do you want
to run RSTS/E or just exercise the PDP-11/83 hardware?

If your answer is running RSTS/E, there is much more
convenient hardware than a PDP-11/83.

If you want to exercise the PDP-11/83, the solution I
understand is to use a hammer when you only have a nail.

If you don't know how to prepare a TK50 tape that self boots
and then does a restore of RSTS/E, then you might resort to
using RT-11.  Backup each RT-11 partition under either
SimH or Ersatz-11.  The restore using the RX50 drive and
copy each RT-11 partition to the RD54 from the TK50 file
images.

Of course, you need to be able to write to a TK50 tape
under SimH or Ersatz-11.  You also have to take care
of block 65535 for each RT-11 partition since I don't
know if RT-11 will backup it up.  If you need some help
with this, I will try and figure it out as long as you test
to determine if you can write to a TK50 tape in the first
place.

Jerome Fine




Hi Jerome
Thanks for the answer.

1. The system is going into an exhibit. There will be an assortment of 
DEC terminals attached


2. The guy who is going to look after it has years of RSTS user 
knowledge.


3, There are several systems available all 11/83.  All with RD54

4. They are working and boot RSX .

5.   I cant remember how to remember how to prepare a bootable RSTS 
install tape (I last did the course in 1983)


6. I do have a copy of RSTS V9 and I know the version supports TK50.  
Its a .tap image


7.  So its a case move the image over to my VAX  from my PC. My 
network can do that.


8.  Then make the tape boot and install RSTS

9 . How do I do that?


As I mentioned, the ONLY advice that I can offer is what to
do with an image file on a system that supports SimH and / or
Ersatz-11.  AFTER RSTS/E is installed on such a system
within an image file that is the same size as an RD54, then
assuming you can copy file images to physical TK50 media
on that same system, I can probably figure out how to do it
under RT-11, i.e. how to copy each RT-11 partition of the
RD54 (actually the image file the size of an RD54) with the
installed RSTS/E files to TK50 images although in the past
I have never used TK50s under Ersatz-11, just under a real
DEC PDP-11/83 (actually TK70s, but the software is the
same).

Are you that far at this point?

Maybe if you can find someone who knows how to produce
a bootable TK50 media would be easier.  One thing that I
would be concerned over is that a TK50, if I remember
correctly, can't hold much more than 50 MB, so if the image
file of the RD54 holds more than that many files, you will
need more than one TK50 media of data.

If you go the RT-11 method, each TK50 will need to hold
32 MB at most, so there will not be a problem.

Jerome Fine

Re: Beam-penetration color CRT, Tektronix DAS 912x (was Re: Nice LAB11 brochure.)

[Pete Lancashire]

Actually the CRT was built for Tek. but since is was a custom it can
be though of as a Tek CRT. I'm not sure about the monitory assembly,
sometime this year I maybe able to get the full specs on the CRT if
anyone is interested.

-pete Ex Tekkie

On Thu, May 19, 2016 at 11:18 PM, Eric Smith  wrote:
> On May 8, 2016 9:33 PM, "Eric Smith"  wrote
> about the CRT of the color monitor of some models of the Tektronix
> DAS 9100 logic analyzer:
>> It is custom, and it is tri-color (red, green, yellow), but it's a
>> beam penetration CRT that is not a modified version of any normal
>> color CRT. There is no shadow mask, and it can only draw one color per
>> field, like the 1951 CBS field-sequential color television, though
>> that was done with a color wheel while this is done by modulating the
>> anode voltage (and possibly the deflection drive as well).
>
> On Mon, May 9, 2016 at 7:45 AM, Pete Lancashire  
> wrote:
>> I must be thinking of a different  model.
>
> Now that I've looked at volume 1 of the DAS 9100 service manual, I
> believe my information was incorrect. Volume 1 is scant on details of
> the color monitor, but it does say that the anode voltage is 21kV. If
> it was a beam-penetration CRT, it would have to be switched between
> different voltages for red and green.  (And yellow, if that was
> generated with its own phosphor layer rather than as two passes with
> red and green.)
>
> The color monitor is manufactured by Tektronix using a CRT also
> manufactured by Tektronix. The monochrome version uses a monitor OEM'd
> from Motorola.
>

MINC is going to Pete Turnbull

[tony duell]

Well, the Subject: line gives the result of by decision.  I have decided (after
much thought, it was not easy!) to give the surplus MINC to Pete. I wish I had
more spare MINCs so I could give each of you one.

Perhaps the only consolation is that there may well be other machines up for
grabs as I continue to sort out.

Pete, we need to agree a time for collection.

Thanks to everyone who responded. 

-tony

Re: Classics long overdue a Boot.

[Adrian Graham]

On 19/05/2016 23:10, "Sean Caron"  wrote:

> On Thu, 19 May 2016, Chris Hanson wrote:
> 
>> I haven't booted my Lisa 2/10 in a very long time, not since before a
>> cross-country move.
>> 
>> I'm a little worried about it. Last time I looked (a couple years ago) it
>> didn't look like any caps had gone though. And at least it doesn't have an
>> internal battery to worry about.
>> 
>> It definitely needs a floppy drive recalibration though, if not repair. Now
>> that MacFloppyEmu exists (and I have one) I may just not worry about it, and
>> run a cable out to use with that instead, so I can install the latest Office
>> System as well as install Workshop.
>> 
>> I also need to pull out and boot my NeXT mono slab.
>> 
>>  -- Chris
>> 
> 
> Be sure to check the battery! I saw a Lisa on EEVblog that met a horrible
> end. Rotted out more thoroughly than any Amiga I've ever seen with battery
> issues.
> 
> It reminds me, I should probably pull my Dad's Lisa 2 out of storage next
> time I visit and give it a good looking over.
> 
> I have found NeXT machines to age pretty well. If they don't fire right up
> just give the battery a change.

I had a panic about my Lisa 2/5 after unearthing one of my Amiga 2000s and
discovering the battery damage. Fortunately because I'd had it stored on its
side (it fits in a Mac Plus box) the damage was limited to the immediate
area around the battery and it was very fixable.

That in turn made me attempt to power up my 2/10 but it's never been powered
up even though I've had it for over 10 years so I wasn't surprised when I
hit the button and got nothing. Fortunately I know someone who's well versed
on the PSUs of these things.

My NeXT slab also hadn't been powered up for 10 years so I checked that one
and all was ok, only it wasn't my slab! I picked up a load of NeXT gear from
an ex-employee many years ago including a colour turbo, cube, slab and
Elonex SCSI PC running the x86 version of NeXTSTEP (NeXTSTART by then?). At
some point I must've accidentally swapped the slabs...

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Classics long overdue a Boot.

[Adrian Graham]

On 19/05/2016 23:21, "Austin Pass"  wrote:

> I'm surprised I have relatively little of it now (just the A3000 and a very
> clean Model B). I'd like a RISC PC but supply is thin on the ground here
> nowadays, it appears the boat has sailed.

They're still around - I got 2 RPCs and an Iyonix the other month from the
local freecycle group. If you're anywhere near Stratford-on-Avon in July I'm
doing an exhibition there so the Iyonix will be on display.

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: RSTS/E

[Rod Smallwood]

On 20/05/2016 05:19, Jerome H. Fine wrote:

>Rod Smallwood wrote:

I'm not overly worried about it being on TK50 other than knowing that 
was one of the distribution mediums.
So a quick rephrase of the question. I have an 11/83 system with an 
RX50 and an RD54. How do I install RSTS on  it?


Why do you want to use the PDP-11/83?  Do you want
to run RSTS/E or just exercise the PDP-11/83 hardware?

If your answer is running RSTS/E, there is much more
convenient hardware than a PDP-11/83.

If you want to exercise the PDP-11/83, the solution I
understand is to use a hammer when you only have a nail.

If you don't know how to prepare a TK50 tape that self boots
and then does a restore of RSTS/E, then you might resort to
using RT-11.  Backup each RT-11 partition under either
SimH or Ersatz-11.  The restore using the RX50 drive and
copy each RT-11 partition to the RD54 from the TK50 file
images.

Of course, you need to be able to write to a TK50 tape
under SimH or Ersatz-11.  You also have to take care
of block 65535 for each RT-11 partition since I don't
know if RT-11 will backup it up.  If you need some help
with this, I will try and figure it out as long as you test
to determine if you can write to a TK50 tape in the first
place.

Jerome Fine



Hi Jerome
Thanks for the answer.

1. The system is going into an exhibit. There will be an assortment of 
DEC terminals attached


2. The guy who is going to look after it has years of RSTS user knowledge.

3, There are several systems available all 11/83.  All with RD54

4. They are working and boot RSX .

5.   I cant remember how to remember how to prepare a bootable RSTS 
install tape (I last did the course in 1983)


6. I do have a copy of RSTS V9 and I know the version supports TK50.  
Its a .tap image


7.  So its a case move the image over to my VAX  from my PC. My network 
can do that.


8.  Then make the tape boot and install RSTS

9 . How do I do that?

Rod

Re: Pascal/8002 or other compilers for Tek 8002 dev. system?

[Eric Smith]

On Tue, May 10, 2016 at 11:47 PM, Eric Smith  wrote:
> the Tektronix DAS 9100 logic analyzer is Z80 based, and
> contains many ROMs, mostly 8KB MK36000 series masked ROMs and MCM68764
> EPROMs, but only one ROM appears to contain much actual Z80 code. That
> 8K ROM is labeled "INTERP" and contains a bytecode interpreter.
> Apparently all the other ROMs are full of bytecode.  The bytecode does
> not match the UCSD p-code nor the ETHZ P4 p-code. I've started
> disassembling it, but haven't yet learned too much.

Volume 1 of the service manual confirms that most of the software in
the DAS 9100 is written in Pascal and interpreted. Since the p-code
doesn't match UCSD or ETHZ, I still suspect that it was compiled using
the Pascal/8002 compiler from Pascal Development Co., but I'm not
optimistic about finding a copy of that compiler or even the
documentation for it.

I enjoyed doing a little bit of reverse-engineering of the bytecode
interpreter, but I don't think I'll pursue it any further.

Re: Beam-penetration color CRT, Tektronix DAS 912x (was Re: Nice LAB11 brochure.)

[Eric Smith]

On May 8, 2016 9:33 PM, "Eric Smith"  wrote
about the CRT of the color monitor of some models of the Tektronix
DAS 9100 logic analyzer:
> It is custom, and it is tri-color (red, green, yellow), but it's a
> beam penetration CRT that is not a modified version of any normal
> color CRT. There is no shadow mask, and it can only draw one color per
> field, like the 1951 CBS field-sequential color television, though
> that was done with a color wheel while this is done by modulating the
> anode voltage (and possibly the deflection drive as well).

On Mon, May 9, 2016 at 7:45 AM, Pete Lancashire  wrote:
> I must be thinking of a different  model.

Now that I've looked at volume 1 of the DAS 9100 service manual, I
believe my information was incorrect. Volume 1 is scant on details of
the color monitor, but it does say that the anode voltage is 21kV. If
it was a beam-penetration CRT, it would have to be switched between
different voltages for red and green.  (And yellow, if that was
generated with its own phosphor layer rather than as two passes with
red and green.)

The color monitor is manufactured by Tektronix using a CRT also
manufactured by Tektronix. The monochrome version uses a monitor OEM'd
from Motorola.