Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » Re: Fwd: Linux on a small memory PC
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: COBOL and tricks [message #415769 is a reply to message #415758] Sat, 30 July 2022 19:50 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/30/22 8:16 AM, Dan Espen wrote:
> "25B.Z959" <25B.Z959@nada.net> writes:
>
>> On 7/29/22 5:41 PM, Dennis Boone wrote:
>>>> With a LOT of software/firmware/hardware involved in-between
>>>> that instruction and the actual human-readable output ....
>>> What people have been patiently trying to explain to you is that on
>>> many
>>> older machines, there was only hardware in between.
>>
>> "Hardware" just means "programmed in Solder".
>
> No.
>
> Words have meaning. Programming and soldering are 2 different things.
> You may want to call driving a stake into the ground programming
> building a tent, but it's not.

(Almost) all "hardware", electronic or not, is meant to
be incorporated into some kind of logically-designed
SYSTEM. A gear train or "X%10" serve the same sort of
function in said systems. Electronics is even more
"computing-like" than overt mechanics - indeed "programming
in Solder". We now have DSP processors that can replace a
lot of what those circuit boards were good at, but it's
not a FUNDAMENTAL difference, merely an alternative means.
CPUs are more "general purpose machines" but they're still
machines in the Babbage tradition and the program is just
another bunch of 'gears' crafted to make it do what's required.

So .. you pick your def, but I think my more-inclusive
def is most correct.

Think on it for awhile.
Re: COBOL and tricks [message #415772 is a reply to message #415761] Sat, 30 July 2022 20:35 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/30/22 10:56 AM, Scott Lurndal wrote:
> drb@ihatespam.msu.edu (Dennis Boone) writes:
>>> With a LOT of software/firmware/hardware involved in-between
>>> that instruction and the actual human-readable output ....
>>
>> What people have been patiently trying to explain to you is that on many
>> older machines, there was only hardware in between. These i/o
>> instructions that have been mentioned are NOT high level instructions.
>> They cause the CPU to put a bit pattern out a given set of signal lines.
>> Many of the CPUs in that era weren't even microcoded. The original
>> PDP-8 certainly wasn't. And most of the i/o devices weren't intelligent
>> either. Sending a character to a console teletype is a question of
>> sending a sequence of electrical pulses down a wire. The teletype
>> itself wasn't even electronic. It was purely electromechanical. Many
>> of the earlier card and paper tape devices were not at all intelligent,
>> but made up purely of some simple logic circuits.
>
> Take the Burroughs B3500 family; to read a single card into memory
> was a single instruction (well, not counting the wait for completion).
>
> II0 /01 IOD
>
> And at address IOD, there is an I/O descriptor
> consisting of a buffer start address (A), a buffer
> end address(B), and an optional "C" field.
>
> The Descriptor
> 400D00 000000 000159 000000
>
> would read a card from channel one into memory starting at address A
> zero through address B 159 (80 bytes). Change the @D@ to @C@ and it
> would convert the hollerith to EBCDIC instead of 6-bit BCL before
> storing in memory. Use @F@ and it would read as many cards as would
> fit into the supplied buffer.
>
> The A and B address fields provide the bounds of the memory buffer
> (recalling that the system addresses to the digit (nibble)).
>
> The C address field provided the
> sector number for disk I/O's and a block count for 7/9/18track tape
> skip forward/backward ops.
>
> Similarly for the printer,
> 420000 000000 000264 000000
>
> would print a single line to the line printer on channel 3 from
> memory starting at address zero. The 6th digit of the descriptor
> encoded the channel number on the printer carriage control tape,
> where was no-paper-motion, 1 was advance to head of page, then
> channels 2-11 on the tape, end of page, single and double space.
>
> Waiting for completion was a simple loop waiting for a bit to
> be set in a channel specific area of low memory (a 4 digit
> result descriptor that encoded completion status and error
> conditions).
>
> Hardware in production from 1966 through 2012.

But you're leaving out the printer - it had to be
designed especially to DEAL with the bitstream
your "one instruction" sent out, know what it
meant and what to do with it. In short, a bunch
of downstream electromechanical "program instructions".

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.

For a time I did a lot with those little PIC
micro-controllers. Those were RISC. Might take
ten instructions to accomplish the same thing a
single CISC instruction might do. No hiding the
steps. The advantages were, to some extent speed
(single-clock instructions) but also the processor
design could be MUCH simpler so the things could
sell for two bucks instead of 200. Also deliver
more computing-per-watt-consumed.

Observe a "Rube Goldberg" machine in action and ask if
the "one instruction", perhaps the Early Bird pulling
at a worm, causes the eggs and toast to be prepared and
delivered at the end. IMHO, each of the carefully-
arranged downstream components were "program instructions".

My view may be a little more "All is one and one is All"
than commonly used - but DO think on it for awhile. I'm
not out to troll or enrage or declare anyone to be an
idiot or enemy ... just offering a slightly bigger picture
of a common term to ponder.
Re: COBOL and tricks [message #415773 is a reply to message #415762] Sat, 30 July 2022 21:07 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/30/22 11:04 AM, Scott Lurndal wrote:
> "25B.Z959" <25B.Z959@nada.net> writes:
>> On 7/29/22 8:13 AM, Dan Espen wrote:
>
>>> I have no idea what you are trying to say.
>>>
>>> A high level abstraction to read a card?
>>
>>
>> Hell YES !!!
>>
>> Do you think the CPU knows what a "card" or "card
>> reader" is ?
>
> No, it doesn't care.


It just causes a little metal pin to be source
or drain at seemingly random intervals.

The OTHER instructions have to be downstream, in
the custom-crafted DEVICE - electro-(mechanical)
"instructions".


>> The CPU, given the instruction, would send a byte-stream.
>
> The CPU, given the instruction, sends a set of signals to the
> I/O subsystem which reach the device controller.


But you don't ACCOUNT for all that downstream logical
design :-)

And the "single instruction" sets a whole BUNCH of
sub-instructions in motion, fetching/organizing/
moving stuff in memory.

CISC -vs- RISC. With RISC you can't hide all that
downstream computing.

>> However you had to have another "computer" attached that
>
> No, the simple logic circuits to decode and route the signals
> sent from the CPU are not a "computer" using any definition of
> the word.

I'd say they ARE - merely more "special purpose" than
the average CPU. Yer CPU is just a conglam of very
similar circuits.

> It is logic all the way down.

Yep. Which is why I say the "single instruction" print
is a deception.

Not out to lecture or make people mad - just offering
a somewhat larger picture. Programming is mechanics,
arranging better gears and cogs. There's very little
you can do with electronics you can't also do with
'plumbing'. I've thought about it ... a hydraulic CPU
would indeed be possible. Rather huge and slow, but
possible.

So I guess we're all plumbers - Call Me MARIO ! :-)

Actually, I think plumbers get more $$$/hr than most
programmers/system-designers these days ......
Re: COBOL and tricks [message #415778 is a reply to message #415625] Sun, 31 July 2022 09:38 Go to previous messageGo to next message
Niklas Karlsson is currently offline  Niklas Karlsson
Messages: 265
Registered: January 2012
Karma: 0
Senior Member
On 2022-07-26, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Tue, 26 Jul 2022 21:52:32 +0100
> Vir Campestris <vir.campestris@invalid.invalid> wrote:
>
>> On 25/07/2022 21:55, Peter Flass wrote:
>>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>>> try to figure out what the heck you were trying to do. The more
>>> “concise” a language is, the more write-only it tends to be.
>>
>> Ah, you've seen APL then?
>
> The most unreadable language yet has to be whitespace:
>
> https://en.wikipedia.org/wiki/Whitespace_(programming_language)

Personally I favour ETA (no, not the JVM-based one).

http://www.miketaylor.org.uk/tech/eta/doc/manual.html#7.2

Niklas
--
Just because you *can* write a Java Virtual Machine in INTERCAL, that
doesn't mean you *should*.
-- David Cameron Staples makes the Understatement of the Year in asr
Re: COBOL and tricks [message #415786 is a reply to message #415773] Sun, 31 July 2022 13:55 Go to previous messageGo to next message
D.J. is currently offline  D.J.
Messages: 821
Registered: January 2012
Karma: 0
Senior Member
On Sat, 30 Jul 2022 21:07:39 -0400, "25B.Z959" <25B.Z959@nada.net>
wrote:
> On 7/30/22 11:04 AM, Scott Lurndal wrote:
>> "25B.Z959" <25B.Z959@nada.net> writes:
>>> On 7/29/22 8:13 AM, Dan Espen wrote:
>>
>>>> I have no idea what you are trying to say.
>>>>
>>>> A high level abstraction to read a card?
>>>
>>>
>>> Hell YES !!!
>>>
>>> Do you think the CPU knows what a "card" or "card
>>> reader" is ?
>>
>> No, it doesn't care.
>
>
> It just causes a little metal pin to be source
> or drain at seemingly random intervals.
>
> The OTHER instructions have to be downstream, in
> the custom-crafted DEVICE - electro-(mechanical)
> "instructions".
>
>
>>> The CPU, given the instruction, would send a byte-stream.
>>
>> The CPU, given the instruction, sends a set of signals to the
>> I/O subsystem which reach the device controller.
>
>
> But you don't ACCOUNT for all that downstream logical
> design :-)
>
> And the "single instruction" sets a whole BUNCH of
> sub-instructions in motion, fetching/organizing/
> moving stuff in memory.
>
> CISC -vs- RISC. With RISC you can't hide all that
> downstream computing.
>
>>> However you had to have another "computer" attached that
>>
>> No, the simple logic circuits to decode and route the signals
>> sent from the CPU are not a "computer" using any definition of
>> the word.
>
> I'd say they ARE - merely more "special purpose" than
> the average CPU. Yer CPU is just a conglam of very
> similar circuits.
>
>> It is logic all the way down.
>
> Yep. Which is why I say the "single instruction" print
> is a deception.
>
> Not out to lecture or make people mad - just offering
> a somewhat larger picture. Programming is mechanics,
> arranging better gears and cogs. There's very little
> you can do with electronics you can't also do with
> 'plumbing'. I've thought about it ... a hydraulic CPU
> would indeed be possible. Rather huge and slow, but
> possible.
>
> So I guess we're all plumbers - Call Me MARIO ! :-)
>
> Actually, I think plumbers get more $$$/hr than most
> programmers/system-designers these days ......

I have seen, occasionally, a hydro computer. Looked like simple logic
to me.. NAND, NOR, AND, etc. gates. Probably something online
somewhere. IIRC, they used water to operate the switches.

--
Jim
Re: COBOL and tricks [message #415793 is a reply to message #415786] Sun, 31 July 2022 14:32 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Sun, 31 Jul 2022 12:55:04 -0500
D.J. <chucktheouch@gmail.com> wrote:

> I have seen, occasionally, a hydro computer. Looked like simple logic
> to me.. NAND, NOR, AND, etc. gates. Probably something online
> somewhere. IIRC, they used water to operate the switches.

Moniac perhaps ? Made to model the British economy.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Re: COBOL and tricks [message #415794 is a reply to message #415793] Sun, 31 July 2022 15:13 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Lew Pitcher

On Sun, 31 Jul 2022 19:32:39 +0100, Ahem A Rivet's Shot wrote:

> On Sun, 31 Jul 2022 12:55:04 -0500
> D.J. <chucktheouch@gmail.com> wrote:
>
>> I have seen, occasionally, a hydro computer. Looked like simple logic
>> to me.. NAND, NOR, AND, etc. gates. Probably something online
>> somewhere. IIRC, they used water to operate the switches.
>
> Moniac perhaps ? Made to model the British economy.

See "Fluidics" (https://en.wikipedia.org/wiki/Fluidics)
as an example of logic gates that use water (or other media
that act as a fluid)


--
Lew Pitcher
"In Skills, We Trust"
Re: COBOL and tricks [message #415795 is a reply to message #415793] Sun, 31 July 2022 15:17 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: maus

On 2022-07-31, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Sun, 31 Jul 2022 12:55:04 -0500
> D.J. <chucktheouch@gmail.com> wrote:
>
>> I have seen, occasionally, a hydro computer. Looked like simple logic
>> to me.. NAND, NOR, AND, etc. gates. Probably something online
>> somewhere. IIRC, they used water to operate the switches.
>
> Moniac perhaps ? Made to model the British economy.
>
as i remember it too. Perhaps it could be remade to help Mrs. Truss t
truss up the british economy

--
greymausg@mail.org
Fi Fi Fo Fum, I smell the stench of an influencer
ten, twenty million tops
Re: COBOL and tricks [message #415801 is a reply to message #415625] Sun, 31 July 2022 16:27 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Vir Campestris

On 26/07/2022 22:26, Ahem A Rivet's Shot wrote:
> On Tue, 26 Jul 2022 21:52:32 +0100
> Vir Campestris <vir.campestris@invalid.invalid> wrote:
>
>> On 25/07/2022 21:55, Peter Flass wrote:
>>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>>> try to figure out what the heck you were trying to do. The more
>>> “concise” a language is, the more write-only it tends to be.
>>
>> Ah, you've seen APL then?
>
> The most unreadable language yet has to be whitespace:
>
> https://en.wikipedia.org/wiki/Whitespace_(programming_language)
>
I think Whitespace was intended as a joke. APL wasn't. I met APL from
reading a scientific paper that contained a large APL program. It wasn't
correct.

See <https://en.wikipedia.org/wiki/APL_(programming_language)#Game_of_Life>

If it survives formatting/charsets etc the line in question is

life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}

Andy
Re: COBOL and tricks [message #415806 is a reply to message #415773] Sun, 31 July 2022 16:45 Go to previous messageGo to next message
Rich Alderson is currently offline  Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
Senior Member
"25B.Z959" <25B.Z959@nada.net> writes:

> And the "single instruction" sets a whole BUNCH of
> sub-instructions in motion, fetching/organizing/
> moving stuff in memory.

Others have tried to explain this to you, but you don't want to listen.

On the 1401, there were 3 areas of memory dedicated to card and print I/O.

A READ instruction caused a single card to be input through the 1402 read/punch
and the data values from the columns of the card to be placed into locations
1 through 80. I don't care if you want to faff around and think of the
electromechanical and electronic manipulations going on as "programming"; they
were not available to the actual code-writing programmer, who simply issued the
READ instruction in her program.

A PUNCH instruction caused the contents of locations 101 through 180 to be sent
to the punch side of the 1402, with electronic and electromechanical
manipulations to turn the internal six-bit BCD data into Hollerith codes on
cards. None of those are available to the programmer.

A PRINT instruction caused the contents of locations 201 through 332 to be sent
to the 1403 printer, again with electronic and electromechanical manipulations
of the BCD data to cause appropriate hammers to strike appropriate slugs on the
print train as required. None of those are available to the programmer.

And note that those locations are not changeable. The programmer cannot write
code to print from locations 1269 through 1401 directly; if the desired output
is located there, a MOVE instruction addressing locations 1401 as source and
332 as destination is required, after a SET WOR MARK instruction referencing
location 1269 to that the MOVE will know where to stop.

IT IS ALL HARDWARE LOGIC. Your insistence on calling hardware "programming" is
simply silly.

Just stop.

--
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
Re: COBOL and tricks [message #415807 is a reply to message #415772] Sun, 31 July 2022 16:51 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Vir Campestris

On 31/07/2022 01:35, 25B.Z959 wrote:
>   My view may be a little more "All is one and one is All"
>   than commonly used - but DO think on it for awhile. I'm
>   not out to troll or enrage or declare anyone to be an
>   idiot or enemy ... just offering a slightly bigger picture
>   of a common term to ponder.

Let me offer a (slightly) more recent example.

In some of the IBM PC graphics modes there is a buffer available to the CPU.

Separate graphics hardware reads the ASCII out of the buffer and turns
it to pixels on the screen. This runs continuously; the buffer is read
each time the screen is refreshed.

In order to write a character onto the screen all the program needs to
do is to write an ASCII character into the buffer.

Many early games did that themselves without any intervening device
driver. For speed.

Andy
Re: COBOL and tricks [message #415809 is a reply to message #415772] Sun, 31 July 2022 17:26 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
"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.
Re: COBOL and tricks [message #415814 is a reply to message #415801] Sun, 31 July 2022 21:05 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Vir Campestris <vir.campestris@invalid.invalid> wrote:
> On 26/07/2022 22:26, Ahem A Rivet's Shot wrote:
>> On Tue, 26 Jul 2022 21:52:32 +0100
>> Vir Campestris <vir.campestris@invalid.invalid> wrote:
>>
>>> On 25/07/2022 21:55, Peter Flass wrote:
>>>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>>>> try to figure out what the heck you were trying to do. The more
>>>> “concise” a language is, the more write-only it tends to be.
>>>
>>> Ah, you've seen APL then?
>>
>> The most unreadable language yet has to be whitespace:
>>
>> https://en.wikipedia.org/wiki/Whitespace_(programming_language)
>>
> I think Whitespace was intended as a joke. APL wasn't. I met APL from
> reading a scientific paper that contained a large APL program. It wasn't
> correct.
>
> See <https://en.wikipedia.org/wiki/APL_(programming_language)#Game_of_Life>
>
> If it survives formatting/charsets etc the line in question is
>
> life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}
>
> Andy
>

I think Lynne might weigh in on this, but I believe APL was used to define
S/360 architecture.

--
Pete
Re: COBOL and tricks [message #415815 is a reply to message #415801] Sun, 31 July 2022 21:54 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/31/22 4:27 PM, Vir Campestris wrote:
> On 26/07/2022 22:26, Ahem A Rivet's Shot wrote:
>> On Tue, 26 Jul 2022 21:52:32 +0100
>> Vir Campestris <vir.campestris@invalid.invalid> wrote:
>>
>>> On 25/07/2022 21:55, Peter Flass wrote:
>>>> No, COBOL is for the NEXT  poor bastard who has to look at your code
>>>> and
>>>> try to figure out what the heck you were trying to do. The more
>>>> “concise” a language is, the more write-only it tends to be.
>>>
>>> Ah, you've seen APL then?
>>
>>     The most unreadable language yet has to be whitespace:
>>
>> https://en.wikipedia.org/wiki/Whitespace_(programming_language)
>>
> I think Whitespace was intended as a joke. APL wasn't. I met APL from
> reading a scientific paper that contained a large APL program. It wasn't
> correct.
>
> See <https://en.wikipedia.org/wiki/APL_(programming_language)#Game_of_Life>
>
> If it survives formatting/charsets etc the line in question is
>
> life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}


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

FORTH is more transparent (and I did use it for a
few projects back in the tiny/slow CPU days).
A FORTH interpreter is TIGHT, not much else comes
close.

I hope nobody actually tried to train their kiddies
how to program using APL - they probably majored
in basket-weaving and finger-painting later in life :-)
Re: COBOL and tricks [message #415816 is a reply to message #415814] Sun, 31 July 2022 22:05 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
It appears that Peter Flass <peter_flass@yahoo.com> said:
> I think Lynn might weigh in on this, but I believe APL was used to define
> S/360 architecture.

The 1964 issue of the IBM Systems Journal which was all about S/360
included a description of the architecture in a version of APL.

Shortly after that the started turning APL from a paper lanaguage into
one that could run on a computer.

--
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
Re: COBOL and tricks [message #415818 is a reply to message #415661] Sun, 31 July 2022 22:35 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/27/22 2:10 PM, Charlie Gibbs wrote:
> On 2022-07-27, 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> On 7/26/22 4:53 PM, Vir Campestris wrote:
>>
>>> The useful comments don't say _what_ you're doing, they say _why_.
>>
>> 'Zactly ... it needs to be a 'narrative' - both WHAT and WHY.
>> Doesn't matter if it's ASM or COBOL or FORTRAN or Python. If
>> you or anybody would EVER need to go back and tweak the pgm
>> it really NEEDS serious commenting. Alas it's kinda RARE to
>> see this ..... the old "Well *I* know what it's all about NOW"
>> attitude. Wait a couple years until the boss decides your form
>> needs some new data fields or entry box #7 moved 10 spaces to
>> the right 'cause it would 'look nicer' .... :-)
>
> Don't laugh. Once upon a time, every shop in Canada that ran payroll
> had to modify their programs that generated T4 forms (Statement of
> Remuneration Paid) because someone in Ottawa decided to move one
> box one space to the right.

I can believe it ... pointy-haired bosses outnumber the
sensible bosses ten to one IMHO :-)

I'd once spent months writing code/functions/subs/structure
for a database and then one of the directors wanted to make
ONE LITTLE CHANGE. I spent an hour arguing how we'd have
to throw away months of code built on the current paradigm
just because of that. Fortunately I was still young and
strong and could quickly diagram-out WHY that was so.

In THAT case it worked out. the guy WAS a nerd - even
hand-wired one of the shops old PCs, an LSI-11 jobbie with
8" floppies (my very first job was to get all the data OFF
that and INTO the new-fangled IBM-PCs - a serial port wiring
rats-nest ... have a (chemical) photo of that somewhere) so
HE could understand and be persuaded. But MOST bosses, they'll
have it whatever way their latest brainfart takes them no
matter HOW big a disaster. That old adage about "rise to their
level of incompetence" really seems true.

One of the newer bosses decided that Unix/Linux was evil
and MicroSoft was the "standard", the Holy Grail - didn't
know anything about computing beyond the buzz-shit read in
management mags. I left it so there WAS still some -x .. but
hidden well enough they'd never notice it (not that they'd
know it if they saw it, not even a FreeBSD VM).

> The hairiest change I was involved in, though, was when the government
> decided to turn the form upside down, i.e. put the row of numbers
> across the top rather than the bottom. (Or maybe it was the other way
> around, I can't remember.) I was maintaining the program in a shop
> whose card-based machine's memory was so small that it didn't have
> room to store all of an employee's information. It would read the
> card containing the employee's name, print it out, then work its
> way through the cards with the employee's address, city, etc.
> Finally it would read the card with the actual numbers and
> print them. The card deck was sorted by employee number and
> a sequence code that ensured that name, address, and statistics
> were in the proper order. Not only did I have to overhaul the
> program's logic to handle the different sequence, the entire
> card deck had to be re-punched (and re-sorted) with the modified
> sequence code.

AAAAAUUUUGGGGGHHHHHH !

> There has to be a better way to fight unemployment...

Yea ... "Small Shop".

Better to be the big fish in the smaller pond - you'll
keep your sanity and be able to Do It Right. You may
even have FUN !

I learned this very early on - a few years behind the
poor bastards in the white shirts and narrow ties. Saw
their unspeakable fates. After that I never "worked"
another day in my life.

Observing unspeakable fates is why I never got married
either ... amazing how much money you can save, and
arteriosclerosis you can escape, taking that path :-)
Re: COBOL and tricks [message #415819 is a reply to message #415696] Sun, 31 July 2022 22:40 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/28/22 1:11 PM, Ahem A Rivet's Shot wrote:
> On Thu, 28 Jul 2022 15:10:25 +0100
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> What isn't efficient is low source code byte count achieved by removing
>> the comments
>
> It is in interpreted code!

Meaning "Without a Rosetta Stone" it's .... :-)
Re: COBOL and tricks [message #415822 is a reply to message #415744] Sun, 31 July 2022 23:23 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

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.

Ya know what WILL last 100+ years ? Those notebooks
full of the wide-format 8-pin printed fanfold paper :-)

But in 100 years it'll all be "AI" - and unverifiable/
incomprehensible q-logic the AIs dream up . "Procedural"
code will be like junk etched onto clay tablets and
the only things that "talk" about "programming" will
be the chatter between the AIs.

Some of those old sci-fi writers DID get it right - where
tech soon exceeds common, and eventually "expert", human
comprehension and becomes naught but "magic" - until
something blows a fuse, so to speak :-)
Re: COBOL and tricks [message #415823 is a reply to message #415723] Sun, 31 July 2022 23:47 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/29/22 11:54 AM, Scott Lurndal wrote:
> "25B.Z959" <25B.Z959@nada.net> writes:
>> On 7/28/22 9:02 AM, Scott Lurndal wrote:
>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>> On 7/25/22 7:37 AM, Johnny Billquist wrote:
>>>
>>>> Consider "print x" ... those of us that go back some years
>>>> will acutely recognize how "print x" stands atop a veritable
>>>> Everest of subroutines, device abstractors, drivers for
>>>> display controllers .........
>>>>
>>>> CPUs don't *have* a "print x".
>>>
>>> Arguable. e.g. the intel OUT instruction can easily print 'x',
>>> and REP OUT can print an entire string.
>>
>>
>> ONLY if it has something to print TO ... and THAT
>> requires a whole chain of device drivers/devices.
>
> No, it does not. Please do some reading and understand
> what the IN and OUT instructions actually do.

They cause seemingly random voltage fluctuations on a
little metal pin.

Which requires rather a lot of dedicated downstream
hardware/firmware/electro-mechanics to make any
sense of. Yer big hard-disk pak machine was a full
computer in and of itself ... "IN" was just a
simple command to set all that logic in motion.

*I* count the downstream stuff. Others may not.

The old Big Iron could do a lot with a few instructions,
but those instructions relied on big expensive "smart"
peripherals (usually with the same BrandName/Series#
printed on them).

If you Google "eggs" - is that one instruction ? No !
It sets gigantic cluster-computers and routers and
huge banks of smart storage devices around the world
into motion. The "one instruction" is a lie. Maybe
it's just my age, but I *do* see what's behind the
"one instruction" whereas most these days just see
it as some kind of magic they never need/dare think
about.

But SOMEBODY needs to think about it ....

Ah ... time for WestWorld .......... :-)
Re: COBOL and tricks [message #415824 is a reply to message #415806] Mon, 01 August 2022 00:38 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/31/22 4:45 PM, Rich Alderson wrote:
> "25B.Z959" <25B.Z959@nada.net> writes:
>
>> And the "single instruction" sets a whole BUNCH of
>> sub-instructions in motion, fetching/organizing/
>> moving stuff in memory.
>
> Others have tried to explain this to you, but you don't want to listen.
>
> On the 1401, there were 3 areas of memory dedicated to card and print I/O.
>
> A READ instruction caused a single card to be input through the 1402 read/punch
> and the data values from the columns of the card to be placed into locations
> 1 through 80. I don't care if you want to faff around and think of the
> electromechanical and electronic manipulations going on as "programming"; they
> were not available to the actual code-writing programmer, who simply issued the
> READ instruction in her program.
>
> A PUNCH instruction caused the contents of locations 101 through 180 to be sent
> to the punch side of the 1402, with electronic and electromechanical
> manipulations to turn the internal six-bit BCD data into Hollerith codes on
> cards. None of those are available to the programmer.
>
> A PRINT instruction caused the contents of locations 201 through 332 to be sent
> to the 1403 printer, again with electronic and electromechanical manipulations
> of the BCD data to cause appropriate hammers to strike appropriate slugs on the
> print train as required. None of those are available to the programmer.
>
> And note that those locations are not changeable. The programmer cannot write
> code to print from locations 1269 through 1401 directly; if the desired output
> is located there, a MOVE instruction addressing locations 1401 as source and
> 332 as destination is required, after a SET WOR MARK instruction referencing
> location 1269 to that the MOVE will know where to stop.
>
> IT IS ALL HARDWARE LOGIC. Your insistence on calling hardware "programming" is
> simply silly.
>
> Just stop.


But it's the *correct* viewpoint, it IS "programming",
creating a predictable, useful, train of events through
carefully (soldered) logical design - and it's often
more complex, more nuanced, programming than anything
you'd find on your Big Iron :-)

Go tell the hardware people they're not "programmers" ...
they'll whip you to death with ribbon cable ... and
"IN"/"OUT" won't DO anything anymore .....

Hell, your precious CPU is a MASSIVE exercise in
"programming in Solder" .....

I've done BOTH sides of this equation - I see it as
"All Is One and One Is All" - top to bottom, bottom
to top ... it's all 'computing'/'programming'. I often
wound up doing "special projects" that involved not only
programming cpu's/mpu's but also designing/building the
peripheral hardware involved. Nothing huge, but still
very educational. There's no dividing line.

Not trying to make anyone mad or brand them as idiots/enemies
(like one or two are fond of) - I just want you to THINK
about the Big Picture. So few do these days, it's become
too compartmentalized/specialized. Wasn't always. You
could still see to the horizon.
Re: COBOL and tricks [message #415826 is a reply to message #415806] Mon, 01 August 2022 03:19 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
Senior Member
On 31/07/2022 21:45, Rich Alderson wrote:
> IT IS ALL HARDWARE LOGIC. Your insistence on calling hardware "programming" is
> simply silly.
>
> Just stop.
Did you know that a hardware instruction to most CISC CPU chips is in
fact interpreted by an interpreter written in microcode?
The line between hardware and software is, and always has been, very
blurred.

--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.
Re: COBOL and tricks [message #415827 is a reply to message #415824] Mon, 01 August 2022 03:09 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Mon, 1 Aug 2022 00:38:37 -0400
"25B.Z959" <25B.Z959@nada.net> wrote:

> But it's the *correct* viewpoint, it IS "programming",
> creating a predictable, useful, train of events through
> carefully (soldered) logical design

Yes there are similarities between the design of electronic
hardware, the design of software, the design of mechanical systems and so
forth but similarities do not make them the same thing. We have words to
distinguish them because although they are all branches of *engineering*
and thus embody common principles they are different disciplines no matter
how similar. It is a mistake to conflate similar things instead of
recognising both the similarities and the differences.

Now STFU about it and say something interesting please.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Re: COBOL and tricks [message #415829 is a reply to message #415827] Mon, 01 August 2022 06:02 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
Senior Member
On 01/08/2022 08:09, Ahem A Rivet's Shot wrote:
> On Mon, 1 Aug 2022 00:38:37 -0400
> "25B.Z959" <25B.Z959@nada.net> wrote:
>
>> But it's the *correct* viewpoint, it IS "programming",
>> creating a predictable, useful, train of events through
>> carefully (soldered) logical design
>
> Yes there are similarities between the design of electronic
> hardware, the design of software, the design of mechanical systems and so
> forth but similarities do not make them the same thing. We have words to
> distinguish them because although they are all branches of *engineering*
> and thus embody common principles they are different disciplines no matter
> how similar. It is a mistake to conflate similar things instead of
> recognising both the similarities and the differences.
>
> Now STFU about it and say something interesting please.
>
The point at which hardware becomes firmware, is very moot.

When programming a ULA, is that software, or hardware?

The problem with abstract concepts like hardware and software is that
they seldom map exactly to the real world
The map, is not the territory.


--
"The great thing about Glasgow is that if there's a nuclear attack it'll
look exactly the same afterwards."

Billy Connolly
Re: COBOL and tricks [message #415832 is a reply to message #415829] Mon, 01 August 2022 07:02 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Mon, 1 Aug 2022 11:02:12 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> The point at which hardware becomes firmware, is very moot.

Not really. Hardware you have to build. The firmware gets written.

> When programming a ULA, is that software, or hardware?

The gates etc. are hardware. The connection map is firmware if in
ROM, software if in RAM (I'm not aware of any examples this is just for
completeness).

A good demonstration of this would be the researcher at (IIRC
Exeter) who used genetic algorithms starting with random data to evolve
circuitry on ULAs. One result was a frequency discriminator in under 100
gates, some of which were not connected to any signal path but were
required for the thing to work. I don't think that one was ever fully
understood - there certainly wasn't any kind of clock.

There's no useful distinguishing word between write once firmware
and rewritable firmware which is a shame.

> The problem with abstract concepts like hardware and software is that
> they seldom map exactly to the real world

But in this case they do, very well.

Hard: Built, implemented in matter.
Firm: Written may be write once or changeable with some difficulty.
Soft: Written, easily changeable.

There is a continuum between firm and soft but not between hard and
firm. Software and Firmware are patterns, hardware is things.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Re: COBOL and tricks [message #415833 is a reply to message #415826] Mon, 01 August 2022 10:00 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
The Natural Philosopher <tnp@invalid.invalid> writes:
> On 31/07/2022 21:45, Rich Alderson wrote:
>> IT IS ALL HARDWARE LOGIC. Your insistence on calling hardware "programming" is
>> simply silly.
>>
>> Just stop.
> Did you know that a hardware instruction to most CISC CPU chips is in
> fact interpreted by an interpreter written in microcode?

As an adjunct to a bunch of chip designers, I find your characterization incorrect.

While it is true for a small number of more complicated CISC-y instructions
on Intel CPUs, it's not true for the vast majority of instructions on
Intel CPUs and it is not true at all for most 64-bit ARM cpus (I'm looking at the
RTL right now for a very large 64-bit ARM cpu, performance competitive with
an Intel/AMD CPU - no microcode at all).
Re: COBOL and tricks [message #415835 is a reply to message #415822] Mon, 01 August 2022 10:45 Go to previous messageGo to next message
D.J. is currently offline  D.J.
Messages: 821
Registered: January 2012
Karma: 0
Senior Member
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.

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
Re: COBOL and tricks [message #415836 is a reply to message #415806] Mon, 01 August 2022 10:46 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Lew Pitcher

On Sun, 31 Jul 2022 16:45:08 -0400, Rich Alderson wrote:

> "25B.Z959" <25B.Z959@nada.net> writes:
>
>> And the "single instruction" sets a whole BUNCH of
>> sub-instructions in motion, fetching/organizing/
>> moving stuff in memory.
[snip]
> IT IS ALL HARDWARE LOGIC. Your insistence on calling hardware "programming" is
> simply silly.

I agree that hardware design is not normally considered "programming".

But, there is a class of "programming" that has nothing to do with
programming languages, or Boolean logic, or software, but concentrates
entirely on "hardware'.

Consider the simple Jacquard loom, where fabric weaving patterns are
"programmed" on cards "read" by the loom. These cards do not, in any way,
constitute "programming" as is referred to by our contemporaries, but still
are referred to as a "program" for the loom.

Or, how about the process of modifying a blank FPGA into a device that
performs useful work. This process, using such languages as VHDL and
Verilog, is referred to as "programming", and the generated logic
templates are referred to as "programs", but, again, these terms refer
to things that form /hardware/, and not software.


--
Lew Pitcher
"In Skills, We Trust"
Re: COBOL and tricks [message #415837 is a reply to message #415835] Mon, 01 August 2022 10:50 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Lew Pitcher

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.

--
Lew Pitcher
"In Skills, We Trust"
Re: COBOL and tricks [message #415838 is a reply to message #415837] Mon, 01 August 2022 10:51 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Lew Pitcher

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.




--
Lew Pitcher
"In Skills, We Trust"
Re: COBOL and tricks [message #415845 is a reply to message #415835] Mon, 01 August 2022 11:08 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: maus

On 2022-08-01, D.J <chucktheouch@gmail.com> 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:
>
> 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
the disk drive for Amstrad computers was an odd size, I forget what.

--
greymausg@mail.org
Fi Fi Fo Fum, I smell the stench of an influencer
ten, twenty million tops
Re: COBOL and tricks [message #415846 is a reply to message #415837] Mon, 01 August 2022 11:40 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
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.

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.
Re: COBOL and tricks [message #415847 is a reply to message #415845] Mon, 01 August 2022 12:31 Go to previous messageGo to next message
Harry Vaderchi is currently offline  Harry Vaderchi
Messages: 719
Registered: July 2012
Karma: 0
Senior Member
On 1 Aug 2022 15:08:33 GMT
maus <maus@dmaus.org> wrote:

> On 2022-08-01, D.J <chucktheouch@gmail.com> 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:
>>
>> 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
> the disk drive for Amstrad computers was an odd size, I forget what.
>
3 inch. Amstrad Z80-based home computers CPC 464, 6128

https://en.wikipedia.org/wiki/Amstrad_CPC

I had^w my attic still has one!

--
Bah, and indeed Humbug.
Re: COBOL and tricks [message #415848 is a reply to message #415832] Mon, 01 August 2022 12:35 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
Senior Member
On 01/08/2022 12:02, Ahem A Rivet's Shot wrote:
> On Mon, 1 Aug 2022 11:02:12 +0100
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> The point at which hardware becomes firmware, is very moot.
>
> Not really. Hardware you have to build. The firmware gets written.
>
>> When programming a ULA, is that software, or hardware?
>
> The gates etc. are hardware. The connection map is firmware if in
> ROM, software if in RAM (I'm not aware of any examples this is just for
> completeness).
>
> A good demonstration of this would be the researcher at (IIRC
> Exeter) who used genetic algorithms starting with random data to evolve
> circuitry on ULAs. One result was a frequency discriminator in under 100
> gates, some of which were not connected to any signal path but were
> required for the thing to work. I don't think that one was ever fully
> understood - there certainly wasn't any kind of clock.
>
> There's no useful distinguishing word between write once firmware
> and rewritable firmware which is a shame.
>
>> The problem with abstract concepts like hardware and software is that
>> they seldom map exactly to the real world
>
> But in this case they do, very well.
>
> Hard: Built, implemented in matter.
> Firm: Written may be write once or changeable with some difficulty.
> Soft: Written, easily changeable.
>
> There is a continuum between firm and soft but not between hard and
> firm. Software and Firmware are patterns, hardware is things.
>

So microcode inst "hardware" then, although its bought as part of the
processor

And hooking up a UART isn't hardware, since it has to be "programmed".

--
“Progress is precisely that which rules and regulations did not foresee,”

– Ludwig von Mises
Re: COBOL and tricks [message #415849 is a reply to message #415847] Mon, 01 August 2022 13:05 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: maus

On 2022-08-01, Kerr-Mudd, John <admin@127.0.0.1> wrote:
> On 1 Aug 2022 15:08:33 GMT
> maus <maus@dmaus.org> wrote:
>
>> On 2022-08-01, D.J <chucktheouch@gmail.com> 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:
>>>
>>> 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
>> the disk drive for Amstrad computers was an odd size, I forget what.
>>
> 3 inch. Amstrad Z80-based home computers CPC 464, 6128
>
> https://en.wikipedia.org/wiki/Amstrad_CPC
>
> I had^w my attic still has one!
>
In my humble opinion and that that of my repair man, one of the best
computers ever made.


--
greymausg@mail.org
Fi Fi Fo Fum, I smell the stench of an influencer
ten, twenty million tops
Re: COBOL and tricks [message #415850 is a reply to message #415848] Mon, 01 August 2022 14:06 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
The Natural Philosopher <tnp@invalid.invalid> writes:
> On 01/08/2022 12:02, Ahem A Rivet's Shot wrote:
>> On Mon, 1 Aug 2022 11:02:12 +0100
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>
>>> The point at which hardware becomes firmware, is very moot.
>>
>> Not really. Hardware you have to build. The firmware gets written.
>>
>>> When programming a ULA, is that software, or hardware?
>>
>> The gates etc. are hardware. The connection map is firmware if in
>> ROM, software if in RAM (I'm not aware of any examples this is just for
>> completeness).
>>
>> A good demonstration of this would be the researcher at (IIRC
>> Exeter) who used genetic algorithms starting with random data to evolve
>> circuitry on ULAs. One result was a frequency discriminator in under 100
>> gates, some of which were not connected to any signal path but were
>> required for the thing to work. I don't think that one was ever fully
>> understood - there certainly wasn't any kind of clock.
>>
>> There's no useful distinguishing word between write once firmware
>> and rewritable firmware which is a shame.
>>
>>> The problem with abstract concepts like hardware and software is that
>>> they seldom map exactly to the real world
>>
>> But in this case they do, very well.
>>
>> Hard: Built, implemented in matter.
>> Firm: Written may be write once or changeable with some difficulty.
>> Soft: Written, easily changeable.
>>
>> There is a continuum between firm and soft but not between hard and
>> firm. Software and Firmware are patterns, hardware is things.
>>
>
> So microcode inst "hardware" then, although its bought as part of the
> processor

A lot of microcode, in the day, was simply a table of VLIW (80 to hundreds
of bits wide) entries, where each bit in the VLIW drove signals
throughout the rest of the processor, including selector bits for the next
VLIW instruction to execute. Often loaded via scan chains from floppy
by the maintenance processor when the host was powered on.
Re: COBOL and tricks [message #415851 is a reply to message #415837] Mon, 01 August 2022 14:15 Go to previous messageGo to next message
Dan Espen is currently offline  Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
Senior Member
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.

That "370-30" would have been a 370/135 or some other 3 digit model
number.

Probably where I saw my first 8" floppy drive.


--
Dan Espen
Re: COBOL and tricks [message #415852 is a reply to message #415838] Mon, 01 August 2022 14:18 Go to previous messageGo to next message
Dan Espen is currently offline  Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
Senior Member
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

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

I don't believe a 360/30 had a floppy drive.

--
Dan Espen
Re: COBOL and tricks [message #415853 is a reply to message #415848] Mon, 01 August 2022 14:05 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Mon, 1 Aug 2022 17:35:28 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> So microcode inst "hardware" then, although its bought as part of the
> processor

Agreed, it is usually write once firmware there have been systems
with writable microcode.

> And hooking up a UART isn't hardware, since it has to be "programmed".

Not sure what you mean there, a UART is usually hardware with
control registers (the registers and the things they control are hardware
but the settings are not) OTOH if you were to implement a UART using the
GPIO pins of a Raspberry Pi or Ardiuno and code then that would be a
software implementation of a UART using the general purpose hardware. I
have done this, although it was on something much older than a Pi or
Arduino.

Oh yes - best distinction between software and firmware I can think
of. Firmware is guaranteed not to go away when the power is off.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Re: COBOL and tricks [message #415854 is a reply to message #415852] Mon, 01 August 2022 14:38 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Lew Pitcher

On Mon, 01 Aug 2022 14:18:42 -0400, Dan Espen wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>
>> 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.
>
> I don't believe a 360/30 had a floppy drive.

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

For a time, I wrote SCI code. Later, I maintained several different
mainframe cheque sorter applications ("Transit", CPCS, and DosCheck)
that ran these machines.


--
Lew Pitcher
"In Skills, We Trust"
Re: COBOL and tricks [message #415855 is a reply to message #415851] Mon, 01 August 2022 14:47 Go to previous messageGo to previous message
Harry Vaderchi is currently offline  Harry Vaderchi
Messages: 719
Registered: July 2012
Karma: 0
Senior Member
On Mon, 01 Aug 2022 14:15:18 -0400
Dan Espen <dan1espen@gmail.com> wrote:

> 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.
>
> That "370-30" would have been a 370/135 or some other 3 digit model
> number.
>
> Probably where I saw my first 8" floppy drive.
>
>
The cluster controllers I saw in the late 80's? were (occasionally) booted
from 8" floppys. We had some kind of upgrade that allowed better
screen editting.

Hah you try searching on cluster controllers these day!
but this is what I mean:
https://en.wikipedia.org/wiki/IBM_3270#3274_controller

Entry Assist I think was the new feature.

Then Multiple Logical Terminals - this was streets ahead of the old
single line editting days of 1980.

--
Bah, and indeed Humbug.
Pages (21): [ «    1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16    »]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: R.I.P. Terry Davis - TempleOS and Holy C
Next Topic: Satan's Digital Butthole - R.I.P. Mr. P.J. O'Rourke
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 08:57:05 EDT 2024

Total time taken to generate the page: 0.08919 seconds