020111 067544 023556 020164 062556 062145 067040 020157
072163 062545 065556 067151 020147 062550 060570 062544
064543 060555 020554 005012

--
Beauty and harmony are as necessary to you as the very breath of life.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sa 16 Nov 2024 at 00:01, "186282@ud0s4.net" <186283@ud0s4.net> wrote:

As for terminals, I liked the Textronics 4000
series a lot more. For text + simple graphs
vector really was faster/sharper than bitmap ...
at least back in the low-bandwidth day.

It is Tektronix you mean, not Textronics isn't it?

'Andreas
--
ceterum censeo redmondinem esse delendam

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/11/2024 14:14, Andreas Eder wrote:

On Sa 16 Nov 2024 at 00:01, "186282@ud0s4.net" <186283@ud0s4.net> wrote:

As for terminals, I liked the Textronics 4000
series a lot more. For text + simple graphs
vector really was faster/sharper than bitmap ...
at least back in the low-bandwidth day.

It is Tektronix you mean, not Textronics isn't it?

'Andreas

Phonetic spelling. USA's favorite pastime. Along with inventing
multisyllabic words.
Burglarize
Copacetic.

--
When plunder becomes a way of life for a group of men in a society, over
the course of time they create for themselves a legal system that
authorizes it and a moral code that glorifies it.

Frédéric Bastiat

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"186282@ud0s4.net" <186283@ud0s4.net> writes:

On 11/16/24 12:24 AM, rbowman wrote:

On Fri, 15 Nov 2024 23:31:26 -0500, 186282@ud0s4.net wrote:

Again, not entirely sure where the end of octal was. Many of the PDPs >>> used octal, and I *think* a few PIC chips. 8/16/32 kinda took over
kinda early on however.

chmod 4755
I don't know if I'd call it octal but if you were writing an
assembler for
quite a few microcontrollers the opcodes would have a pattern where source >> ans destination registers were 0 - 7,

Octal does persist, sometimes in obscure ways and places.
It WAS kinda big for awhile - a "big step" better than
8-bit.

Alas don't think anymore 12 or 24 bit CPUs are
gonna be made. Might still have a place for some
higher-end microcontrollers - hell, I think Epson
still makes FOUR-bit microcontrollers (looked at
the sheet for one once, insanely capable).

Hmmm ... 256 of those 4-bitters running
parallel - that'd be a fun project :-)

GE's "GECOS" and later Honeywell's "GCOS" mainframe machines were all
36-bit words, so octal was a natural for them: 6 6-bit BCD characters or
4 9-bit bytes per 36 bit word.

--
-Don_from_AZ-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 16 Nov 2024 03:20:33 -0500, 186282@ud0s4.net wrote:

Alas don't think anymore 12 or 24 bit CPUs are
gonna be made. Might still have a place for some higher-end
microcontrollers - hell, I think Epson still makes FOUR-bit
microcontrollers (looked at the sheet for one once, insanely
capable).

https://en.wikichip.org/w/images/2/25/
MARC4_User's_Guide_qFORTH_Compiler.pdf

I don't know when the MARC4 was dropped but it held on until this century.
You don't need an Arm M4 to run a coffee pot but 8-bit devices are dirt
cheap.

Hmmm ... 256 of those 4-bitters running parallel - that'd be a fun
project

That's dangerously close to reinventing bit-slice.

https://alchetron.com/Motorola-MC10800

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/16/24 9:38 AM, The Natural Philosopher wrote:

On 16/11/2024 14:14, Andreas Eder wrote:

On Sa 16 Nov 2024 at 00:01, "186282@ud0s4.net" <186283@ud0s4.net> wrote:

   As for terminals, I liked the Textronics 4000
   series a lot more. For text + simple graphs
   vector really was faster/sharper than bitmap ...
   at least back in the low-bandwidth day.

It is Tektronix you mean, not Textronics isn't it?

Yea, yea ... it's one of those words I *always*
mis-spell. Dunno why :-)

But they WERE really good terminals ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/16/24 11:16 AM, Don_from_AZ wrote:

"186282@ud0s4.net" <186283@ud0s4.net> writes:

On 11/16/24 12:24 AM, rbowman wrote:

On Fri, 15 Nov 2024 23:31:26 -0500, 186282@ud0s4.net wrote:

