On Tuesday, December 6, 2022 at 6:21:41 AM UTC-6, Benny Lyne Amorsen wrote:
> MitchAlsup <Mitch...@aol.com> writes:
>
> > I really hate it when eXcel converts "1/4" into Jan-4-2022 when I literally
> > wanted the string 1/4 {as in DIV4} in the cell. The <ahem> prescribed
> > way of doing this it to reformat the cell from general to text and then
> > being careful to put something textural in the cell before putting 1/4
> > in the cell.
> I was going to recommend LibreOffice Calc, because typing 1/4 there gets
> you ¼ (Unicode 1/4 symbol).
>
> For kicks, I then tried 1/3... And got March 1st 2022.
>
> Spreadsheets are a cursed technology.
<
At least you tried......!!
>
>
> /Benny

According to MitchAlsup <MitchAlsup@aol.com>:
>BUT I DO NOT WANT 0.25;
>I WANT THE 3 CHARACTERS "1/4" in the cell.
>I DO NOT WANT THE VALUE OF 1 DIVIDED BY THE VALUE 4
>I WANT THE 3 CHARACTERS "1/4" in the cell.

Oh, then type "1/4"

With the quotes.

Excel does some dumb things but it does know what quotes mean.

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

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Anton Ertl wrote:
>
>> Russell Wallace <russell.wallace@gmail.com> writes:
>>
>>> On Sunday, December 4, 2022 at 6:46:30 PM UTC, Anton Ertl wrote:
>>>
>>>> If these are represented as the binary integers 123 (7 bits) and
>>>> 456 (9 bits), it seems to me that the multiplier can early-out at
>>>> least as early as if they are represented as BCD numbers (both 12
>>>> bits).
>>>
>>> Right, scaled integers are the other good way to represent
>>> decimal numbers. (But this is a very different solution from
>>> binary floating point.)
>>>
>>>> Display update is so slow that the conversion cost is minor change.
>>>
>>> You're probably assuming a bitmap display with overlapping
>>> windows and scalable fonts? Once you're at that tech level, the
>>> arithmetic cost (in whichever format) is also minor change. But
>>> Lotus 1-2-3 ran on a character cell display, where updating each
>>> character was just a store to a single memory location.
>>
>> It was a "graphics" card memory location, and CPU access there
>> tends to be slower than main memory. Probably more importantly
>> in the early generations, there's an overhead in determining the
>> memory location that you have to write to, and if you have to
>> write at all (i.e., if the cell is on-screen of off-screen).
>
> I discovered this by measuring it around 1983/84, which is when I
> switched my own programs to use a memory block as a shadow frame
> buffer, only copying any updates to the real screen, and only when
> I had a few spare milliseconds to do so. I.e. on a quickly
> scrolling screen I might not update every single line.

It's sad that we seem to have lost the advances in computer
graphics that were already known 50 years ago. The Alto, even
though it was only a 16-bit computer running at 6 MHz, could
easily do smooth scrolling over its entire display (606 x 808
pixels, IIRC). It did this by using a display list of regions
(horizontal strips of varying widths) rather than a simple frame
buffer. Because the display list was an actual linked list, it
was easy to prepare a new list and simply link it in at the
appropriate moment. Temporal fidelity was achieved by switching
in a new display list at a time when a vertical retrace was
occurring; no glitches, ever.

It would be nice if modern machines and operating systems could
provide a comparable high-performance graphics capability, with
the same level of temporal fidelity, as the Alto did almost 50
years ago. Alas, the scourge of frame buffers and rudimentally
designed windowing systems has put us in a world where, to use a
phrase, glitches happen.

Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> Anton Ertl wrote:
>>
>>> Russell Wallace <russell.wallace@gmail.com> writes:
>>>
>>>> On Sunday, December 4, 2022 at 6:46:30 PM UTC, Anton Ertl wrote:
>>>>
>>>>> If these are represented as the binary integers 123 (7 bits) and
>>>>> 456 (9 bits), it seems to me that the multiplier can early-out at
>>>>> least as early as if they are represented as BCD numbers (both 12
>>>>> bits).
>>>>
>>>> Right, scaled integers are the other good way to represent
>>>> decimal numbers. (But this is a very different solution from
>>>> binary floating point.)
>>>>
>>>>> Display update is so slow that the conversion cost is minor change.
>>>>
>>>> You're probably assuming a bitmap display with overlapping
>>>> windows and scalable fonts? Once you're at that tech level, the
>>>> arithmetic cost (in whichever format) is also minor change. But
>>>> Lotus 1-2-3 ran on a character cell display, where updating each
>>>> character was just a store to a single memory location.
>>>
>>> It was a "graphics" card memory location, and CPU access there
>>> tends to be slower than main memory. Probably more importantly
>>> in the early generations, there's an overhead in determining the
>>> memory location that you have to write to, and if you have to
>>> write at all (i.e., if the cell is on-screen of off-screen).
>>
>> I discovered this by measuring it around 1983/84, which is when I
>> switched my own programs to use a memory block as a shadow frame
>> buffer, only copying any updates to the real screen, and only when
>> I had a few spare milliseconds to do so. I.e. on a quickly
>> scrolling screen I might not update every single line.
>
> It's sad that we seem to have lost the advances in computer
> graphics that were already known 50 years ago. The Alto, even
> though it was only a 16-bit computer running at 6 MHz, could
> easily do smooth scrolling over its entire display (606 x 808
> pixels, IIRC). It did this by using a display list of regions
> (horizontal strips of varying widths) rather than a simple frame
> buffer. Because the display list was an actual linked list, it
> was easy to prepare a new list and simply link it in at the
> appropriate moment. Temporal fidelity was achieved by switching
> in a new display list at a time when a vertical retrace was
> occurring; no glitches, ever.

This was of course the HW way to do it back when keeping a megapixel
screen updated at 60 Hz was _hard_.

In the code I mentioned above (a terminal emulator in fact, which needed
to do all the windowed scrolling operations supported by
VT52/VT100/VT220/NORD/etc terminals I did use a linked list memory store
for the frame buffer, with separate dirty flags for each element. Back
in those days all frame buffer writes had to be synced to either
horizontal (very short!) or vertical retrace, but even the vertical
retrace didn't last long enough to update everything in one go afair, so
my full screen update code would use both to get done asap.
>
> It would be nice if modern machines and operating systems could
> provide a comparable high-performance graphics capability, with
> the same level of temporal fidelity, as the Alto did almost 50
> years ago. Alas, the scourge of frame buffers and rudimentally
> designed windowing systems has put us in a world where, to use a
> phrase, glitches happen.
>
For most stuff it doesn't matter, and when it does matter, then we just
throw a full GPU at at. :-)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 12/15/2022 8:51 AM, Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> Anton Ertl wrote:
>>
>>> Russell Wallace <russell.wallace@gmail.com> writes:
>>>
>>>> On Sunday, December 4, 2022 at 6:46:30 PM UTC, Anton Ertl wrote:
>>>>
>>>>> If these are represented as the binary integers 123 (7 bits) and
>>>>> 456 (9 bits), it seems to me that the multiplier can early-out at
>>>>> least as early as if they are represented as BCD numbers (both 12
>>>>> bits).
>>>>
>>>> Right, scaled integers are the other good way to represent
>>>> decimal numbers. (But this is a very different solution from
>>>> binary floating point.)
>>>>
>>>>> Display update is so slow that the conversion cost is minor change.
>>>>
>>>> You're probably assuming a bitmap display with overlapping
>>>> windows and scalable fonts? Once you're at that tech level, the
>>>> arithmetic cost (in whichever format) is also minor change. But
>>>> Lotus 1-2-3 ran on a character cell display, where updating each
>>>> character was just a store to a single memory location.
>>>
>>> It was a "graphics" card memory location, and CPU access there
>>> tends to be slower than main memory. Probably more importantly
>>> in the early generations, there's an overhead in determining the
>>> memory location that you have to write to, and if you have to
>>> write at all (i.e., if the cell is on-screen of off-screen).
>>
>> I discovered this by measuring it around 1983/84, which is when I
>> switched my own programs to use a memory block as a shadow frame
>> buffer, only copying any updates to the real screen, and only when
>> I had a few spare milliseconds to do so. I.e. on a quickly
>> scrolling screen I might not update every single line.
>
> It's sad that we seem to have lost the advances in computer
> graphics that were already known 50 years ago. The Alto, even
> though it was only a 16-bit computer running at 6 MHz, could
> easily do smooth scrolling over its entire display (606 x 808
> pixels, IIRC). It did this by using a display list of regions
> (horizontal strips of varying widths) rather than a simple frame
> buffer. Because the display list was an actual linked list, it
> was easy to prepare a new list and simply link it in at the
> appropriate moment. Temporal fidelity was achieved by switching
> in a new display list at a time when a vertical retrace was
> occurring; no glitches, ever.
>
> It would be nice if modern machines and operating systems could
> provide a comparable high-performance graphics capability, with
> the same level of temporal fidelity, as the Alto did almost 50
> years ago. Alas, the scourge of frame buffers and rudimentally
> designed windowing systems has put us in a world where, to use a
> phrase, glitches happen.

