On Mon, 1 Aug 2022 12:22:38 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> If engineers built bridges the way programmers write programs, the first
> stiff breeze that came along would destroy civilization.

Tacoma Narrows 1940 - nuff said ?

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On Mon, 1 Aug 2022 12:22:36 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> 25B.Z959 <25B.Z959@nada.net> wrote:
> > On 7/29/22 6:23 PM, Peter Flass wrote:
> >> The Natural Philosopher <tnp@invalid.invalid> wrote:
> >>> On 28/07/2022 20:13, Peter Flass wrote:
> >>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
> >>>>> On 28/07/2022 12:01, Dan Espen wrote:
> >>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
> >
> > Ya know what WILL last 100+ years ? Those notebooks
> > full of the wide-format 8-pin printed fanfold paper :-)
> >
>
> Yes! Same with dead-tree photos. Not so much color photos, but
> black-and-white photos have lasted well over 100 years with no discernible
> degradation, and no special hardware or software required to view them.

The monks had it right, constantly copying to fresh media and
verifying the copies. Starting with digitised data does make the copying and
verification somewhat easier and far more reliable. Data should easily last
as long as anyone cares to maintain it. Now the more tricky part is data
nobody cares to maintain, it's probably going to get lost.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On Mon, 01 Aug 2022 18:53:36 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> I still have my IMSAI with its two 8-inch floppy drives.

The second hand price still hasn't reached the inflation adjusted
purchase price, hang on to it :)

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On Mon, 1 Aug 2022 12:22:42 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> Ahem A Rivet's Shot <steveo@eircom.net> wrote:

> > Oh yes - best distinction between software and firmware I can
> > think of. Firmware is guaranteed not to go away when the power is off.
> >
>
> Programs in core memory didn’t either.

Most of the time - that's why I said guaranteed. TBH it's still a
very incomplete characterisation of firmware but running from non volatile
memory is a key characteristic IMHO.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

scott@slp53.sl.home (Scott Lurndal) writes:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Mon, 01 Aug 2022 09:45:53 -0500, D.J. wrote:

>>> I've never seen an 8" floppy drive anywhere.

>> They are rarer than hen's teeth, these days.

>> My first encounter with an 8" floppy disk drive was in loading
>> the microcode into a S/370-30 mainframe. Later, when I acquired
>> my first home computer (a Cromemco Z2) I loaded CP/M from 8"
>> disks on my dual-drive Persci voice-coil floppy disk drive.

> It may be that Al has one at the CHM. I've seen references on the
> PDP-11 groups to folks using 8" floppies on working PDP-11's.

The RX01 and RX02 8" floppy drives were used on PDP-11 and PDP-8 systems to my
certain knowledge, and likely on some PDP-15s but that's speculation on my part.

The DEC-20 (PDP-10 system built on the KL-10 processor) was a special case:
The boot processor (referred to as the "front end") was a PDP-11/40 with either
a pair of DECtape drives or a pair of RX01 floppies. They were used to boot
either the diagnostic monitor KLDCP or the OS RSX-20F (based on RSX-11D with
some -11M mods) if the RP06 boot drive was unavailable (e.g., if the OSes for
the 11/40 and the KL-10 had not yet been installed there).

The VAX-11/780 also required an RX01 to load microcode and boot.

> Some of the Bx9xx series Burroughs mainframes had 8" floppies (e.g. B2900)
> and others used 5 1/4" (B4900) to load microcode and the initial boot loader.

Yup. Same deal.

Did the Burroughs systems always require the floppies (like the VAX), or were
they an adjunct not usually in use (like the KL-10 systems)?

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Rich Alderson <news@alderson.users.panix.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>

>
>> Some of the Bx9xx series Burroughs mainframes had 8" floppies (e.g. B2900)
>> and others used 5 1/4" (B4900) to load microcode and the initial boot loader.
>
>Yup. Same deal.
>
>Did the Burroughs systems always require the floppies (like the VAX), or were
>they an adjunct not usually in use (like the KL-10 systems)?

The control store floppies were only used in the rare case that the system
was power cycled. Otherwise, with a push of a button on the
front of the system, the floppy was accessible to applications
running under the MCP.

Note that the V380 at the Living History Museum is just a rebadged
B4900 and it uses the control store floppies at power up. Normally the panel
floppy (PANDLP or PANEL) is kept in the drive in case a halt-load is initiated
from the console maintenance processsor (MP) (the bootstrap program
(which I wrote) is loaded from the floppy into memory by the MP and
the MP tickles the scan chains to start the processor). Halt/Load
initiated by the MCP doesn't require the floppy and would have been
the normal way to reboot if necessary.

According to Lew Pitcher <lew.pitcher@digitalfreehold.ca>:
>TBH, I didn't tell the whole story. It was a 3890 High Speed Cheque
>Processor, and (according to the IBM CE, and the service manuals)
>had an embedded 360/30 that made all the stacker decisions. The
>8" floppy in the back was used for loading the microcode and
>offline programs written in SCI (Stacker Control Instructions).

Wikipedia says the early 3890s were controlled by a 360/25 which is
a lot easier to believe, since it was later and cheaper than the /30
and its control store was writable core. The last model of 3890
was controlled by a PS/2-80 with an 80386 CPU.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to Rich Alderson <news@alderson.users.panix.com>:
>APL is more than a decade older than the PET.