Again, not entirely sure where the end of octal was. Many of the PDPs >>>> used octal, and I *think* a few PIC chips. 8/16/32 kinda took over >>>> kinda early on however.

chmod 4755
I don't know if I'd call it octal but if you were writing an
assembler for
quite a few microcontrollers the opcodes would have a pattern where source >>> ans destination registers were 0 - 7,

Octal does persist, sometimes in obscure ways and places.
It WAS kinda big for awhile - a "big step" better than
8-bit.

Alas don't think anymore 12 or 24 bit CPUs are
gonna be made. Might still have a place for some
higher-end microcontrollers - hell, I think Epson
still makes FOUR-bit microcontrollers (looked at
the sheet for one once, insanely capable).

Hmmm ... 256 of those 4-bitters running
parallel - that'd be a fun project :-)

GE's "GECOS" and later Honeywell's "GCOS" mainframe machines were all
36-bit words, so octal was a natural for them: 6 6-bit BCD characters or
4 9-bit bytes per 36 bit word.

Yep ... 2^12 hung on for quite awhile.

And, in Linux/Unix, is STILL there in things like 'chmod'.

8/16/32/64 seems more 'natural' ... but that may
be more because of constant exposure than because
of practical function. You can make a CPU with
any word length you want.

Remember "bit-slice" CPUs ? Fabrication tech could
not make really wide single chips, so you just
wired a bunch of them parallel ... you could HAVE
yer 64-bit+ CPU even in the late 70s.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/16/24 1:14 PM, rbowman wrote:

On Sat, 16 Nov 2024 03:20:33 -0500, 186282@ud0s4.net wrote:

Alas don't think anymore 12 or 24 bit CPUs are
gonna be made. Might still have a place for some higher-end
microcontrollers - hell, I think Epson still makes FOUR-bit
microcontrollers (looked at the sheet for one once, insanely
capable).

https://en.wikichip.org/w/images/2/25/
MARC4_User's_Guide_qFORTH_Compiler.pdf

I don't know when the MARC4 was dropped but it held on until this century. You don't need an Arm M4 to run a coffee pot but 8-bit devices are dirt cheap.

Absolutely correct ! Four bits was more than enough for
remote controls, Mr. Coffee, microwaves, vending machines,
a whole spectrum of 'small devices'. The chips WERE
insanely capable, SO many ways you could set up the pins
to serve most any need. Kinda nano-power too.

Try :
https://global.epson.com/products_and_drivers/semicon/pdf/id002151.pdf

Don't see the 4-bitters in their recent product line, but
you can still buy 'em. Of course EVERYTHING now needs a
GUI type touch interface so .......

https://www.digikey.com/en/products/detail/epson/S1C17W04F101100/8593592

Remember buttons/switches that went "click !" ?

Hmmm ... 256 of those 4-bitters running parallel - that'd be a fun
project

That's dangerously close to reinventing bit-slice.

https://alchetron.com/Motorola-MC10800

Heh heh ... I mentioned bit-slice to somebody here, but
anyone born after 1965 has likely never heard of them :-)

But, it WOULD be an interesting experiment in intense
parallel 4-bit processing without going into NVidia and
such.

Periodically, people offer PI "motherboards" for up
to four of the plug-in CMs. They do feature channels
for inter-board comms. None for the PI5 yet.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Ames wrote this post while blinking in Morse code:

On Sat, 9 Nov 2024 09:36:58 -0500
Chris Ahlstrom <OFeem1987@teleworm.us> wrote:

020111 067544 023556 020164 062556 062145 067040 020157 072163 062545
065556 067151 020147 062550 060570 062544 064543 060555 020554 005012

041165 072040 073350 060564 020151 063040 074557 072447 071145 020167
071151 072151 067147 020146 071157 066400 060440 061151 063455 062556
062151 060556 020155 060543 064151 067145 027056 027077

Damn, I still haven't found a program that would easily reverse octal to a string.

--
Q: How many marketing people does it take to change a light bulb?
A: I'll have to get back to you on that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/11/2024 1:58 PM, Chris Ahlstrom wrote:

John Ames wrote this post while blinking in Morse code:

On Sat, 9 Nov 2024 09:36:58 -0500
Chris Ahlstrom <OFeem1987@teleworm.us> wrote:

020111 067544 023556 020164 062556 062145 067040 020157 072163 062545
065556 067151 020147 062550 060570 062544 064543 060555 020554 005012

