[cctalk] Re: Thirties techies and computing history

2024-05-20 Thread Kevin Jordan via cctalk
Virtual museums as well, e.g.:

http://www.nostalgiccomputing.org


On Mon, May 20, 2024 at 1:28 PM Christian Liendo via cctalk <
cctalk@classiccmp.org> wrote:

> I see computer history slowly growing. Before you had only one museum
> in the United States and now you have multiple ones such as but not
> limited to:
>
> American Computer Museum
> Computer History Museum
> Computer Museum of America
> Large Scale Systems Museum
> Rhode Island Computer Museum
> System Source Computer Museum
>
> 10 years ago I didn't see any computing history taught in a
> university. Now I see it being taught at NJIT.
>
>
> https://news.njit.edu/new-computer-science-elective-examines-history-computing
>
> There are people whose hard work is keeping computer history alive.
>


[cctalk] Re: Random items on Pascal #3

2024-05-16 Thread Kevin Jordan via cctalk
Regarding NOS/VE and the notion that its command language was horribly
awkward ... the command language was strongly influenced by Multics and
some thinking in the Computer Science world about user-friendliness in
command languages being linked to predictability. Commands in NOS/VE's SCL
(System Command Language) were verbose and their names followed strict
rules. Specifically, every command began with a verb followed by an object,
and one or two modifiers might occur between them. The individual words
were separated by underscores. And, every command could be abbreviated in a
standard and predictable way -- first three letters of verb followed by
first letter of each subsequent word. Examples:

create_file (abbreviated cref)

delete_file (abbreviated delf)

display_catalog (disc)

display_command_list (discl)

display_command_parameters (discp)

edit_file (edif)

etc.


There were similar, predictable rules about command parameter names and
their abbreviations.

The language truly was very predictable and actually quite easy to learn
because of it. Unfortunately, it reached the market too late. For example,
it came to market around the same time as X-Windows, which muted the need
for "user-friendly" command languages. Also, NOS/VE ran on expensive Cyber
180 mainframes and came to market during the time that supermini's were
flourishing and Moore's Law was turning PC's into competitive computing
platforms too.

On Thu, May 16, 2024 at 11:13 AM Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> > On May 16, 2024, at 11:08 AM, Gary Grebus via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > We were a beta test site for NOS/VE and the hardware (Cyber 180?).  CDC
> sent the machine and a software support engineer to help us do something
> with it.  My one recollection was that the command language was horribly
> awkward, but I didn't spend much time on the system.
> >
> > I know there are some manuals for NOS/VE on bitsavers, but I wonder if
> any of the software still exists?
>
> I don't know if it does.  The other issue is that there isn't as far as I
> know, an emulator that supports the 64 bit mode it needs.  There is of
> course a (very solid) emulator for the classic 60 bit architecture, DtCyber.
>
> paul
>
>


[cctalk] Re: RIP: Software design pioneer and Pascal creator Niklaus Wirth