Iverson described it in a book in 1957. The first implementations were
on IBM mainframes in the late 1960s.

>The first personal computer implementation was the IBM 5100, c. 1972.

It was an amazing hack. The 5100's processor ran an emulator that
provided most of the 360's instruction set, and it ran a slightly
modified APLSV. It also could run BASIC on an emulated S/3.

>It was used on the 360 and on the IBM 1800 (running the 1500 operating system)
>in the Computer-Assisted Instruction Lab at UTexas in the late 1960s. That's
>where I first used it.

I briefly used APL\1130 which I assume is the same as what you used on the 1800.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to Peter Flass <peter_flass@yahoo.com>:
>> Oh yes - best distinction between software and firmware I can think
>> of. Firmware is guaranteed not to go away when the power is off.
>
>Programs in core memory didn’t either. We used a diskless MDS-2400 as an
>RJE station. We’d load the emulator once and then could turn the machine
>off and on whenever we wanted. I would assume 360/20 RJE was the same.

I used some 360/20's as RJE terminals to Princeton's 360/91. They had
core memory so the memory contents didn't go away when the power
failed, but the only way to start a /20 was to IPL it from the card
reader so we always reloaded the program when we restarted it.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Mon, 1 Aug 2022 12:22:36 -0700
> Peter Flass <peter_flass@yahoo.com> wrote:
>
>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>> On 7/29/22 6:23 PM, Peter Flass wrote:
>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>> On 28/07/2022 20:13, Peter Flass wrote:
>>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>>> On 28/07/2022 12:01, Dan Espen wrote:
>>>>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>
>>> Ya know what WILL last 100+ years ? Those notebooks
>>> full of the wide-format 8-pin printed fanfold paper :-)
>>>
>>
>> Yes! Same with dead-tree photos. Not so much color photos, but
>> black-and-white photos have lasted well over 100 years with no discernible
>> degradation, and no special hardware or software required to view them.
>
> The monks had it right, constantly copying to fresh media and
> verifying the copies. Starting with digitised data does make the copying and
> verification somewhat easier and far more reliable. Data should easily last
> as long as anyone cares to maintain it. Now the more tricky part is data
> nobody cares to maintain, it's probably going to get lost.
>

I’m just reading Asimov’s _Prelude to Foundation_, and one theme is the
loss of data over time.

I’m also experiencing some of this now. I’m looking for some programs I had
some years ago, but a couple of computer upgrades and data that was on
various sizes of floppies makes this iffy. I try to copy what’s important,
and make archival copies including media upgrades, but things fall thru the
cracks. i’m

--
Pete

On 8/1/22 3:56 PM, Rich Alderson wrote:
> "25B.Z959" <25B.Z959@nada.net> writes:
>
>> As best I remember, APL came with some of the old
>> Commodore PET computers - considered a rival for
>> BASIC at the time. Yes, you CAN "concisely" render
>> a lot of math stuff, but ........
>
> APL is more than a decade older than the PET.
>
> The first personal computer implementation was the IBM 5100, c. 1972.

According to a wiki ... the PRICE was from $9000 to $19,000
1975 US dollars - with a whopping 1.9MHz CPU. This wasn't
really a "personal" computer unless you were rich out the ass.

LOOKED kinda like the IBM "Portable PC" though - same
idea, very similar form factor. THAT used an 8088 though,
with a socket for an 8087. Basically the "non portable"
PC with a handle. The damned things were EXTREMELY heavy
though ... I know, I used some "in the field" and you
didn't want to lug them very far :-)

> It was used on the 360 and on the IBM 1800 (running the 1500 operating system)
> in the Computer-Assisted Instruction Lab at UTexas in the late 1960s. That's
> where I first used it.
>
> It was available on DEC PDP-10 systems as well.

It's certainly not a new language. The question was
whether it was a "good" language - esp for newbies.
You COULD get it for the Commodore PETs, but almost
nobody used it and that was a sign for the future.

My vote ... NO ! It is NOT good for newbies.

It's really not even "good" for the experienced, WAY
too cryptic. Makes 'C' look self-documenting.

I suppose they could have written Winders using FORTH -
but for some odd reason they didn't :-)

(FORTH did/does actually have a place - as kind of the
bare minimum language you can fit into microcontrollers
and very low-end CPUs. I understand that it's still
kinda popular with astronomers building controls for
big telescopes and such)

