Re: GIMP 3.0.0-RC1

On 2/12/25 1:50 PM, rbowman wrote:

On Wed, 12 Feb 2025 12:25:17 -0500, WokieSux282@ud0s4.net wrote:
 

    I think the 86 series had 'more future possibilities'
    than the 8085. There were too many 8-bit systems out there already,
    so bumping up to 16 bit was smart for sales. Why make/compete-with
    "just another TRS-80" ?

 16/32 bit processors were in the air so it would make no sense to stay
with 8 bits.
 https://spectrum.ieee.org/the-inside-story-of-texas-instruments-biggest-
blunder-the-tms9900-microprocessor
 That covers the ground from a slightly different perspective, a TI
engineer. It's interesting to speculate on IBM's view of future
possibilities. A large part of the company didn't think there was a
future. Intel thought the 432 was the future but that fell on its face.
Using the 8088 solved the peripherals problem but it also meant the
performance wasn't better than a Z80. Z80 designs were already doing bank
switching. The 8088 just had the additional registers to implement it.
 The TMS9900 wasn't a bad chip, if a little odd if you came from the Intel/
Zilog world. I worked with it on one project. Because of TI's roots they
had a rad hard version
 https://retrocomputingforum.com/t/the-texas-instruments-tms-9900-
microprocessor/1370
 That's a good description of the oddities.

   I did a little ASM for the 9900. It *was* a bit 'odd'
   however. Register-sets-in-RAM was unique, but it
   facilitated multi-user. Everybody remembers the PC,
   but the real intended use of the chip was in the 990
   mini-computer, where multi-user/tasking was a must.
   Actual hardware support for that, weird.
   Branch and Load Workspace Pointer .......
   Anyway, TI flubbed it and another early 16-bitter
   went down the toilet.
   There were a LOT of 'concept chips' back around the
   same time when 16+ bits was becoming real. Everyone
   was sure they had the Better Idea. Now, you might
   maybe find one in a surplus parts bin. (had a dream
   once about finding a TMS9900 - white with gold pins -
   in a surplus bin)

The first article points out the IBM was big-endian and suddenly thy were
transported into the little-endian world. Our legacy software uses ONC-RPC
which handle the byte order. Originally the system ran on RS6000 machines
where the reshuffling was a NOOP. As we started using Linux in house for
development, the x86 machines had to reverse the canonical big-endian
data. No problem. Then our clients moved to Windows while we still used
Linux leading to the absurdity of dual processing to move little-endian to
big-endian and back to little-endian.
 All that is hidden in the RPC code but it becomes explicit when you find
yourself using htonl, ntohl, and friends when building a socket
connection.

   There were some dual-chip jobbbies, bet-hedging.
   One TRS-80 could be had with a 68k board that
   ran CP/M-68k and as I recall the C128 had both
   a 65xx upgrade plus a Z80 that'd run CP/M.
   Dealing with big/small-endian ... that could get
   a bit confusing jumping back and forth between
   platforms. Made some boards with both a Rabbit
   and PIC on them and would find myself typing PIC
   instructions into the bunny and vice-versa sometimes :-)