So, I am guessing no "blit" operation to try to copy a "DIB Bitmap
Object" (and/or XImage / XPutImage) to the window 30 or 60 times per
second or so?...

Well, a little worse in my case, since the "GUI mode" first requires
copying over the framebuffer pixels from the DIB Object, and then
running a color-cell encoder over said pixels (to convert to the display
memory format, mostly because there is not enough VRAM for a traditional
raster oriented frambuffer).

Kinda hard to make this part work all that quickly at 640x400 on a 50
MHz CPU...

Some DOS-era software seemed to have two 8-bpp framebuffers, at A0000
and B0000 (or A000:0000 / B000:0000), drawing to these buffers, and then
twiddling some hardware bits to flip which buffer was being displayed.

Wouldn't work so well in my case, as even if the hardware were using an
8bpp linear framebuffer, the display interface doesn't allow byte-level
access to VRAM (the VRAM is accessed in terms of 64-bit units).

Well, apart from some software which had used the screen in modes where
it was split into 4 bit-planes (also sort of a thing that VGA did...).
Have to basically fully emulate this stuff in software (well, and also
don't have enough VRAM for 640x480 16-color either; but there is
640x400, and a 640x480/800x600 4-color mode, *).

*: Where one has multiple choices of "4 amazing colors" (on screen at
any given time):
Black/Cyan/Magenta/White
Black/Green/Red/Yellow
Black/Cyan/Red/White
Black/DarkGray/LightGray/White

A case could maybe be made for adding a "4 shades of olive" mode (say,
for a similar look to the original GameBoy or similar). Or maybe add a
mode register to allow 4 arbitrary RGB555 colors to be used in the
4-color palette.

Though, this could also be faked easily enough in the color-cell mode
(and 160x144 is a lot closer to 320x200 than to 640x480 or 800x600).

....

On Thursday, December 15, 2022 at 2:36:13 PM UTC-6, BGB wrote:
> On 12/15/2022 8:51 AM, Tim Rentsch wrote:
> > Terje Mathisen <terje.m...@tmsw.no> writes:
> >
> >> Anton Ertl wrote:
> >>
> >>> Russell Wallace <russell...@gmail.com> writes:
> >>>
> >>>> On Sunday, December 4, 2022 at 6:46:30 PM UTC, Anton Ertl wrote:
> >>>>
> >>>>> If these are represented as the binary integers 123 (7 bits) and
> >>>>> 456 (9 bits), it seems to me that the multiplier can early-out at
> >>>>> least as early as if they are represented as BCD numbers (both 12
> >>>>> bits).
> >>>>
> >>>> Right, scaled integers are the other good way to represent
> >>>> decimal numbers. (But this is a very different solution from
> >>>> binary floating point.)
> >>>>
> >>>>> Display update is so slow that the conversion cost is minor change.
> >>>>
> >>>> You're probably assuming a bitmap display with overlapping
> >>>> windows and scalable fonts? Once you're at that tech level, the
> >>>> arithmetic cost (in whichever format) is also minor change. But
> >>>> Lotus 1-2-3 ran on a character cell display, where updating each
> >>>> character was just a store to a single memory location.
> >>>
> >>> It was a "graphics" card memory location, and CPU access there
> >>> tends to be slower than main memory. Probably more importantly
> >>> in the early generations, there's an overhead in determining the
> >>> memory location that you have to write to, and if you have to
> >>> write at all (i.e., if the cell is on-screen of off-screen).
> >>
> >> I discovered this by measuring it around 1983/84, which is when I
> >> switched my own programs to use a memory block as a shadow frame
> >> buffer, only copying any updates to the real screen, and only when
> >> I had a few spare milliseconds to do so. I.e. on a quickly
> >> scrolling screen I might not update every single line.
> >
> > It's sad that we seem to have lost the advances in computer
> > graphics that were already known 50 years ago. The Alto, even
> > though it was only a 16-bit computer running at 6 MHz, could
> > easily do smooth scrolling over its entire display (606 x 808
> > pixels, IIRC). It did this by using a display list of regions
> > (horizontal strips of varying widths) rather than a simple frame
> > buffer. Because the display list was an actual linked list, it
> > was easy to prepare a new list and simply link it in at the
> > appropriate moment. Temporal fidelity was achieved by switching
> > in a new display list at a time when a vertical retrace was
> > occurring; no glitches, ever.
> >
> > It would be nice if modern machines and operating systems could
> > provide a comparable high-performance graphics capability, with
> > the same level of temporal fidelity, as the Alto did almost 50
> > years ago. Alas, the scourge of frame buffers and rudimentally
> > designed windowing systems has put us in a world where, to use a
> > phrase, glitches happen.
> So, I am guessing no "blit" operation to try to copy a "DIB Bitmap
> Object" (and/or XImage / XPutImage) to the window 30 or 60 times per
> second or so?...
>
>
> Well, a little worse in my case, since the "GUI mode" first requires
> copying over the framebuffer pixels from the DIB Object, and then
> running a color-cell encoder over said pixels (to convert to the display
> memory format, mostly because there is not enough VRAM for a traditional
> raster oriented frambuffer).
>
> Kinda hard to make this part work all that quickly at 640x400 on a 50
> MHz CPU...
>
>
> Some DOS-era software seemed to have two 8-bpp framebuffers, at A0000
> and B0000 (or A000:0000 / B000:0000), drawing to these buffers, and then
> twiddling some hardware bits to flip which buffer was being displayed.
>
> Wouldn't work so well in my case, as even if the hardware were using an
> 8bpp linear framebuffer, the display interface doesn't allow byte-level
> access to VRAM (the VRAM is accessed in terms of 64-bit units).
>
>
> Well, apart from some software which had used the screen in modes where
> it was split into 4 bit-planes (also sort of a thing that VGA did...).
> Have to basically fully emulate this stuff in software (well, and also
> don't have enough VRAM for 640x480 16-color either; but there is
> 640x400, and a 640x480/800x600 4-color mode, *).
>
> *: Where one has multiple choices of "4 amazing colors" (on screen at
> any given time):
> Black/Cyan/Magenta/White
> Black/Green/Red/Yellow
> Black/Cyan/Red/White
> Black/DarkGray/LightGray/White
>
>
> A case could maybe be made for adding a "4 shades of olive" mode (say,
> for a similar look to the original GameBoy or similar). Or maybe add a
> mode register to allow 4 arbitrary RGB555 colors to be used in the
> 4-color palette.
>
> Though, this could also be faked easily enough in the color-cell mode
> (and 160x144 is a lot closer to 320x200 than to 640x480 or 800x600).
>
>
> ...
Acccckkkkk::
<
I remember those days..........