On 7/25/22 7:37 AM, Johnny Billquist wrote:
> On 2022-07-24 00:23, Peter Flass wrote:
> > 25B.Z959 <25B.Z959@nada.net> wrote:
> >>    Sometimes that IS a factor ... you have to have people who
> >>    can write it. But 1990 ... IMHO it should have been 'C'.
> >>
> >
> > IMNSHO, COBOL. C is a terrible language for those types of language.
> Things
> >   that are so dimple in COBOL, like moving a character string with blank
> > fill, or formatting numeric output, requires calling subroutines in
> C, and
> > lack of length checking on string moves is a recipe for disaster.
> This is one of the weirder arguments I've ever seen:
> "requires calling a subroutine in C". As if that somehow is a problem?
> Not to mention it's a function, and not a subroutine. Any claim of "used
> the language quite a bit" sounds hollow after that.
>
> A statement to move a character string in COBOL will in the end be a
> subroutine call as well.
>
> And lack of length checking depends on the function. Nothing prevents
> you from using strncpy in C. Or write your own, with whatever
> characteristic you want. It will actually be pretty efficient.
> Comparable to the provided functions.
>
> > I have used both languages quite a bit, perhaps COBOL more, years
> ago, but
> > neither is my preferred language, so I have no dog in this fight.
> > …
> Seems like your C is both rusty and bad.
>
> >>    Mostly I like "terse" languages - less typing and lots
> >>    of room left over for comments at the ends of the lines.
> >
> > Sounds like assembler ;-)
> >
> > It’s too easy to write tricky code with side-effects in C. COBOL
> might not
> > be as self-documenting as advertised, but the operation of each
> statement
> > is pretty obvious and easily understood.
> What kind of side effects are we talking about? The operation of each
> statement in C is very obvious and easy to understand.
> Most people get into trouble because of memory handling. Not the
> language semantics.
> But that is where you get to the point where things gets even harder to
> even do in COBOL. And if you manage to do it, it won't be easily
> understood.

With all the talk about COBOL, I actually wrote some
today. Hadn't done so in like 35+ years.

Ya know what .... it kinda SUCKS. Beyond the mere verbosity
it is heavily oriented around fixed-sized vars and records.
and can get VERY anal if you try to mix types - maybe even
worse than ADA in that respect. I spent an hour on a compact
'strlen()' that would actually tell you how long the string
REALLY was, as opposed to how many bytes were officially
allocated for it. No loop breaks unless you kinda cheat to
engineer some - or use GOTOs. It's meant to process "business"
records. Try to go beyond that and you'll SUFFER. You COULD
write Winders or Linux with it - but WHY ???

Since COBOL, esp for smaller apps, I've liked to create
ASCII-delimited multi-value records kinda in the PICK
tradition. They're easy to create and humans can actually
READ them. After an hour of Duck and Google I *still*
couldn't see how to append "non-printable" ASCII chars
to a string. Super-duper easy in 'C' and Python and Pascal,
but COBOL once again wasn't MEANT for that and it's a
huge fight. No "S1+chr(254)". (Some IBM COBOLS do have
a "CHAR(nnn)" ... but not the COBOL I had).

It just shouldn't be hard to do this kind of stuff. IMHO
a "good" computer language provides clear simple no-BS ways
to do most ANYTHING you want. PL/I is better in that
respect, amongst the 'older' langs, usually SEVERAL ways
to do whatever you need to do. I was able to do the kinds
of things I wanted MUCH easier with FORTRAN - and there's
a practical little app that evolved from that.

I'll finish my little COBOL app, mostly as a how-to
template ... but it WILL actually DO some little thing
of value, just to make my successors suffer a bit ...
er ... to ENLIGHTEN them :-)

Now if I could just find some punch-cards and a reader ...
paper tape ...... "If you want to see your 5 year pay and
benifits profile, just insert the 4-meter long paper tape
in the reader and press ..." - heh, heh, heh :-)

On 8/1/22 10:45 AM, D.J. wrote:
> On Sun, 31 Jul 2022 23:23:35 -0400, "25B.Z959" <25B.Z959@nada.net>
> wrote:
>> On 7/29/22 6:23 PM, Peter Flass wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 28/07/2022 20:13, Peter Flass wrote:
>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>> On 28/07/2022 12:01, Dan Espen wrote:
>>>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> But then it has to deal with packed decimals ... :-)
>>>>>>>>
>>>>>>>> 'Efficient' is kind of relative - is it fewer ASM bytes
>>>>>>>> or fewer ultimate CPU cycles ?
>>>>>>>>
>>>>>> Depends. Sometimes it was lack of EPROM space
>>>>>> Sometimes it was lack of CPU Hz.
>>>>>> What isn't efficient is low source code byte count achieved by removing
>>>>>> the comments
>>>>>>
>>>>>
>>>>> Unless your source is on paper tape.
>>>>>
>>>> It is still going to end up as machine code long before you run it
>>>>
>>>>
>>>
>>> If you punch your code on cards, you get one instruction per card. The
>>> other sixty or so characters will be there whether they’re blanks or a
>>> comment, so you might as well comment. If you use paper tape, comments will
>>> balloon the size of your source to several times it’s size, and you have to
>>> read in all that tape to compile. I think early tapes used card-images,
>>> blocked or unblocked, so, again, comments were “free.”
>>
>> Largely true ... the "Real App Tapes" didn't include the
>> comments - that was "elsewhere", printed onto the wide-
>> format fan-fold paper with green stripes in the local equiv
>> of Courier-12 by an 8-pin teletype/printer, where'd it'd
>> soon get lost or totally out-of-sync because people kept
>> making "tweaks" without documenting them in the slightest
>> beyond MAYbe a scribble on their deskpads ..........
>>
>> This was when "large convenient removable storage" was
>> 8" SS/SD floppies. I still come across white ring
>> notebooks with those printouts, and several of those
>> old floppies. Is it even POSSIBLE to read those disk
>> formats these days ???
>>
>> The same is coming to apply to 5-1/4 disks SS/SD thru
>> DS/QuadD/HD, and it won't be long before even 3-1/2
>> and CD/DVD disks won't have any readers. You didn't
>> use "ZIP disks", did you ?). Yer "safest" bet may be
>> "the cloud" - but eventually they'll all get hacked
>> or go out of business so REPLICATION is the holy grail.
>
> The last time I looked online, about 2019, I was able to locate for
> sale an external USB 3.5" floppy drive.

