Re: GIMP 3.0.0-RC1

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.

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.