On 12/15/2022 2:53 PM, MitchAlsup wrote:
> On Thursday, December 15, 2022 at 2:36:13 PM UTC-6, BGB wrote:
>> On 12/15/2022 8:51 AM, Tim Rentsch wrote:
>>> Terje Mathisen <terje.m...@tmsw.no> writes:
>>>
>>>> Anton Ertl wrote:
>>>>
>>>>> Russell Wallace <russell...@gmail.com> writes:
>>>>>
>>>>>> On Sunday, December 4, 2022 at 6:46:30 PM UTC, Anton Ertl wrote:
>>>>>>
>>>>>>> If these are represented as the binary integers 123 (7 bits) and
>>>>>>> 456 (9 bits), it seems to me that the multiplier can early-out at
>>>>>>> least as early as if they are represented as BCD numbers (both 12
>>>>>>> bits).
>>>>>>
>>>>>> Right, scaled integers are the other good way to represent
>>>>>> decimal numbers. (But this is a very different solution from
>>>>>> binary floating point.)
>>>>>>
>>>>>>> Display update is so slow that the conversion cost is minor change.
>>>>>>
>>>>>> You're probably assuming a bitmap display with overlapping
>>>>>> windows and scalable fonts? Once you're at that tech level, the
>>>>>> arithmetic cost (in whichever format) is also minor change. But
>>>>>> Lotus 1-2-3 ran on a character cell display, where updating each
>>>>>> character was just a store to a single memory location.
>>>>>
>>>>> It was a "graphics" card memory location, and CPU access there
>>>>> tends to be slower than main memory. Probably more importantly
>>>>> in the early generations, there's an overhead in determining the
>>>>> memory location that you have to write to, and if you have to
>>>>> write at all (i.e., if the cell is on-screen of off-screen).
>>>>
>>>> I discovered this by measuring it around 1983/84, which is when I
>>>> switched my own programs to use a memory block as a shadow frame
>>>> buffer, only copying any updates to the real screen, and only when
>>>> I had a few spare milliseconds to do so. I.e. on a quickly
>>>> scrolling screen I might not update every single line.
>>>
>>> It's sad that we seem to have lost the advances in computer
>>> graphics that were already known 50 years ago. The Alto, even
>>> though it was only a 16-bit computer running at 6 MHz, could
>>> easily do smooth scrolling over its entire display (606 x 808
>>> pixels, IIRC). It did this by using a display list of regions
>>> (horizontal strips of varying widths) rather than a simple frame
>>> buffer. Because the display list was an actual linked list, it
>>> was easy to prepare a new list and simply link it in at the
>>> appropriate moment. Temporal fidelity was achieved by switching
>>> in a new display list at a time when a vertical retrace was
>>> occurring; no glitches, ever.
>>>
>>> It would be nice if modern machines and operating systems could
>>> provide a comparable high-performance graphics capability, with
>>> the same level of temporal fidelity, as the Alto did almost 50
>>> years ago. Alas, the scourge of frame buffers and rudimentally
>>> designed windowing systems has put us in a world where, to use a
>>> phrase, glitches happen.
>> So, I am guessing no "blit" operation to try to copy a "DIB Bitmap
>> Object" (and/or XImage / XPutImage) to the window 30 or 60 times per
>> second or so?...
>>
>>
>> Well, a little worse in my case, since the "GUI mode" first requires
>> copying over the framebuffer pixels from the DIB Object, and then
>> running a color-cell encoder over said pixels (to convert to the display
>> memory format, mostly because there is not enough VRAM for a traditional
>> raster oriented frambuffer).
>>
>> Kinda hard to make this part work all that quickly at 640x400 on a 50
>> MHz CPU...
>>
>>
>> Some DOS-era software seemed to have two 8-bpp framebuffers, at A0000
>> and B0000 (or A000:0000 / B000:0000), drawing to these buffers, and then
>> twiddling some hardware bits to flip which buffer was being displayed.
>>
>> Wouldn't work so well in my case, as even if the hardware were using an
>> 8bpp linear framebuffer, the display interface doesn't allow byte-level
>> access to VRAM (the VRAM is accessed in terms of 64-bit units).
>>
>>
>> Well, apart from some software which had used the screen in modes where
>> it was split into 4 bit-planes (also sort of a thing that VGA did...).
>> Have to basically fully emulate this stuff in software (well, and also
>> don't have enough VRAM for 640x480 16-color either; but there is
>> 640x400, and a 640x480/800x600 4-color mode, *).
>>
>> *: Where one has multiple choices of "4 amazing colors" (on screen at
>> any given time):
>> Black/Cyan/Magenta/White
>> Black/Green/Red/Yellow
>> Black/Cyan/Red/White
>> Black/DarkGray/LightGray/White
>>
>>
>> A case could maybe be made for adding a "4 shades of olive" mode (say,
>> for a similar look to the original GameBoy or similar). Or maybe add a
>> mode register to allow 4 arbitrary RGB555 colors to be used in the
>> 4-color palette.
>>
>> Though, this could also be faked easily enough in the color-cell mode
>> (and 160x144 is a lot closer to 320x200 than to 640x480 or 800x600).
>>
>>
>> ...
> Acccckkkkk::
> <
> I remember those days..........

Yeah. It is a trick:

Try to do full color graphics where on screen, though there is only
enough memory for 2-bits-per-pixel and a pair of colors for every 4x4
pixel block...

Except in 640x480 or 800x600, where there is no longer enough memory for
the per-block colors (so, it is effectively limited to a 2bpp pseudo
bitmapped mode).

Well, unless one wants to do graphics in what is essentially a text mode
(using character glyph style color-cell).

Can theoretically go into what is essentially a 100x75 text mode (with
800x600 screen resolution), and then draw graphics more like on a
Commodore 64 (say, using a "Font RAM").

So, one has multiple choices here (say, the 4-color mode allows setting
every pixel independently, which is not actually possible in the other
mode; not quite bitmapped, and limited to 2 colors per 8x8 pixel block).

At 320x200, it can draw Doom in full quality, but doesn't have enough
video memory (nor the needed hardware support) for double-buffering the
display.

Mostly works for now...

Technically has more VRAM than the CGA, NES, or SNES.

But, less VRAM than the original VGA (hence its inability to do 640x480
16-color or similar). Roughly comparable to the EGA on this front.

Technically also an unusually slow refresh rate at 800x600, as the
(standard) 75Hz refresh would likely require effectively driving the
screen-refresh logic and similar internally at a higher clock frequency.

Though, 36 Hz is below the rated minimum refresh-rate for most multisync
monitors, but at least the LCD monitors and similar I have seemed to
accept it (and not really worth it to try to get ahold of a CRT monitor
to test with).

....

On 12/5/2022 5:21 AM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

snip

>> If the more popular
>> languages that replaced COBOL had good support for fixed decimal, I
>> suspect that might have won out over binary floating point (especially
>> if there was some hardware support).
>
> The main successor for COBOL seems to be Java.