Harder and harder to find these days. For an INTERNAL 3-1/2
you'll need to find a mboard kinda of the Core2-Quad vintage
where there were still dedicated headers on the board. I
have one - and will KEEP it. ALSO supports 5-1/4" and has
a parallel port that can run ZIP disks. A valuable bit of
hardware (and NOT as slow as you'd think).

But 8" floppies ... no ... nothing anymore. Those died out
in the early 80s. No hardware, no drivers .....

> I still have, somewhere, in a storage box, a 5.25" floppy drive,
> internal. And i think I still have a desktop computer i can put it in.
> No idea if the PSU, or the hard drive, stil lwork though.
>
> I've never seen an 8" floppy drive anywhere.
> --
> Jim

I used an LSI-11 system with those for a couple of years.
They were REALLY "floppy" :-) Still have a few notebooks
with the print-outs AND those disk in there. There were also
some that were like 12" ... and held even LESS data. Never
used those. I think they weren't even MFM encoded, more like
pure FM. the Original Deal.

I did like those old hard drives with the removable
disk-stacks. DO make sure the thing has reached zero
RPMs before attempting to EXTRACT the pack though.

For the newbies, you opened the lid on what kinda looked
like a little top-loading washing machine, pushed a big
plastic 12-inch or so top-cover down over the disk-stack,
twisted it to lock and then physically lifted the stack
out of the "drive". However the safety interlocks, IF they
existed, didn't always work right ... the stack MIGHT
still be at like 1000 RPM when you pulled it out.
Google the term "gyroscopic precession" :-)

Mid 80s I took a tour of an attack sub - and in the
sonar niche they were STILL using those kinds of
disk drives ... might still BE for all I know, those
systems are spec'ed like ten+ YEARS before actual
construction ...........

On 8/1/22 3:22 PM, Peter Flass wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Mon, 01 Aug 2022 14:50:20 +0000, Lew Pitcher wrote:
>>
>>> On Mon, 01 Aug 2022 09:45:53 -0500, D.J. wrote:
>>>>
>>>> I've never seen an 8" floppy drive anywhere.
>>>
>>> They are rarer than hen's teeth, these days.
>>>
>>> My first encounter with an 8" floppy disk drive was in loading
>>> the microcode into a S/370-30 mainframe. Later, when I acquired
>>
>> Correction: I meant to say a S/360-30 mainframe. I later worked on
>> S/370 systems, but the /first/ time I saw an 8" floppy was the
>> S/360 microcode.
>>
>>> my first home computer (a Cromemco Z2) I loaded CP/M from 8"
>>> disks on my dual-drive Persci voice-coil floppy disk drive.
>>
>
> 360/30 used CCROS microcode - mylar cards the size and shape of a standard
> IBM card. I once watched a CE punch and install a patch.

I'd LOVE to find a surplus 360/370 ... but can you get
any PARTS for them anymore ? (that includes mag/paper
tape, esp with an OS) I've got this empty room ....

The Cromeco's were nice units too ... way beyond my
paychecks at the time alas. There were a ton of
S-100 buss systems for awhile there - from 8008s
to early 68000 series CPUs. The "CPU" bit was sometimes
spread over a couple plug-in cards. S-100 was very
good, but it did have speed limitations and after
awhile 100 pins still weren't enough, so ....

There were a couple of S-100 rivals in the backplane-
system universe. I don't know if any still survive in
any useful role.

On 8/1/22 3:22 PM, Peter Flass wrote:
> 25B.Z959 <25B.Z959@nada.net> wrote:
>> On 7/29/22 6:23 PM, Peter Flass wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 28/07/2022 20:13, Peter Flass wrote:
>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>> On 28/07/2022 12:01, Dan Espen wrote:
>>>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>
>> Ya know what WILL last 100+ years ? Those notebooks
>> full of the wide-format 8-pin printed fanfold paper :-)
>>
>
> Yes! Same with dead-tree photos. Not so much color photos, but
> black-and-white photos have lasted well over 100 years with no discernible
> degradation, and no special hardware or software required to view them.

B&W is "forever" - literal metallic grains. On good
museum-quality paper they'll hold for centuries.

And you can still find perfect Daguerreotypes, tintypes
and even autochromes (used dyed grains of potato starch
to get etherial color photos from B&W plates). Oddly
some of the last, and kinda popular with law-enforcement,
Polaroid films used the same trick - but with tight color
stripes on the film base. I've got the little processing
machine somewhere - but there's no more film.

KodaChrome is also "forever"...but the processors were
nearly the size of a bus and required several harried
techs to keep everything perfect. Doubt it exists anymore.

A guy I know spent three weeks at a workshop on how to
make dye-transfer prints - from large-format transparencies.
Absolutely STUNNING ... 3-feet wide and you could STILL put
a magnifying glass to 'em and see more detail and nuance.
Supposedly those are "forever" too. Of course this guy's
equipment was well into five (1980s) figures ....

