On Sun, 01 Dec 2024 15:11:05 +0000, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

I also remember a zilog Z8000?

Yes, although also with a segmented memory model.

Its segmentation scheme made Intel x86 look good.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Thu, 28 Nov 2024 19:42:18 GMT, Charlie Gibbs wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2024-12-18, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 28 Nov 2024 19:42:18 GMT, Charlie Gibbs wrote:

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

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.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Wed, 18 Dec 2024 18:02:34 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

On 2024-12-18, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 28 Nov 2024 19:42:18 GMT, Charlie Gibbs wrote:

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

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.

Qwerty keyboards being a prime example.


Bah, and indeed Humbug.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Wed, 18 Dec 2024 20:33:27 +0000, Kerr-Mudd, John wrote:

Qwerty keyboards being a prime example.

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 18/12/2024 06:22, Lawrence D'Oliveiro wrote:

On Sun, 01 Dec 2024 15:11:05 +0000, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

I also remember a zilog Z8000?

Yes, although also with a segmented memory model.

Its segmentation scheme made Intel x86 look good.

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

--
Brian Gregory (in England).

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Mon, 23 Dec 2024 03:26:11 +0000, Brian Gregory wrote:

On 18/12/2024 06:22, Lawrence D'Oliveiro wrote:

On Sun, 01 Dec 2024 15:11:05 +0000, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

I also remember a zilog Z8000?

Yes, although also with a segmented memory model.

Its segmentation scheme made Intel x86 look good.

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?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Mon, 23 Dec 2024 03:26:11 +0000, Brian Gregory wrote:

On 18/12/2024 06:22, Lawrence D'Oliveiro wrote:

On Sun, 01 Dec 2024 15:11:05 +0000, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

I also remember a zilog Z8000?

Yes, although also with a segmented memory model.

Its segmentation scheme made Intel x86 look good.

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
16KB Language card that allowed bank switching RAM in place of the built-in BASIC ROM, and (later for the Apple IIe) the 64KB Memory Expansion card for
the Apple IIe that allowed bank switching in a second 64KB of RAM bank
switched over the built-in 64KB (both were further bank switched the same
way as a 48KB Apple II equipped with a Language Card), and finally, the “slinky”-style 256KB - 1 MB card that was not bank switched, but supported sequential reads or writes through an autoincremented register set up by
the programmer (used primarily as a RAM disk).

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.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 24/12/2024 08:24, Michael J. Mahon wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Mon, 23 Dec 2024 03:26:11 +0000, Brian Gregory wrote:

On 18/12/2024 06:22, Lawrence D'Oliveiro wrote:

On Sun, 01 Dec 2024 15:11:05 +0000, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

I also remember a zilog Z8000?

Yes, although also with a segmented memory model.

Its segmentation scheme made Intel x86 look good.

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 16KB Language card that allowed bank switching RAM in place of the built-in BASIC ROM, and (later for the Apple IIe) the 64KB Memory Expansion card for the Apple IIe that allowed bank switching in a second 64KB of RAM bank switched over the built-in 64KB (both were further bank switched the same
way as a 48KB Apple II equipped with a Language Card), and finally, the “slinky”-style 256KB - 1 MB card that was not bank switched, but supported
sequential reads or writes through an autoincremented register set up by
the programmer (used primarily as a RAM disk).

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
4K chunk of ROM was mapped and you continued executing at the next
address in the ROM. You had to remember which bank was mapped and you
could only move forward 1 bank at a time. Cue interesting routines to
switch to an arbitrary bank. 1988 when I last wrote stuff for one of them.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)