That is true now, but by the time of Java's ascendancy, the die had
already been cast. The immediate successor to COBOL as the primary
language for business applications was C. IBM tried to push PL/1, but
wasn't successful for a variety of reasons. Later, C++ tried, and now,
as you say, Java is the winner. But once C became popular and it didn't
support decimal arithmetic directly, programmers just got used to that,
and, for the most part, accepted it, so future "business oriented"
languages didn't support it.

> Searching for "Java
> fixed point" leads me to <https://github.com/tools4j/decimal4j>. I
> find having to write
>
> Decimal2f interest = principal.multiplyBy(rate.multiplyExact(time));
>
> cumbersome, but it might be just to the taste of COBOL programmers.

:-) Of course, in COBOL, there was no "extra code" to specify decimal
arithmetic.

> Anyway, if programmers really wanted fixed point for the jobs where
> COBOL used to be used, Ada, C++ and Java would have allowed to make
> convenient fixed-point libraries (or actual built-in support for fixed
> point in the case of Ada). Apparently they did not care enough.

Generally agreed. Specifically, Ada wasn't intended for business
applications, and, of course, C++ built on C's heritage and had enough
problems of its own without introducing another feature. As I said, by
the time Java became available, everyone was used to no decimal support.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

BGB <cr88192@gmail.com> writes:

> On 12/15/2022 8:51 AM, Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Anton Ertl wrote:
>>>
>>>> Russell Wallace <russell.wallace@gmail.com> writes:
>>>>
>>>>> On Sunday, December 4, 2022 at 6:46:30 PM UTC, Anton Ertl wrote:
>>>>>
>>>>>> If these are represented as the binary integers 123 (7 bits) and
>>>>>> 456 (9 bits), it seems to me that the multiplier can early-out at
>>>>>> least as early as if they are represented as BCD numbers (both 12
>>>>>> bits).
>>>>>
>>>>> Right, scaled integers are the other good way to represent
>>>>> decimal numbers. (But this is a very different solution from
>>>>> binary floating point.)
>>>>>
>>>>>> Display update is so slow that the conversion cost is minor change.
>>>>>
>>>>> You're probably assuming a bitmap display with overlapping
>>>>> windows and scalable fonts? Once you're at that tech level, the
>>>>> arithmetic cost (in whichever format) is also minor change. But
>>>>> Lotus 1-2-3 ran on a character cell display, where updating each
>>>>> character was just a store to a single memory location.
>>>>
>>>> It was a "graphics" card memory location, and CPU access there
>>>> tends to be slower than main memory. Probably more importantly
>>>> in the early generations, there's an overhead in determining the
>>>> memory location that you have to write to, and if you have to
>>>> write at all (i.e., if the cell is on-screen of off-screen).
>>>
>>> I discovered this by measuring it around 1983/84, which is when I
>>> switched my own programs to use a memory block as a shadow frame
>>> buffer, only copying any updates to the real screen, and only when
>>> I had a few spare milliseconds to do so. I.e. on a quickly
>>> scrolling screen I might not update every single line.
>>
>> It's sad that we seem to have lost the advances in computer
>> graphics that were already known 50 years ago. The Alto, even
>> though it was only a 16-bit computer running at 6 MHz, could
>> easily do smooth scrolling over its entire display (606 x 808
>> pixels, IIRC). It did this by using a display list of regions
>> (horizontal strips of varying widths) rather than a simple frame
>> buffer. Because the display list was an actual linked list, it
>> was easy to prepare a new list and simply link it in at the
>> appropriate moment. Temporal fidelity was achieved by switching
>> in a new display list at a time when a vertical retrace was
>> occurring; no glitches, ever.
>>
>> It would be nice if modern machines and operating systems could
>> provide a comparable high-performance graphics capability, with
>> the same level of temporal fidelity, as the Alto did almost 50
>> years ago. Alas, the scourge of frame buffers and rudimentally
>> designed windowing systems has put us in a world where, to use a
>> phrase, glitches happen.
>
> So, I am guessing no "blit" operation to try to copy a "DIB Bitmap
> Object" (and/or XImage / XPutImage) to the window 30 or 60 times per
> second or so?...
>
>
> Well, a little worse in my case, since the "GUI mode" first requires
> copying over the framebuffer pixels from the DIB Object, and then
> running a color-cell encoder over said pixels (to convert to the
> display memory format, mostly because there is not enough VRAM for a
> traditional raster oriented frambuffer). [...]

My comment is about a general lack, not about the detailed
specifics.

If you want to know about the specifics, I suggest you look for
information about the design of the Alto (it should be easy to
find by doing some web searches). For one thing, the Alto didn't
have a framebuffer; the display was refreshed directly out of
main memory. There was no capability for color, which would have
been far too expensive at the time the Alto was designed (early
1970s). As it was approximately half the total memory available
was (typically) used to hold the bits of the display image. Lots
of other points of interest.

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Anton Ertl wrote:
>>>
>>>> Russell Wallace <russell.wallace@gmail.com> writes:
>>>>
>>>>> On Sunday, December 4, 2022 at 6:46:30 PM UTC, Anton Ertl wrote:
>>>>>
>>>>>> If these are represented as the binary integers 123 (7 bits)
>>>>>> and 456 (9 bits), it seems to me that the multiplier can
>>>>>> early-out at least as early as if they are represented as BCD
>>>>>> numbers (both 12 bits).
>>>>>
>>>>> Right, scaled integers are the other good way to represent
>>>>> decimal numbers. (But this is a very different solution from
>>>>> binary floating point.)
>>>>>
>>>>>> Display update is so slow that the conversion cost is minor
>>>>>> change.
>>>>>
>>>>> You're probably assuming a bitmap display with overlapping
>>>>> windows and scalable fonts? Once you're at that tech level, the
>>>>> arithmetic cost (in whichever format) is also minor change. But
>>>>> Lotus 1-2-3 ran on a character cell display, where updating each
>>>>> character was just a store to a single memory location.
>>>>
>>>> It was a "graphics" card memory location, and CPU access there
>>>> tends to be slower than main memory. Probably more importantly
>>>> in the early generations, there's an overhead in determining the
>>>> memory location that you have to write to, and if you have to
>>>> write at all (i.e., if the cell is on-screen of off-screen).
>>>
>>> I discovered this by measuring it around 1983/84, which is when I
>>> switched my own programs to use a memory block as a shadow frame
>>> buffer, only copying any updates to the real screen, and only when
>>> I had a few spare milliseconds to do so. I.e. on a quickly
>>> scrolling screen I might not update every single line.
>>
>> It's sad that we seem to have lost the advances in computer
>> graphics that were already known 50 years ago. The Alto, even
>> though it was only a 16-bit computer running at 6 MHz, could
>> easily do smooth scrolling over its entire display (606 x 808
>> pixels, IIRC). It did this by using a display list of regions
>> (horizontal strips of varying widths) rather than a simple frame
>> buffer. Because the display list was an actual linked list, it
>> was easy to prepare a new list and simply link it in at the
>> appropriate moment. Temporal fidelity was achieved by switching
>> in a new display list at a time when a vertical retrace was
>> occurring; no glitches, ever.
>
> This was of course the HW way to do it back when keeping a
> megapixel screen updated at 60 Hz was _hard_.
>
> In the code I mentioned above (a terminal emulator in fact, which
> needed to do all the windowed scrolling operations supported by
> VT52/VT100/VT220/NORD/etc terminals I did use a linked list memory
> store for the frame buffer, with separate dirty flags for each
> element. Back in those days all frame buffer writes had to be
> synced to either horizontal (very short!) or vertical retrace, but
> even the vertical retrace didn't last long enough to update
> everything in one go afair, so my full screen update code would
> use both to get done asap.

If the frame buffer is represented as a linked list, why not
just make up a new linked list and change the top-level link
during the vertical retrace? Surely changing the one link
could be done in the time it takes to do a vertical retrace.

>> It would be nice if modern machines and operating systems could
>> provide a comparable high-performance graphics capability, with
>> the same level of temporal fidelity, as the Alto did almost 50
>> years ago. Alas, the scourge of frame buffers and rudimentally
>> designed windowing systems has put us in a world where, to use a
>> phrase, glitches happen.
>
> For most stuff it doesn't matter,

I find this attitude reprehensible, especially coming from
someone as capable as you are. There is no reason in this day
and age to tolerate shitty software. Certainly there are things
about Apple that I don't like, but when it comes to software
quality developers should strive to be more like Apple and less
like Microsoft.

> and when it does matter, then we just throw a full GPU at
> at. :-)