In *theory*, digital is "forever" ... but format drift
and the hardware base complicates the picture, so to speak.
It's also an intangible media, something that could disappear,
whereas film/paper will persist and persist.

And yes, those notebooks with wide-format print-outs of
old COBOL and FORTRAN programs will be around 100+ years
from now too. Just ask the great-great-grandaughter of
Empress Siri to run 'em for you - IF she feels like
catering to mere humans today :-)

On 7/26/22 5:20 PM, Ahem A Rivet's Shot wrote:
> On Tue, 26 Jul 2022 13:49:44 -0700
> Peter Flass <peter_flass@yahoo.com> wrote:
>
>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>> On Tue, 26 Jul 2022 14:13:56 +0100
>>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>
>>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>>> C is the exact opposite, terse, machine level assembler but faster
>>>>> coded.
>>>>
>>>> “Assembler” is a terrible mental model for C.
>>>>
>>>> richard@sfere:~/junk$ cat t.c
>>>> int f(int *ptr) {
>>>> int r = *ptr;
>>>
>>> If ptr is 0 this is undefined behaviour aka probably SEGV.
>>
>> The programmer makes assumptions based on what he/she knows. Presumably
>> the original author might “know” that ptr will never be zero (previously
>
> Programmer tests ptr for 0 in the next statement. Buggy code!

Sounds sensible ... even in ASM you should be careful
about ASSUMING. If NIL could be bad, CHECK for it.

On 7/31/22 5:26 PM, Scott Lurndal wrote:
> "25B.Z959" <25B.Z959@nada.net> writes:
>> On 7/30/22 10:56 AM, Scott Lurndal wrote:
>>> drb@ihatespam.msu.edu (Dennis Boone) writes:
>
>> Oh, and the "one instruction" required those params,
>> which meant there was a lot going on inside to fetch
>> and manipulate and move memory blocks. It wasn't REALLY
>> "one instruction", just an extra-complex poly-instruction
>> in the CISC, vs RISC, tradition.
>
> As usual, you are incorrect. The opcode (94) was decoded
> into a signal that causes the channel number to be decoded
> (top 3 bits decoded into a rack select, bottom three bits
> put on the bus in the rack and is latched by an I/O
> control jumpered to that ID. The bus also contains
> the op (read/write/test/echo) and variant digits all of
> which are captured and decoded with logic circuits.
>
> There's no microcontroller, just a bunch of state
> machines. The B3500 was transistor
> based, with some early use of SSI integrated circuits.
>
> It wasn't until the third generation (B4900) that microcode
> became a common adjunct to the hardwired logic.

You're still seeing the peripherals as separate
from The System. They were not, and still are not
even though there's a lot more abstraction these
days.

Do you have something against those hardware geeks
with the faint whiff of solder flux ? Don't let
them sit at the lunch counter ? :-)

Powerful I/O instructions REQUIRE "smart" periphs.
Doesn't matter how the smartness is implemented.
It's ALL part of The System, top to bottom.

On Mon, 1 Aug 2022 20:37:43 +0100
Ahem A Rivet's Shot <steveo@eircom.net> wrote:

> On Mon, 1 Aug 2022 12:22:38 -0700
> Peter Flass <peter_flass@yahoo.com> wrote:
>
> > If engineers built bridges the way programmers write programs, the first
> > stiff breeze that came along would destroy civilization.
>
> Tacoma Narrows 1940 - nuff said ?
>
Beta-test first. And always keep a backup.

--
Bah, and indeed Humbug.

On Mon, 1 Aug 2022 22:59:00 -0400
"25B.Z959" <25B.Z959@nada.net> wrote:

> On 8/1/22 3:56 PM, Rich Alderson wrote:
> > "25B.Z959" <25B.Z959@nada.net> writes:
> >
> >> As best I remember, APL came with some of the old
> >> Commodore PET computers - considered a rival for
> >> BASIC at the time. Yes, you CAN "concisely" render
> >> a lot of math stuff, but ........
> >
> > APL is more than a decade older than the PET.
> >
> > The first personal computer implementation was the IBM 5100, c. 1972.
>
> According to a wiki ... the PRICE was from $9000 to $19,000
> 1975 US dollars - with a whopping 1.9MHz CPU. This wasn't
> really a "personal" computer unless you were rich out the ass.
>
> LOOKED kinda like the IBM "Portable PC" though - same
> idea, very similar form factor. THAT used an 8088 though,
> with a socket for an 8087. Basically the "non portable"
> PC with a handle. The damned things were EXTREMELY heavy
> though ... I know, I used some "in the field" and you
> didn't want to lug them very far :-)
>
> > It was used on the 360 and on the IBM 1800 (running the 1500 operating system)
> > in the Computer-Assisted Instruction Lab at UTexas in the late 1960s. That's
> > where I first used it.
> >
> > It was available on DEC PDP-10 systems as well.
>
> It's certainly not a new language. The question was
> whether it was a "good" language - esp for newbies.
> You COULD get it for the Commodore PETs, but almost
> nobody used it and that was a sign for the future.
>
> My vote ... NO ! It is NOT good for newbies.
>
> It's really not even "good" for the experienced, WAY
> too cryptic. Makes 'C' look self-documenting.
>
> I suppose they could have written Winders using FORTH -
> but for some odd reason they didn't :-)
>
> (FORTH did/does actually have a place - as kind of the
> bare minimum language you can fit into microcontrollers
> and very low-end CPUs. I understand that it's still
> kinda popular with astronomers building controls for
> big telescopes and such)

Be aware that it's erm a language to attracts individuals. See
news:comp.lang.forth
ffi.

--
Bah, and indeed Humbug.

"25B.Z959" <25B.Z959@nada.net> writes:
>On 7/31/22 5:26 PM, Scott Lurndal wrote:
>> "25B.Z959" <25B.Z959@nada.net> writes:
>>> On 7/30/22 10:56 AM, Scott Lurndal wrote:
>>>> drb@ihatespam.msu.edu (Dennis Boone) writes:

>> There's no microcontroller, just a bunch of state
>> machines. The B3500 was transistor
>> based, with some early use of SSI integrated circuits.
>>
>> It wasn't until the third generation (B4900) that microcode
>> became a common adjunct to the hardwired logic.
>
> You're still seeing the peripherals as separate
> from The System. They were not, and still are not
> even though there's a lot more abstraction these
> days.

Actually, at Burroughs, the peripherals were designed
and implemented in completely different states and or
countries, and were used for multiple lines of mainframes
(when they weren't outsourced to memorex).

The were completely separate from the system in
every possible respect.

>
> Do you have something against those hardware geeks
> with the faint whiff of solder flux ? Don't let
> them sit at the lunch counter ? :-)

I don't know what you're talking about. I spent 14 years
architecting and building mainframes and mainframe operating
systems.

>
> Powerful I/O instructions REQUIRE "smart" periphs.

No, they're not smart. Simple logic.

On Mon, 1 Aug 2022 12:22:39 -0700, Peter Flass <peter_flass@yahoo.com>
wrote:
>D.J. <chucktheouch@gmail.com> wrote:

[snip]

>> I still have, somewhere, in a storage box, a 5.25" floppy drive,
>> internal. And i think I still have a desktop computer i can put it in.
>> No idea if the PSU, or the hard drive, stil lwork though.
>
>I think I still have one, too. New in box. Are they still selling
>USB-attached external floppy drives?

I saw 3.5" external USB drives for sale online about 2018/19.
--
Jim

On Tue, 2 Aug 2022 01:05:20 -0400, "25B.Z959" <25B.Z959@nada.net>
wrote:
>On 8/1/22 10:45 AM, D.J. wrote:
>> I still have, somewhere, in a storage box, a 5.25" floppy drive,
>> internal. And i think I still have a desktop computer i can put it in.
>> No idea if the PSU, or the hard drive, stil lwork though.
>>
>> I've never seen an 8" floppy drive anywhere.
>
> I used an LSI-11 system with those for a couple of years.
> They were REALLY "floppy" :-) Still have a few notebooks
> with the print-outs AND those disk in there. There were also
> some that were like 12" ... and held even LESS data. Never
> used those. I think they weren't even MFM encoded, more like
> pure FM. the Original Deal.
>
> I did like those old hard drives with the removable
> disk-stacks. DO make sure the thing has reached zero
> RPMs before attempting to EXTRACT the pack though.
>
> For the newbies, you opened the lid on what kinda looked
> like a little top-loading washing machine, pushed a big
> plastic 12-inch or so top-cover down over the disk-stack,
> twisted it to lock and then physically lifted the stack
> out of the "drive". However the safety interlocks, IF they
> existed, didn't always work right ... the stack MIGHT
> still be at like 1000 RPM when you pulled it out.
> Google the term "gyroscopic precession" :-)
>
> Mid 80s I took a tour of an attack sub - and in the
> sonar niche they were STILL using those kinds of
> disk drives ... might still BE for all I know, those
> systems are spec'ed like ten+ YEARS before actual
> construction ...........

