OT: horrible 8086 segmentation

On 25.11.24 18:33, mm0fmf wrote: [...]

And to consider that, at that time, processors like MC68000 or NS32016 were readily available.

Josef

Which proves once again that a s***ty design beats a good one if it's released first.

Everybody was yapping about the 640K barrier. I was more concerned with the 64K barrier. I remember manually normalizing pointers everywhere, and if I wanted to work with a large arrays of structures I'd copy individual structures to a work area byte by byte so I didn't get bitten by segment wrap-around in the middle of a structure.

As the joke goes, aren't you glad the iAPX432 died out? Otherwise a truly horrible Intel architecture might have taken over the world.

I found this when digging around...

"void KERNELsetvect(unsigned wVec, void far *pVect) { void far * far *pPtr ;

pPtr = (void far * far *) MK_FP(0x0000, wVec << 2) ; *pPtr = pVect ; }"

It simply looks so ugly.

ISTR trying to push to use 68000 or even 68E020 but 80186EB became the CPU of choice. It had lots of nice embedded features on chip and ran at

It's 26 years since I had to deal with this segmented rubbish and a lot of it I had forgotten or repressed!

Backwards compatibility. DOS came from 8080 based CP/M , to run on an 8086, to where 8 bit code could be easily ported.

And so we were stick with that architecture.

A prime example off 'mass marketing always wins over excellence'

and 'nothing succeeds like success'

Intel put the "backward" in "backward compatible".

At the time when the design decision was made, the Motorola 68000 was not ready for production.

From

"The 68000 was considered the best choice,[19] but was not production-ready like the others."

I also remember a zilog Z8000?

Yes, although also with a segmented memory model.

Its segmentation scheme made Intel x86 look good.

I recall the term “backward combatible” used to describe the feelings of violence some people had towards the requirement for backward compatibility with certain kinds of brain death ...

Then there's "bug-compatible", where so many people and systems have adapted to an existing bug that you can't fix it without breaking just about everything - so any future versions have to also contain the bug, or at least a good emulation of it.

If at first you don't succeed, you might as well forget it.

Qwerty keyboards being a prime example.

Bah, and indeed Humbug.

I remember Byte magazine did an in-depth study of typing speed, involving both theoretical analyses and actual measurements using video cameras on the hands of people as they typed, comparing QWERTY and Dvorak layouts.

Their conclusion: there was no significant efficiency improvement in switching to Dvorak.

Not that unusual. Compare to some of the Microchip PICs. Some have really bizarre bank switching arrangements and so on.

I think the Apple II RAM expansion card worked by switching to a different bank (48K each?) every time a particular control register byte was written. You couldn’t just write a bank number: instead, you had to repeat the write N number of times, and I guess remember where you started from, to get to the right bank.

But this was because the CPU itself only supported 16-bit addressing. What was Zilog’s excuse?

Apple sold three memory expansion cards for the (8-bit) Apple II’s: the

Many other manufacturers offered cards of various capacities emulating the architecture of each of Apple’s cards.

I know of no expansion card that required multiple control byte accesses to select a particular bank.

Instead the bank value was stored in a control register, but this was only for third-party cards with more than one additional bank. Since Apple never shipped such a card, different manufacturers did not all choose the same control byte address, nor did they interpret the control value the same way.

Apple set the standard and a large number of applications used it. The third-party extensions were supported by a smaller group of applications, sometimes by design and sometimes by patches to applications.

BTW, banks were switched in selectively for reading or writing, so copying data from one bank to another or executing code that wrote to another bank was quite easy.

Some of the Z80 CPM cards for the Apple II had memory. Some had just 64k and the II's RAM was used for disk buffers and such. I'm sure my CPM 3 card had a 6MHz Z80 and 192k of RAM but it's 41 years ago since I last used one and my memory is vague now.

The Atari 7800 console did bank switching on the ROM cartridge as there was only 4K memory space. You hit the bank switch register and the next