This one too. It's ridiculous to pay $1000 for a solution when
there is another way of solving the same problem that costs less
than $10. Equally ridiculous is needing GB/sec of bandwidth in
cases where MB/sec would do. Or web pages that load multiple
megabytes to display only a few thousand bytes of content. These
excesses, and others like them, must be fought at every level.

On Saturday, December 17, 2022 at 10:32:14 AM UTC-6, Tim Rentsch wrote:
> Terje Mathisen <terje.m...@tmsw.no> writes:
>
> > Tim Rentsch wrote:
> >
> >> Terje Mathisen <terje.m...@tmsw.no> writes:
> >>
> >>> Anton Ertl wrote:
> >>>
> >>>> Russell Wallace <russell...@gmail.com> writes:
> >>>>
> >>>>> On Sunday, December 4, 2022 at 6:46:30 PM UTC, Anton Ertl wrote:
> >>>>>
> >>>>>> If these are represented as the binary integers 123 (7 bits)
> >>>>>> and 456 (9 bits), it seems to me that the multiplier can
> >>>>>> early-out at least as early as if they are represented as BCD
> >>>>>> numbers (both 12 bits).
> >>>>>
> >>>>> Right, scaled integers are the other good way to represent
> >>>>> decimal numbers. (But this is a very different solution from
> >>>>> binary floating point.)
> >>>>>
> >>>>>> Display update is so slow that the conversion cost is minor
> >>>>>> change.
> >>>>>
> >>>>> You're probably assuming a bitmap display with overlapping
> >>>>> windows and scalable fonts? Once you're at that tech level, the
> >>>>> arithmetic cost (in whichever format) is also minor change. But
> >>>>> Lotus 1-2-3 ran on a character cell display, where updating each
> >>>>> character was just a store to a single memory location.
> >>>>
> >>>> It was a "graphics" card memory location, and CPU access there
> >>>> tends to be slower than main memory. Probably more importantly
> >>>> in the early generations, there's an overhead in determining the
> >>>> memory location that you have to write to, and if you have to
> >>>> write at all (i.e., if the cell is on-screen of off-screen).
> >>>
> >>> I discovered this by measuring it around 1983/84, which is when I
> >>> switched my own programs to use a memory block as a shadow frame
> >>> buffer, only copying any updates to the real screen, and only when
> >>> I had a few spare milliseconds to do so. I.e. on a quickly
> >>> scrolling screen I might not update every single line.
> >>
> >> It's sad that we seem to have lost the advances in computer
> >> graphics that were already known 50 years ago. The Alto, even
> >> though it was only a 16-bit computer running at 6 MHz, could
> >> easily do smooth scrolling over its entire display (606 x 808
> >> pixels, IIRC). It did this by using a display list of regions
> >> (horizontal strips of varying widths) rather than a simple frame
> >> buffer. Because the display list was an actual linked list, it
> >> was easy to prepare a new list and simply link it in at the
> >> appropriate moment. Temporal fidelity was achieved by switching
> >> in a new display list at a time when a vertical retrace was
> >> occurring; no glitches, ever.
> >
> > This was of course the HW way to do it back when keeping a
> > megapixel screen updated at 60 Hz was _hard_.
> >
> > In the code I mentioned above (a terminal emulator in fact, which
> > needed to do all the windowed scrolling operations supported by
> > VT52/VT100/VT220/NORD/etc terminals I did use a linked list memory
> > store for the frame buffer, with separate dirty flags for each
> > element. Back in those days all frame buffer writes had to be
> > synced to either horizontal (very short!) or vertical retrace, but
> > even the vertical retrace didn't last long enough to update
> > everything in one go afair, so my full screen update code would
> > use both to get done asap.
> If the frame buffer is represented as a linked list, why not
> just make up a new linked list and change the top-level link
> during the vertical retrace? Surely changing the one link
> could be done in the time it takes to do a vertical retrace.
> >> It would be nice if modern machines and operating systems could
> >> provide a comparable high-performance graphics capability, with
> >> the same level of temporal fidelity, as the Alto did almost 50
> >> years ago. Alas, the scourge of frame buffers and rudimentally
> >> designed windowing systems has put us in a world where, to use a
> >> phrase, glitches happen.
> >
> > For most stuff it doesn't matter,
> I find this attitude reprehensible, especially coming from
> someone as capable as you are. There is no reason in this day
> and age to tolerate shitty software.
<
a) I applaud the suggestion that no one should accept shitty SW
b) There is the package known as Windows that fits your description
.....of shitty
c) every web browser shovels shit at you in the form of advertising.
d) even adblockers are getting to the point of selectively shoveling
.....you shit
So, while the premises good, there is no escape from shit in SW.
<
> Certainly there are things
> about Apple that I don't like, but when it comes to software
> quality developers should strive to be more like Apple and less
> like Microsoft.
> > and when it does matter, then we just throw a full GPU at
> > at. :-)
> This one too. It's ridiculous to pay $1000 for a solution when
> there is another way of solving the same problem that costs less
> than $10. Equally ridiculous is needing GB/sec of bandwidth in
> cases where MB/sec would do. Or web pages that load multiple
> megabytes to display only a few thousand bytes of content. These
> excesses, and others like them, must be fought at every level.
<
I think I would settle for delivering the pages content first, and
shoveling the advertisements later.
<
But then again, you can't buy a PC that does not already come
with a GPU built in (at a cost so low you don't see it).

Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> Tim Rentsch wrote:
>>
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> Anton Ertl wrote:
>>>>
>>>>> Russell Wallace <russell.wallace@gmail.com> writes:
>>>>>
>>>>>> On Sunday, December 4, 2022 at 6:46:30 PM UTC, Anton Ertl wrote:
>>>>>>
>>>>>>> If these are represented as the binary integers 123 (7 bits)
>>>>>>> and 456 (9 bits), it seems to me that the multiplier can
>>>>>>> early-out at least as early as if they are represented as BCD
>>>>>>> numbers (both 12 bits).
>>>>>>
>>>>>> Right, scaled integers are the other good way to represent
>>>>>> decimal numbers. (But this is a very different solution from
>>>>>> binary floating point.)
>>>>>>
>>>>>>> Display update is so slow that the conversion cost is minor
>>>>>>> change.
>>>>>>
>>>>>> You're probably assuming a bitmap display with overlapping
>>>>>> windows and scalable fonts? Once you're at that tech level, the
>>>>>> arithmetic cost (in whichever format) is also minor change. But
>>>>>> Lotus 1-2-3 ran on a character cell display, where updating each
>>>>>> character was just a store to a single memory location.
>>>>>
>>>>> It was a "graphics" card memory location, and CPU access there
>>>>> tends to be slower than main memory. Probably more importantly
>>>>> in the early generations, there's an overhead in determining the
>>>>> memory location that you have to write to, and if you have to
>>>>> write at all (i.e., if the cell is on-screen of off-screen).
>>>>
>>>> I discovered this by measuring it around 1983/84, which is when I
>>>> switched my own programs to use a memory block as a shadow frame
>>>> buffer, only copying any updates to the real screen, and only when
>>>> I had a few spare milliseconds to do so. I.e. on a quickly
>>>> scrolling screen I might not update every single line.
>>>
>>> It's sad that we seem to have lost the advances in computer
>>> graphics that were already known 50 years ago. The Alto, even
>>> though it was only a 16-bit computer running at 6 MHz, could
>>> easily do smooth scrolling over its entire display (606 x 808
>>> pixels, IIRC). It did this by using a display list of regions
>>> (horizontal strips of varying widths) rather than a simple frame
>>> buffer. Because the display list was an actual linked list, it
>>> was easy to prepare a new list and simply link it in at the
>>> appropriate moment. Temporal fidelity was achieved by switching
>>> in a new display list at a time when a vertical retrace was
>>> occurring; no glitches, ever.
>>
>> This was of course the HW way to do it back when keeping a
>> megapixel screen updated at 60 Hz was _hard_.
>>
>> In the code I mentioned above (a terminal emulator in fact, which
>> needed to do all the windowed scrolling operations supported by
>> VT52/VT100/VT220/NORD/etc terminals I did use a linked list memory
>> store for the frame buffer, with separate dirty flags for each
>> element. Back in those days all frame buffer writes had to be
>> synced to either horizontal (very short!) or vertical retrace, but
>> even the vertical retrace didn't last long enough to update
>> everything in one go afair, so my full screen update code would
>> use both to get done asap.
>
> If the frame buffer is represented as a linked list, why not
> just make up a new linked list and change the top-level link
> during the vertical retrace? Surely changing the one link
> could be done in the time it takes to do a vertical retrace.
>
>>> It would be nice if modern machines and operating systems could
>>> provide a comparable high-performance graphics capability, with
>>> the same level of temporal fidelity, as the Alto did almost 50
>>> years ago. Alas, the scourge of frame buffers and rudimentally
>>> designed windowing systems has put us in a world where, to use a
>>> phrase, glitches happen.
>>
>> For most stuff it doesn't matter,
>
> I find this attitude reprehensible, especially coming from
> someone as capable as you are. There is no reason in this day
> and age to tolerate shitty software. Certainly there are things
> about Apple that I don't like, but when it comes to software
> quality developers should strive to be more like Apple and less
> like Microsoft.

Tim, we are really in violent agreement, it is just that either I am
older than you, or I have given up fixing this before you did.
>
>> and when it does matter, then we just throw a full GPU at
>> at. :-)
>
> This one too. It's ridiculous to pay $1000 for a solution when
> there is another way of solving the same problem that costs less
> than $10. Equally ridiculous is needing GB/sec of bandwidth in
> cases where MB/sec would do. Or web pages that load multiple
> megabytes to display only a few thousand bytes of content. These
> excesses, and others like them, must be fought at every level.
>
Having written some of the most performance-critical code in use today,
I strongly agree. However, I have found that I need to pick my battles
to the places where it still really matters.
:-(

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> On 12/5/2022 5:21 AM, Anton Ertl wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>
> snip
>
>>> If the more popular
>>> languages that replaced COBOL had good support for fixed decimal, I
>>> suspect that might have won out over binary floating point (especially
>>> if there was some hardware support).
>>
>> The main successor for COBOL seems to be Java.
>
> That is true now, but by the time of Java's ascendancy, the die had
> already been cast. The immediate successor to COBOL as the primary
> language for business applications was C.

Really? Do you mean hand-crafted business applications (which were
later often replaced by SAP), or as the language for implementing
things like spreadsheets?

C was certainly in wide use among computer scientists, especially
in the UNIX field, and engineers also used it a lot after FORTRAN
had fallen behind too much, but for business?

Thomas Koenig <tkoenig@netcologne.de> writes:
>Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> On 12/5/2022 5:21 AM, Anton Ertl wrote:
>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>
>> snip
>>
>>>> If the more popular
>>>> languages that replaced COBOL had good support for fixed decimal, I
>>>> suspect that might have won out over binary floating point (especially
>>>> if there was some hardware support).
>>>
>>> The main successor for COBOL seems to be Java.
>>
>> That is true now, but by the time of Java's ascendancy, the die had
>> already been cast. The immediate successor to COBOL as the primary
>> language for business applications was C.
>
>Really? Do you mean hand-crafted business applications (which were
>later often replaced by SAP), or as the language for implementing
>things like spreadsheets?

Not really. The successor to COBOL is COBOL, or 4GL's like SAP.

On 12/19/2022 9:06 AM, Thomas Koenig wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> On 12/5/2022 5:21 AM, Anton Ertl wrote:
>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>
>> snip
>>
>>>> If the more popular
>>>> languages that replaced COBOL had good support for fixed decimal, I
>>>> suspect that might have won out over binary floating point (especially
>>>> if there was some hardware support).
>>>
>>> The main successor for COBOL seems to be Java.
>>
>> That is true now, but by the time of Java's ascendancy, the die had
>> already been cast. The immediate successor to COBOL as the primary
>> language for business applications was C.
>
> Really? Do you mean hand-crafted business applications (which were
> later often replaced by SAP), or as the language for implementing
> things like spreadsheets?

Some of each, and as the language for implementing things like
commercial accounting packages for GL/AP/AR, etc., particularly on
mini-computers and even micros where COBOL compilers were either not
available, or of terrible quality, or perhaps just to much to implement
reasonably on the smaller hardware.

> C was certainly in wide use among computer scientists, especially
> in the UNIX field, and engineers also used it a lot after FORTRAN
> had fallen behind too much, but for business?

Not so much on mainframes, but as smaller companies realized they could
use a lower cost mini for their business needs.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> On 12/19/2022 9:06 AM, Thomas Koenig wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>>> On 12/5/2022 5:21 AM, Anton Ertl wrote:
>>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>>
>>> snip
>>>
>>>>> If the more popular
>>>>> languages that replaced COBOL had good support for fixed decimal, I
>>>>> suspect that might have won out over binary floating point (especially
>>>>> if there was some hardware support).
>>>>
>>>> The main successor for COBOL seems to be Java.
>>>
>>> That is true now, but by the time of Java's ascendancy, the die had
>>> already been cast. The immediate successor to COBOL as the primary
>>> language for business applications was C.
>>
>> Really? Do you mean hand-crafted business applications (which were
>> later often replaced by SAP), or as the language for implementing
>> things like spreadsheets?
>
> Some of each, and as the language for implementing things like
> commercial accounting packages for GL/AP/AR, etc., particularly on
> mini-computers and even micros where COBOL compilers were either not
> available, or of terrible quality, or perhaps just to much to implement
> reasonably on the smaller hardware.

C as mostly coupled to UNIX in the first years of its existence,
I believe, and UNIX was very much in use at universities, less
so elsewhere.

The minicomputers running business applications were, of course,
the midrange IBM systems (certainly not C, rather RPG or Cobol),
Data General machines, DEC (PDP-11, VAX), Prime. I think these
mostly had FORTRAN, Cobol, Algol, Pascal, BASIC etc, from the 1970s
and early 1980s.

C compilers for non-UNIX systems started appearing in the 1980s,
I believe. The first C compiler for PCs was Lattice C, released
in 1982.

>> C was certainly in wide use among computer scientists, especially
>> in the UNIX field, and engineers also used it a lot after FORTRAN
>> had fallen behind too much, but for business?
>
> Not so much on mainframes, but as smaller companies realized they could
> use a lower cost mini for their business needs.

Sure, but programming it in C? Just what importance did UNIX
systems have in business in the 1970s and early 1980s, before
the PC really took off?

Thomas Koenig <tkoenig@netcologne.de> writes:
>Just what importance did UNIX
>systems have in business in the 1970s and early 1980s, before
>the PC really took off?

In 1991 I worked in a small company that did business applications;
the customers got a Unix server and a bunch of terminals and the
software from this company. The software was written in C and used
IIRC Oracle as database. However, this was not replacing Cobol
software, but instead mostly non-computerized processes. Replacing
the terminals with PCs would have been more expensive and would not
have added value; replacing the Unix box with a Windows 3.1 system
would probably also have been a bad idea, because Windows 3.1 is not a
multi-user system.

Some years later (after I had left) they were doing Java.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Tuesday, December 20, 2022 at 12:09:31 PM UTC+2, Anton Ertl wrote:
> Thomas Koenig <tko...@netcologne.de> writes:
> >Just what importance did UNIX
> >systems have in business in the 1970s and early 1980s, before
> >the PC really took off?
> In 1991 I worked in a small company that did business applications;
> the customers got a Unix server and a bunch of terminals and the
> software from this company. The software was written in C and used
> IIRC Oracle as database. However, this was not replacing Cobol
> software, but instead mostly non-computerized processes. Replacing
> the terminals with PCs would have been more expensive and would not
> have added value;

What sort of terminals was cheaper in 1991 than 386SX PC with VGA and 640 KB RAM?
I remember IBM's lower-end X-terminals from this era. Their displays were hard to
read even for my young eyes of then. And still I am not sure that they were cheap.
May be, a little cheaper than PC like above + Ethernet NIC. Or, may be, not cheaper.

> replacing the Unix box with a Windows 3.1 system
> would probably also have been a bad idea, because Windows 3.1 is not a
> multi-user system.
>

You don't need multi-user OS for server side of client-server app.

> Some years later (after I had left) they were doing Java.

Likely, for medium+ firms rather than for small-to-medium.

> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>What sort of terminals was cheaper in 1991 than 386SX PC with VGA and 640 KB RAM?

Something VT220 or VT320 compatible. I don't remember the exact
price, but the terminals cost around ATS 10K (~EUR 700). A 486 PC I
bought in 1993 cost ATS 40K, with a hard disk costing ATS 5K. In 1991
I don't think you could get a PC with screen, keyboard and HDD for ATS
10K. However, 10base2 cabling is cheaper than a RS232 star topology.

>I remember IBM's lower-end X-terminals from this era.

X-Terminals are a different kettle of fish.

>Their displays were hard to
>read even for my young eyes of then.

I used to work on an NCD X-Terminal, which had nice screens for the
time; while my PC from 1993 had a 14" colour sceen with IIRC up to
1024x768 resolution, the NCD X-Terminals from around the same time had
a 19" B&W screen with 1280x1024 resolution.

>And still I am not sure that they were cheap.

Of course they were not. IBM does not sell cheap equipment; at least
not cheap for their customers.

>> replacing the Unix box with a Windows 3.1 system
>> would probably also have been a bad idea, because Windows 3.1 is not a
>> multi-user system.
>>
>
>You don't need multi-user OS for server side of client-server app.

That would mean replacing the terminals with more versatile clients
(e.g., PCs), more expensive.

>> Some years later (after I had left) they were doing Java.
>
>Likely, for medium+ firms rather than for small-to-medium.

I don't know who the customers were in the Java times. My impression
from the time when I worked for them was that a project they worked a
lot on use about 20 terminals (which was more than usual), and that
most of the employees of the company would be using this system (so
they had a head count of maybe 30 people).

My guess is that they kept their customers, and switched the
technology to using Java (probably also networked PC at that time,
terminals were no longer competetive, but I have no information from
the company about that).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 12/20/2022 3:09 AM, Michael S wrote:
> On Tuesday, December 20, 2022 at 12:09:31 PM UTC+2, Anton Ertl wrote:
>> Thomas Koenig <tko...@netcologne.de> writes:
>>> Just what importance did UNIX
>>> systems have in business in the 1970s and early 1980s, before
>>> the PC really took off?
>> In 1991 I worked in a small company that did business applications;
>> the customers got a Unix server and a bunch of terminals and the
>> software from this company. The software was written in C and used
>> IIRC Oracle as database. However, this was not replacing Cobol
>> software, but instead mostly non-computerized processes. Replacing
>> the terminals with PCs would have been more expensive and would not
>> have added value;
>
> What sort of terminals was cheaper in 1991 than 386SX PC with VGA and 640 KB RAM?

I think there were still what we used to call "glass teletypes"
available. These were basically a keyboard and a character oriented
screen, an RS232 serial port and whatever minimal hardware logic to
connect them all, certainly a lot less than a 386SX. No user
programmability. IIRC, they were in the hundreds of US dollars.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 12/20/2022 2:00 AM, Anton Ertl wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>> Just what importance did UNIX
>> systems have in business in the 1970s and early 1980s, before
>> the PC really took off?
>
> In 1991 I worked in a small company that did business applications;
> the customers got a Unix server and a bunch of terminals and the
> software from this company. The software was written in C and used
> IIRC Oracle as database. However, this was not replacing Cobol
> software, but instead mostly non-computerized processes. Replacing
> the terminals with PCs would have been more expensive and would not
> have added value; replacing the Unix box with a Windows 3.1 system
> would probably also have been a bad idea, because Windows 3.1 is not a
> multi-user system.
>
> Some years later (after I had left) they were doing Java.

Yes. That is an excellent example of one of the kind of things I was
talking about.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 12/20/2022 10:14 AM, Stephen Fuld wrote:
> On 12/20/2022 3:09 AM, Michael S wrote:
>> On Tuesday, December 20, 2022 at 12:09:31 PM UTC+2, Anton Ertl wrote:
>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>> Just what importance did UNIX
>>>> systems have in business in the 1970s and early 1980s, before
>>>> the PC really took off?
>>> In 1991 I worked in a small company that did business applications;
>>> the customers got a Unix server and a bunch of terminals and the
>>> software from this company. The software was written in C and used
>>> IIRC Oracle as database. However, this was not replacing Cobol
>>> software, but instead mostly non-computerized processes. Replacing
>>> the terminals with PCs would have been more expensive and would not
>>> have added value;
>>
>> What sort of terminals was cheaper in 1991 than 386SX PC with VGA and
>> 640 KB RAM?
>
> I think there were still what we used to call "glass teletypes"
> available.  These were basically a keyboard and a character oriented
> screen, an RS232 serial port and whatever minimal hardware logic to
> connect them all, certainly a lot less than a 386SX.  No user
> programmability.  IIRC, they were in the hundreds of US dollars.
>

There is still a lot of stuff around that assumes VT102 behavior, ASCII
+ ANSI escape sequences, ... Also some amount of "Sixel" graphics (for
sending graphics over an ASCII terminal link).

I would assume at one point, these sorts of terminals were relatively
popular.

Albeit, I never encountered any of these personally...

....

MitchAlsup <MitchAlsup@aol.com> writes:

> On December 17, 2022 at 10:32:14 AM UTC-6, Tim Rentsch wrote:
>
>> Terje Mathisen <terje.m...@tmsw.no> writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.m...@tmsw.no> writes:

[.. speed of graphics operations ..]

>>>>> I discovered this by measuring it around 1983/84, which is when
>>>>> I switched my own programs to use a memory block as a shadow
>>>>> frame buffer, only copying any updates to the real screen, and
>>>>> only when I had a few spare milliseconds to do so. I.e. on a
>>>>> quickly scrolling screen I might not update every single line.
>>>>
>>>> It's sad that we seem to have lost the advances in computer
>>>> graphics that were already known 50 years ago. The Alto, even
>>>> though it was only a 16-bit computer running at 6 MHz, could
>>>> easily do smooth scrolling over its entire display (606 x 808
>>>> pixels, IIRC). It did this by using a display list of regions
>>>> (horizontal strips of varying widths) rather than a simple frame
>>>> buffer. Because the display list was an actual linked list, it
>>>> was easy to prepare a new list and simply link it in at the
>>>> appropriate moment. Temporal fidelity was achieved by switching
>>>> in a new display list at a time when a vertical retrace was
>>>> occurring; no glitches, ever.
>>>
>>> This was of course the HW way to do it back when keeping a
>>> megapixel screen updated at 60 Hz was _hard_.
>>>
>>> In the code I mentioned above (a terminal emulator in fact, which
>>> needed to do all the windowed scrolling operations supported by
>>> VT52/VT100/VT220/NORD/etc terminals I did use a linked list memory
>>> store for the frame buffer, with separate dirty flags for each
>>> element. Back in those days all frame buffer writes had to be
>>> synced to either horizontal (very short!) or vertical retrace, but
>>> even the vertical retrace didn't last long enough to update
>>> everything in one go afair, so my full screen update code would
>>> use both to get done asap.
>>
>> If the frame buffer is represented as a linked list, why not
>> just make up a new linked list and change the top-level link
>> during the vertical retrace? Surely changing the one link
>> could be done in the time it takes to do a vertical retrace.
>>
>>>> It would be nice if modern machines and operating systems could
>>>> provide a comparable high-performance graphics capability, with
>>>> the same level of temporal fidelity, as the Alto did almost 50
>>>> years ago. Alas, the scourge of frame buffers and rudimentally
>>>> designed windowing systems has put us in a world where, to use a
>>>> phrase, glitches happen.
>>>
>>> For most stuff it doesn't matter,
>>
>> I find this attitude reprehensible, especially coming from
>> someone as capable as you are. There is no reason in this day
>> and age to tolerate shitty software.
>
> a) I applaud the suggestion that no one should accept shitty SW
> b) There is the package known as Windows that fits your description
> ....of shitty

Much of the blame for current attitudes towards software falls on
Microsoft, even before MS Windows. If there there such a thing
as a negative Nobel Prize, Bill Gates deserves one. Or more than
one.

> c) every web browser shovels shit at you in the form of advertising.
> d) even adblockers are getting to the point of selectively shoveling
> ....you shit
> So, while the premises good, there is no escape from shit in SW.