On the Dec Vax 11/730 at university, we used it for Pascal, there were
disc packs just like that. Had a backup, and two or three rotated out
for each semester.

The university guy who kept it in mantenance, bought cheap labels, and
one year one fel off onto the platters when they were still spinning.

I could hear him yell in agony from the next room. The faculty were
upset, as those platters held their homework plans, etc.

Six VT102 terminals at one camps, 4 VT102 terminals at another campus,
and a third location that library had an IBM PC, with a dial up modem.
All that so we could do our homework in VAX PASCAL.
--
Jim

25B.Z959 <25B.Z959@nada.net> wrote:
> On 8/1/22 10:45 AM, D.J. wrote:
>> On Sun, 31 Jul 2022 23:23:35 -0400, "25B.Z959" <25B.Z959@nada.net>
>> wrote:
>>> On 7/29/22 6:23 PM, Peter Flass wrote:
>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>> On 28/07/2022 20:13, Peter Flass wrote:
>>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>>> On 28/07/2022 12:01, Dan Espen wrote:
>>>>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> But then it has to deal with packed decimals ... :-)
>>>>>>>>>
>>>>>>>>> 'Efficient' is kind of relative - is it fewer ASM bytes
>>>>>>>>> or fewer ultimate CPU cycles ?
>>>>>>>>>
>>>>>>> Depends. Sometimes it was lack of EPROM space
>>>>>>> Sometimes it was lack of CPU Hz.
>>>>>>> What isn't efficient is low source code byte count achieved by removing
>>>>>>> the comments
>>>>>>>
>>>>>>
>>>>>> Unless your source is on paper tape.
>>>>>>
>>>>> It is still going to end up as machine code long before you run it
>>>>>
>>>>>
>>>>
>>>> If you punch your code on cards, you get one instruction per card. The
>>>> other sixty or so characters will be there whether they’re blanks or a
>>>> comment, so you might as well comment. If you use paper tape, comments will
>>>> balloon the size of your source to several times it’s size, and you have to
>>>> read in all that tape to compile. I think early tapes used card-images,
>>>> blocked or unblocked, so, again, comments were “free.”
>>>
>>> Largely true ... the "Real App Tapes" didn't include the
>>> comments - that was "elsewhere", printed onto the wide-
>>> format fan-fold paper with green stripes in the local equiv
>>> of Courier-12 by an 8-pin teletype/printer, where'd it'd
>>> soon get lost or totally out-of-sync because people kept
>>> making "tweaks" without documenting them in the slightest
>>> beyond MAYbe a scribble on their deskpads ..........
>>>
>>> This was when "large convenient removable storage" was
>>> 8" SS/SD floppies. I still come across white ring
>>> notebooks with those printouts, and several of those
>>> old floppies. Is it even POSSIBLE to read those disk
>>> formats these days ???
>>>
>>> The same is coming to apply to 5-1/4 disks SS/SD thru
>>> DS/QuadD/HD, and it won't be long before even 3-1/2
>>> and CD/DVD disks won't have any readers. You didn't
>>> use "ZIP disks", did you ?). Yer "safest" bet may be
>>> "the cloud" - but eventually they'll all get hacked
>>> or go out of business so REPLICATION is the holy grail.
>>
>> The last time I looked online, about 2019, I was able to locate for
>> sale an external USB 3.5" floppy drive.
>
> Harder and harder to find these days. For an INTERNAL 3-1/2
> you'll need to find a mboard kinda of the Core2-Quad vintage
> where there were still dedicated headers on the board. I
> have one - and will KEEP it. ALSO supports 5-1/4" and has
> a parallel port that can run ZIP disks. A valuable bit of
> hardware (and NOT as slow as you'd think).
>
> But 8" floppies ... no ... nothing anymore. Those died out
> in the early 80s. No hardware, no drivers .....
>
>> I still have, somewhere, in a storage box, a 5.25" floppy drive,
>> internal. And i think I still have a desktop computer i can put it in.
>> No idea if the PSU, or the hard drive, stil lwork though.
>>
>> I've never seen an 8" floppy drive anywhere.
>> --
>> Jim
>
> I used an LSI-11 system with those for a couple of years.
> They were REALLY "floppy" :-) Still have a few notebooks
> with the print-outs AND those disk in there. There were also
> some that were like 12" ... and held even LESS data. Never
> used those. I think they weren't even MFM encoded, more like
> pure FM. the Original Deal.
>
> I did like those old hard drives with the removable
> disk-stacks. DO make sure the thing has reached zero
> RPMs before attempting to EXTRACT the pack though.
>
> For the newbies, you opened the lid on what kinda looked
> like a little top-loading washing machine, pushed a big
> plastic 12-inch or so top-cover down over the disk-stack,
> twisted it to lock and then physically lifted the stack
> out of the "drive". However the safety interlocks, IF they
> existed, didn't always work right ... the stack MIGHT
> still be at like 1000 RPM when you pulled it out.
> Google the term "gyroscopic precession" :-)