041165 072040 073350 060564 020151 063040 074557 072447 071145 020167
071151 072151 067147 020146 071157 066400 060440 061151 063455 062556
062151 060556 020155 060543 064151 067145 027056 027077

Damn, I still haven't found a program that would easily reverse octal to a string.

This is crude, but it seems to work for the post you're replying to,
with big-endian two-byte integers:

===
#include <stdio.h>

int main(void)
{
    union {
        unsigned short s;
        char c[2];
    } w;
    unsigned int wi;
    char junk;

    while (scanf("%o%c", &wi, &junk) > 0) {
        w.s = wi;
        printf("%c%c", w.c[1], w.c[0]);
    }
    printf("\n");

    return 0;
}
===

To read a sequence of two-byte octal little-endian integers, swap w.c[1]
and w.c[0].

Louis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Louis Krupp wrote this post while blinking in Morse code:

On 11/11/2024 1:58 PM, Chris Ahlstrom wrote:

John Ames wrote this post while blinking in Morse code:

On Sat, 9 Nov 2024 09:36:58 -0500
Chris Ahlstrom <OFeem1987@teleworm.us> wrote:

020111 067544 023556 020164 062556 062145 067040 020157 072163 062545
065556 067151 020147 062550 060570 062544 064543 060555 020554 005012

041165 072040 073350 060564 020151 063040 074557 072447 071145 020167
071151 072151 067147 020146 071157 066400 060440 061151 063455 062556
062151 060556 020155 060543 064151 067145 027056 027077

Damn, I still haven't found a program that would easily reverse octal to a >> string.

This is crude, but it seems to work for the post you're replying to,
with big-endian two-byte integers:

===
#include <stdio.h>

int main(void)
{
    union {
        unsigned short s;
        char c[2];
    } w;
    unsigned int wi;
    char junk;

    while (scanf("%o%c", &wi, &junk) > 0) {
        w.s = wi;
        printf("%c%c", w.c[1], w.c[0]);
    }
    printf("\n");

    return 0;
}
===

To read a sequence of two-byte octal little-endian integers, swap w.c[1]
and w.c[0].

Thanks!

--
After all, what is your hosts' purpose in having a party? Surely not for
you to enjoy yourself; if that were their sole purpose, they'd have simply
sent champagne and women over to your place by taxi.
-- P. J. O'Rourke

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In comp.os.linux.misc, Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:

This is crude, but it seems to work for the post you're replying to,
with big-endian two-byte integers:

[snip C code with Unicode whitespace]

To read a sequence of two-byte octal little-endian integers, swap w.c[1]
and w.c[0].

Or you could just pipe the output through `dd conv=swab`.

Elijah
------
whose c compiler doesn't like non-ASCII whitespace

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris Ahlstrom <OFeem1...@teleworm.us> [CA]:

I still haven't found a program that would easily reverse
octal to a string.

You have to take into account the writer machine's endianness
and character set encoding (EBCDIC anyone?).

If it's a big-endian system and the encoding is ASCII, use the
following script. It preserves regular text and converts only what
it sees as octal numbers.

Modifying it to also accept EBCDIC encoded text on a non-EBCDIC
system is left as an exercise for the reader.

I would assume that if you could find a bourne shell, 'sed' and 'awk'
on some EBCDIC system, the script might work without changes.
Can anyone comment on this?


#!/bin/sh

DELIMITER="__octal_number_delimiter__" ;

# Step1: locate octal numbers in input
sed 's@\b\([0-7 ]\+\)\b@'"$DELIMITER"'\1'"$DELIMITER"'@g' |

# Step2: convert octal numbers to text, leaving everything else as it is
awk -v FS="$DELIMITER" -v Q='"' '{
for (i=1;i<=NF;i++) { # for all line fields
t = $i; # get the i-th line field
if (i%2) { # regular text; do not touch it

printf "%s", t;

} else { # octal number; process it

gsub(" ","", t); # remove any space characters first

# make sure the number of octal digits is a mulitiple of 6
for (j=1;j<=(length(t)%6);j++) t = "0" t;

# break up the octal string to sextuplets
for (j=1;j<=length(t)/6;j++) {

# convert a 6-digit octal number to a 4-digit hex number
six_octal_digits=substr(t,6*j-5,6);
four_hex_digits = sprintf ("%x", strtonum(0 six_octal_digits));

# process each pair of hex digits (a byte)
for (k=1;k<=length(four_hex_digits)/2;k++) {
two_hex_digits=substr(four_hex_digits,2*k-1, 2);
# output this byte as an ASCII character (escape non-printable ones)
char = strtonum("0x" two_hex_digits);
printf (((char < 32) ? "<%02x>" : "%c"), char);
}
}
}
}
print ""; # add a newline
}
'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/12/24 5:45 PM, Fritz Wuehler wrote:

Chris Ahlstrom <OFeem1...@teleworm.us> [CA]:

I still haven't found a program that would easily reverse
octal to a string.

You have to take into account the writer machine's endianness
and character set encoding (EBCDIC anyone?).

If it's a big-endian system and the encoding is ASCII, use the
following script. It preserves regular text and converts only what
it sees as octal numbers.

Modifying it to also accept EBCDIC encoded text on a non-EBCDIC
system is left as an exercise for the reader.

I would assume that if you could find a bourne shell, 'sed' and 'awk'
on some EBCDIC system, the script might work without changes.
Can anyone comment on this?

#!/bin/sh

DELIMITER="__octal_number_delimiter__" ;

# Step1: locate octal numbers in input
sed 's@\b\([0-7 ]\+\)\b@'"$DELIMITER"'\1'"$DELIMITER"'@g' |

# Step2: convert octal numbers to text, leaving everything else as it is
awk -v FS="$DELIMITER" -v Q='"' '{
for (i=1;i<=NF;i++) { # for all line fields
t = $i; # get the i-th line field
if (i%2) { # regular text; do not touch it

printf "%s", t;

} else { # octal number; process it

gsub(" ","", t); # remove any space characters first

# make sure the number of octal digits is a mulitiple of 6
for (j=1;j<=(length(t)%6);j++) t = "0" t;

# break up the octal string to sextuplets
for (j=1;j<=length(t)/6;j++) {

# convert a 6-digit octal number to a 4-digit hex number
six_octal_digits=substr(t,6*j-5,6);
four_hex_digits = sprintf ("%x", strtonum(0 six_octal_digits));

# process each pair of hex digits (a byte)
for (k=1;k<=length(four_hex_digits)/2;k++) {
two_hex_digits=substr(four_hex_digits,2*k-1, 2);
# output this byte as an ASCII character (escape non-printable ones)
char = strtonum("0x" two_hex_digits);
printf (((char < 32) ? "<%02x>" : "%c"), char);
}
}
}
}
print ""; # add a newline
}
'

Wow ... haven't thought about octal/EBCDIC for
a LONG time.

How long since 12-bit processors ?

Well, they WERE great at the time ...

For SOME apps today 12-bit would STILL
be good.

I think some PICs were/are effectively 12-bit.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 15 Nov 2024 02:58:55 -0500, 186282@ud0s4.net wrote:

Wow ... haven't thought about octal/EBCDIC for a LONG time.

Until three or four years ago a Midwestern US state's criminal justice API
used EBCDIC and the 3270 protocol. There is little uniformity in the
various state CJIN interfaces but that was one of the stranger ones.

They must have finally ran out of parts for the card sorters on eBay when
they went to XML.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In <lppi68FktfdU1@mid.individual.net> rbowman:

[Snip...]

Until three or four years ago a Midwestern US state's criminal justice API used EBCDIC and the 3270 protocol. There is little uniformity in the
various state CJIN interfaces but that was one of the stranger ones.

FWIW...

When I retired from a major defense contractor (circa ~2003), we
were still using an emulator on Linux boxen for payroll timecard
input, probabably running on IBM COBOL in a corporate backwater:

The x3270 Wiki
https://x3270.miraheze.org/wiki/X3270#

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/15/24 3:30 PM, Harold Stevens wrote:

In <lppi68FktfdU1@mid.individual.net> rbowman:

[Snip...]

Until three or four years ago a Midwestern US state's criminal justice API >> used EBCDIC and the 3270 protocol. There is little uniformity in the
various state CJIN interfaces but that was one of the stranger ones.

FWIW...

When I retired from a major defense contractor (circa ~2003), we
were still using an emulator on Linux boxen for payroll timecard
input, probabably running on IBM COBOL in a corporate backwater:

The x3270 Wiki
https://x3270.miraheze.org/wiki/X3270#

I've discovered that the more you look, the more
you find - in terms of 60s hardware/cpus/programs.