I don't like advertising any better than you do, but that's a
problem with content, not software.

>> Certainly there are things about Apple that I don't like, but when
>> it comes to software quality developers should strive to be more
>> like Apple and less like Microsoft.
>>
>>> and when it does matter, then we just throw a full GPU at
>>> at. :-)
>>
>> This one too. It's ridiculous to pay $1000 for a solution when
>> there is another way of solving the same problem that costs less
>> than $10. Equally ridiculous is needing GB/sec of bandwidth in
>> cases where MB/sec would do. Or web pages that load multiple
>> megabytes to display only a few thousand bytes of content. These
>> excesses, and others like them, must be fought at every level.
>
> I think I would settle for delivering the pages content first, and
> shoveling the advertisements later.

Try the add-on Reader View. I started using it recently and it is
fantastic. Pages don't load any faster (?) but the result is
pleasantly stripped of almost all extraneous junk.

> But then again, you can't buy a PC that does not already come
> with a GPU built in (at a cost so low you don't see it).

Terje said full GPU, not any run-of-the-mill GPU.

In any case I don't see that GPUs solve the problem. I use
so-called "smooth scrolling" in my browser, and it's really lame.
During scrolling the text is both jerky and blurry. I don't know
the details but I suspect the interface to the graphics systems
simply doesn't support the necessary operations. Inexcusable.

BGB wrote:
> On 12/20/2022 10:14 AM, Stephen Fuld wrote:
>> On 12/20/2022 3:09 AM, Michael S wrote:
>>> On Tuesday, December 20, 2022 at 12:09:31 PM UTC+2, Anton Ertl wrote:
>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>> Just what importance did UNIX
>>>>> systems have in business in the 1970s and early 1980s, before
>>>>> the PC really took off?
>>>> In 1991 I worked in a small company that did business applications;
>>>> the customers got a Unix server and a bunch of terminals and the
>>>> software from this company. The software was written in C and used
>>>> IIRC Oracle as database. However, this was not replacing Cobol
>>>> software, but instead mostly non-computerized processes. Replacing
>>>> the terminals with PCs would have been more expensive and would not
>>>> have added value;
>>>
>>> What sort of terminals was cheaper in 1991 than 386SX PC with VGA and
>>> 640 KB RAM?
>>
>> I think there were still what we used to call "glass teletypes"
>> available.  These were basically a keyboard and a character oriented
>> screen, an RS232 serial port and whatever minimal hardware logic to
>> connect them all, certainly a lot less than a 386SX.  No user
>> programmability.  IIRC, they were in the hundreds of US dollars.
>>
>
> There is still a lot of stuff around that assumes VT102 behavior, ASCII
> + ANSI escape sequences, ... Also some amount of "Sixel" graphics (for
> sending graphics over an ASCII terminal link).
>
>
> I would assume at one point, these sorts of terminals were relatively
> popular.
>
> Albeit, I never encountered any of these personally...

Our original mountain cabin in Telemark was paid for with my
VT100/52/220/etc terminal emulator for the PC. For a number of years it
was probably #4 on the list of best-selling Norwegian software (measured
in # of licenses). I.e. in the 1980'ies and early 90'ies there was a
large market for such SW. :-)