We used to grab them before they stopped completely.

>
> Mid 80s I took a tour of an attack sub - and in the
> sonar niche they were STILL using those kinds of
> disk drives ... might still BE for all I know, those
> systems are spec'ed like ten+ YEARS before actual
> construction ...........
>

--
Pete

Kerr-Mudd, John <admin@127.0.0.1> wrote:
> On Mon, 1 Aug 2022 22:59:00 -0400
> "25B.Z959" <25B.Z959@nada.net> wrote:
>
>> On 8/1/22 3:56 PM, Rich Alderson wrote:
>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>
>>>> As best I remember, APL came with some of the old
>>>> Commodore PET computers - considered a rival for
>>>> BASIC at the time. Yes, you CAN "concisely" render
>>>> a lot of math stuff, but ........
>>>
>>> APL is more than a decade older than the PET.
>>>
>>> The first personal computer implementation was the IBM 5100, c. 1972.
>>
>> According to a wiki ... the PRICE was from $9000 to $19,000
>> 1975 US dollars - with a whopping 1.9MHz CPU. This wasn't
>> really a "personal" computer unless you were rich out the ass.
>>
>> LOOKED kinda like the IBM "Portable PC" though - same
>> idea, very similar form factor. THAT used an 8088 though,
>> with a socket for an 8087. Basically the "non portable"
>> PC with a handle. The damned things were EXTREMELY heavy
>> though ... I know, I used some "in the field" and you
>> didn't want to lug them very far :-)
>>
>>> It was used on the 360 and on the IBM 1800 (running the 1500 operating system)
>>> in the Computer-Assisted Instruction Lab at UTexas in the late 1960s. That's
>>> where I first used it.
>>>
>>> It was available on DEC PDP-10 systems as well.
>>
>> It's certainly not a new language. The question was
>> whether it was a "good" language - esp for newbies.
>> You COULD get it for the Commodore PETs, but almost
>> nobody used it and that was a sign for the future.
>>
>> My vote ... NO ! It is NOT good for newbies.
>>
>> It's really not even "good" for the experienced, WAY
>> too cryptic. Makes 'C' look self-documenting.
>>
>> I suppose they could have written Winders using FORTH -
>> but for some odd reason they didn't :-)
>>
>> (FORTH did/does actually have a place - as kind of the
>> bare minimum language you can fit into microcontrollers
>> and very low-end CPUs. I understand that it's still
>> kinda popular with astronomers building controls for
>> big telescopes and such)
>
> Be aware that it's erm a language to attracts individuals. See
> news:comp.lang.forth
> ffi.
>