2024-01-05 Thread Kevin Jordan via cctalk
Both ALGOL60 and ALGOL68 are also available on the CDC Cyber 865 and CDC Cyber 
175 at the Nostalgic Computing Center (http://www.nostalgiccomputing.org), and 
both are also available in the NOS 2.8.7 distribution with DtCyber in the 
GitHub repo at https://github.com/kej715/DtCyber. Pascal is available at those 
locations too. It’s not the original version written fir CDC Maxine’s by Wirth, 
but probably a direct descendant of it.

> On Jan 5, 2024, at 4:02 PM, Gary Grebus via cctalk  
> wrote:
> 
> On 1/4/24 19:34, Paul Koning via cctalk wrote:
>> I think the CDC 6000 Algol 68 is still around somewhere.  That one was 
>> created in Holland.
> There is NOS/BE install for DtCyber available from retro1.org.  It includes 
> binaries of both Algol 60 and Algol 68 compilers.
> 
>Gary
> 
> 


[cctalk] Re: Data General Nova and Eclipse Hobbyist License...

2022-10-27 Thread Kevin Jordan via cctalk
Hi Bruce,

This is wonderful news. Is there a chance that AOS/VS will be included in
the future, along with an MV series emulator?

thanks!
Kevin

On Mon, Oct 24, 2022 at 8:23 PM Bruce Ray via cctalk 
wrote:

> G'day Paul -
>
>
> It is not a sublicense - Wild Hare Computer Systems, Inc., now has full
> IP rights and title to Data General software pursuant to a transfer
> agreement by DG/EMC[/Dell] and Wild Hare.
>
>
>
> Bruce Ray
> Wild Hare Computer Systems, Inc.
>
>
> On 10/24/2022 5:35 PM, Paul Koning via cctalk wrote:
> > Very nice!  So I take it that's a sublicense of Dell/EMC IP?  It doesn't
> say that.
> >
> >   paul
> >
> >
> >> On Oct 24, 2022, at 6:26 PM, Bruce Ray via cctalk <
> cctalk@classiccmp.org> wrote:
> >>
> >>
> >> Wild Hare Computer Systems, Inc., is pleased to announce that a
> >> "Hobbyist License" is now available for legacy Data General
> >> Nova and Eclipse software.  This license allows educational, hobbyist,
> >> non-commercial use of the vast amount of DG software - software
> >> that changed the world in many ways.
> >>
> >> The initial archives are currently available at:
> >>
> >> www.NovasAreForever.org/dgsw
> >>
> >> and includes documentation for the corresponding software.
> >>
> >>
> >> This October announcement also honors the 54th anniversary of the
> original
> >> Data General Nova. An international celebration of the Nova's 50th
> anniversary was
> >> hosted by Wild Computer Systems in Colorado, USA.  Some of the
> festivities
> >> can be seen at:
> >>
> >> www.Nova-At-50.org
> >>
> >> and
> >>
> >> www.Nova-At-50.org/album/index.html
> >>
> >>
> >> To complement this Hobbyist License, a Nova and Eclipse emulator that
> can run all of the
> >> software will be introduced later this week.
> >>
> >>
> >> Wild Hare Computer Systems is dedicated to preserving Data General's
> >> significant contributions to computer history.  We seek DG hardware,
> software, documentation,
> >> sales literature - basically "anything DG" - that can be added to the
> >> archives for posterity.
> >>
> >>
> >>
> >> Bruce Ray
> >> Wild Hare Computer Systems, Inc.
> >> Denver, Colorado USA
> >> b...@wildharecomputers.com
> >>
> >> ...preserving the Data General legacy: www.NovasAreForever.org
> >>
> >> www.WildHareComputers.com
> >>
> >> www.NovasAreForever.org
> >
>


Re: APL\360

2021-01-15 Thread Kevin Jordan via cctalk
If you would like to re/experience APL, four classic implementations are
available on five machines running at the Nostalgic Computing Center
:

   - APL 2 (aka APLUM) on the CDC Cyber 865 and Cyber 175 NOS 2 systems
   - APLSF on the PDP-10 TOPS-20 system
   - APL-11 on the PDP-11 RSX-11M-Plus system
   - APL/Z on the Z80 CP/M system

The NCC is also planning to install APL\360 on its IBM 4381 VM/CMS system,
per instructions recently posted on the Hercules forum.

cheers,
Kevin

On Thu, Jan 14, 2021 at 8:45 PM Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

> I was just poking around the computerhistory.org website, searching for
> Knuth stuff.
>
> The second or third hit when I search for "Knuth" is this one:
> https://computerhistory.org/blog/the-apl-programming-language-source-code/
> .  It's not just about APL, it actually has a downloadable copy of the
> source code.  And it points to an executable version, apparently a packaged
> up Hercules running that code.
>
> Nice.  I'll have to give it a try.
>
> paul
>
>


Problems with FORT and ALGOL in TSS/8

2020-12-03 Thread Kevin Jordan via cctalk
Hi everyone,

The Nostalgic Computing Center  has a
virtual PDP-8 running TSS/8

in its collection. We use the SIMH PDP-8e emulator to support the machine,
and we recently updated the machine to run the TSS/8 distribution created
by LCM+L, found here on GitHub
. The LCM+L distribution
is slightly different from other TSS/8 distributions available on the web
in that it provides some additional goodies such as ALGOL and LISP.

The NCC demonstrates how various classic computers worked by providing
automated scripts that interact with the machines in the collection.
For example, to demonstrate each of the programming languages supported by
a machine, scripts are provided to create, compile, and run a simple
Fibonacci sequence generator. We've done this for the TSS/8 system, but the
scripts aren't working for FORTRAN or ALGOL, and we're wondering if anyone
on this list might know why.

Specifically, in the case of FORTRAN, the compiler exits with an error code
6204. This occurs even when trying to compile trivial "hello world"
programs, and it appears to occur in all other TSS/8 distributions we've
tried as well (i.e., this particular problem is not unique to the LCM+L
distribution). We haven't found error code 6204 specifically documented in
the TSS/8 user/admin manuals, but the manuals do document other error codes
in the 62xx range. Documented error codes in the 62xx range appear to
reflect file I/O errors, so we're wondering if perhaps one of the files
supporting the FORTRAN compiler is corrupt in all of these distributions.

For example, here is a transcription of a simple session demonstrating the
problem:

.R EDIT

 INPUT:
OUTPUT:FTEST
A
  WRITE(1,10)
10FORMAT(5HHELLO,/)
  END

E
^BS
.R FORT

 INPUT:FTEST
OUTPUT:
6204^BS

.


We tried enabling the floating point processor to see if lack of FPP might
cause FORT to abort, but enabling the FPP did not solve the problem. The
SIMH configuration file for the machine currently looks like:

set throttle 800K
set df disabled
set rf disabled
set rk enabled
set dt enabled
att rk0 tss8_rk_lcm.dsk

set cpu 32k
attach ttix 4000

load boot.bin
run 200


Note that BASIC, FOCAL, and LISP all seem to run very nicely on the machine.

The problem we're experiencing with ALGOL appears to be a glaring compiler
bug, but the compiler was distributed widely through DECUS, and it is
difficult to imagine that it would have been released with an obvious bug,
so we are wondering if perhaps we're not interpreting the user manual

correctly. Here is a transcription of a session that exhibits the problem:

.R EDIT

 INPUT:
OUTPUT:ATEST
A

'BEGIN'

  'INTEGER' I;

  I := 1;

  WRITE(1, I); SKIP

'END'
$


E
^BS
.R ALGOL

 INPUT:ATEST
OUTPUT:

*TOO MANY UNDEFINED [UEXPRESSION*

^BS
.


The compiler seems to be complaining that the simple assignment statement
on line 3 of the program is somehow incorrect. If we change the statement
to "I := 1 + 0;", the error message goes away,  and the program runs, but
it prints "0" instead of the expected "1".  Also, if we change the program
to:

'BEGIN'
  'INTEGER' I;

  'FOR' I := 1 'STEP' 1 'UNTIL' 10 'DO'
  'BEGIN'

WRITE(1, I); SKIP
  'END'
'END'

$


it compiles successfully and it prints what is expected, the numbers 1
through 10.

Does anyone have experience with the ALGOL/8 compiler? If so, does this
behavior make sense, and can you let us know what we're doing wrong?

Note that the same ALGOL60 program compiles and runs as expected on the CDC
mainframes and the TOPS-20 system at the NCC.

thanks!
Kevin