One of the big issues with VT100 emulation was that you needed to be
bug-for-bug compatible, esp in the face of non-conforming escape
sequences. To make it fast enough while still being able to parse
partially received sequences I re-invented co-routines, so that the
emulation part was a separate deeply nested set of parsers for each
possible type of sequence. These would just call the "get next char"
routine which would yield when the buffer was empty.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>Michael S <already5chosen@yahoo.com> writes:
>>What sort of terminals was cheaper in 1991 than 386SX PC with VGA and 640 KB RAM?
>
>Something VT220 or VT320 compatible. I don't remember the exact
>price, but the terminals cost around ATS 10K (~EUR 700). ...

Wikipedia says a DEC VT320 cost $495 in the late 1980s. You couldn't
get a computer for anything close to that.

>>> replacing the Unix box with a Windows 3.1 system
>>> would probably also have been a bad idea, because Windows 3.1 is not a
>>> multi-user system.
>>
>>You don't need multi-user OS for server side of client-server app.
>
>That would mean replacing the terminals with more versatile clients
>(e.g., PCs), more expensive. ...

In the 1980s I was using a shared database running on a DOS PC with other
DOS PCs on a thin coax Ethernet as the clients. It worked fine but as you
say, dumb terminals would have been cheaper but we'd have needed a more
capable server.