I never used Forth. I remember reading about it in Byte and thought it was
an interesting language. Now that I could use it, I have no interest. A lot
of things that looked good on an 8K micro don’t look so good any more.

--
Pete

25B.Z959 <25B.Z959@nada.net> wrote:
> On 7/25/22 7:37 AM, Johnny Billquist wrote:
>> On 2022-07-24 00:23, Peter Flass wrote:
>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>     Sometimes that IS a factor ... you have to have people who
>>>>     can write it. But 1990 ... IMHO it should have been 'C'.
>>>>
>>>
>>> IMNSHO, COBOL. C is a terrible language for those types of language.
>> Things
>>>    that are so dimple in COBOL, like moving a character string with blank
>>> fill, or formatting numeric output, requires calling subroutines in
>> C, and
>>> lack of length checking on string moves is a recipe for disaster.
>> This is one of the weirder arguments I've ever seen:
>> "requires calling a subroutine in C". As if that somehow is a problem?
>> Not to mention it's a function, and not a subroutine. Any claim of "used
>> the language quite a bit" sounds hollow after that.
>>
>> A statement to move a character string in COBOL will in the end be a
>> subroutine call as well.
>>
>> And lack of length checking depends on the function. Nothing prevents
>> you from using strncpy in C. Or write your own, with whatever
>> characteristic you want. It will actually be pretty efficient.
>> Comparable to the provided functions.
>>
>>> I have used both languages quite a bit, perhaps COBOL more, years
>> ago, but
>>> neither is my preferred language, so I have no dog in this fight.
>>> …
>> Seems like your C is both rusty and bad.
>>
>>>>     Mostly I like "terse" languages - less typing and lots
>>>>     of room left over for comments at the ends of the lines.
>>>
>>> Sounds like assembler ;-)
>>>
>>> It’s too easy to write tricky code with side-effects in C. COBOL
>> might not
>>> be as self-documenting as advertised, but the operation of each
>> statement
>>> is pretty obvious and easily understood.
>> What kind of side effects are we talking about? The operation of each
>> statement in C is very obvious and easy to understand.
>> Most people get into trouble because of memory handling. Not the
>> language semantics.
>> But that is where you get to the point where things gets even harder to
>> even do in COBOL. And if you manage to do it, it won't be easily
>> understood.
>
> With all the talk about COBOL, I actually wrote some
> today. Hadn't done so in like 35+ years.
>
> Ya know what .... it kinda SUCKS. Beyond the mere verbosity
> it is heavily oriented around fixed-sized vars and records.
> and can get VERY anal if you try to mix types - maybe even
> worse than ADA in that respect. I spent an hour on a compact
> 'strlen()' that would actually tell you how long the string
> REALLY was, as opposed to how many bytes were officially
> allocated for it. No loop breaks unless you kinda cheat to
> engineer some - or use GOTOs. It's meant to process "business"
> records. Try to go beyond that and you'll SUFFER. You COULD
> write Winders or Linux with it - but WHY ???
>
> Since COBOL, esp for smaller apps, I've liked to create
> ASCII-delimited multi-value records kinda in the PICK
> tradition. They're easy to create and humans can actually
> READ them. After an hour of Duck and Google I *still*
> couldn't see how to append "non-printable" ASCII chars
> to a string. Super-duper easy in 'C' and Python and Pascal,
> but COBOL once again wasn't MEANT for that and it's a
> huge fight. No "S1+chr(254)". (Some IBM COBOLS do have
> a "CHAR(nnn)" ... but not the COBOL I had).
>
> It just shouldn't be hard to do this kind of stuff. IMHO
> a "good" computer language provides clear simple no-BS ways
> to do most ANYTHING you want. PL/I is better in that
> respect, amongst the 'older' langs, usually SEVERAL ways
> to do whatever you need to do. I was able to do the kinds
> of things I wanted MUCH easier with FORTRAN - and there's
> a practical little app that evolved from that.

PL/I is better than just about anything. When I couldn’t get a version for
my system I decided to write my own.

>
> I'll finish my little COBOL app, mostly as a how-to
> template ... but it WILL actually DO some little thing
> of value, just to make my successors suffer a bit ...
> er ... to ENLIGHTEN them :-)
>
> Now if I could just find some punch-cards and a reader ...
> paper tape ...... "If you want to see your 5 year pay and
> benifits profile, just insert the 4-meter long paper tape
> in the reader and press ..." - heh, heh, heh :-)
>

--
Pete