This stuff is STILL in use at various levels from
yer local school district to the IRS and beyond.
It WORKS - and was a HUGE investment back in the
day, UNAFFORDABLE to replace/debug now. They will
use this stuff until the magic smoke finally
escapes forever and ever. Then - disaster.

Oh, and the COBOL done by those narrow-tie Dilberts
in the 60s was DAMNED GOOD - really pro.

As for terminals, I liked the Textronics 4000
series a lot more. For text + simple graphs
vector really was faster/sharper than bitmap ...
at least back in the low-bandwidth day.

Way WAY back in the day, BBS era, you could
send/receive TEXT just fine - albeit often
at 300 baud. The PROBLEM was that there were
LOTS of early PC models - Atari, Commodore, RS
etc. I proposed encoding pages/graphics in
the Textronix 4000 'language' and then writing
smallish apps for each brand/type of PC.
Basically the logic behind Java or PDFs. The
idea never caught on alas ... but bandwidth
did increase rapidly and the variety of PCs
shrank so The Problem kinda-sorta took care of
itself once HTML/CGI and such was practical.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/15/24 1:28 PM, rbowman wrote:

On Fri, 15 Nov 2024 02:58:55 -0500, 186282@ud0s4.net wrote:

Wow ... haven't thought about octal/EBCDIC for a LONG time.

Until three or four years ago a Midwestern US state's criminal justice API used EBCDIC and the 3270 protocol. There is little uniformity in the
various state CJIN interfaces but that was one of the stranger ones.

They must have finally ran out of parts for the card sorters on eBay when they went to XML.

Awwwww ... surely they can have those parts 3-D printed
these days ! Why throw out perfectly good card readers ? :-)

People will spend lots of money, invest a lot of pride,
in having a running 1918 Model-T ...

Again, not entirely sure where the end of octal was. Many
of the PDPs used octal, and I *think* a few PIC chips.
8/16/32 kinda took over kinda early on however.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 16 Nov 2024 00:01:26 -0500, 186282@ud0s4.net wrote:

This stuff is STILL in use at various levels from yer local school
district to the IRS and beyond. It WORKS - and was a HUGE investment
back in the day, UNAFFORDABLE to replace/debug now. They will use
this stuff until the magic smoke finally escapes forever and ever.
Then - disaster.

https://www.avtecinc.com/industries/public-safety/psap-completes-motorola- centracom-elite-replacement

Time goes by so it probably was 20 years ago when I looked at a RFP from a
new site that specified an interface to a Motorola Centracom Gold system.
I'd written the interface years earlier but I gently asked "Er, guys, you
do know Motorola doesn't make that anymore? Do you have one?" Turned out
they didn't so chaos ensued.

https://www.ebay.com/itm/122618898601

I'm sure there are agencies that actually are shopping on eBay to keep
their radio system alive. It was a great system in its day but its day was about 1985. It's understandable considering a medium sized agency may have several hundred thousands of dollars invested in the existing system and getting money for new hardware isn't as esay as getting it for DEI
training.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 15 Nov 2024 23:31:26 -0500, 186282@ud0s4.net wrote:

Again, not entirely sure where the end of octal was. Many of the PDPs
used octal, and I *think* a few PIC chips. 8/16/32 kinda took over
kinda early on however.

chmod 4755

I don't know if I'd call it octal but if you were writing an assembler for quite a few microcontrollers the opcodes would have a pattern where source
ans destination registers were 0 - 7,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/16/24 12:24 AM, rbowman wrote:

On Fri, 15 Nov 2024 23:31:26 -0500, 186282@ud0s4.net wrote:

Again, not entirely sure where the end of octal was. Many of the PDPs
used octal, and I *think* a few PIC chips. 8/16/32 kinda took over
kinda early on however.

chmod 4755

I don't know if I'd call it octal but if you were writing an assembler for quite a few microcontrollers the opcodes would have a pattern where source ans destination registers were 0 - 7,

Octal does persist, sometimes in obscure ways and places.
It WAS kinda big for awhile - a "big step" better than
8-bit.

Alas don't think anymore 12 or 24 bit CPUs are
gonna be made. Might still have a place for some
higher-end microcontrollers - hell, I think Epson
still makes FOUR-bit microcontrollers (looked at
the sheet for one once, insanely capable).

Hmmm ... 256 of those 4-bitters running
parallel - that'd be a fun project :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)