Raspberry Pi relevance : I'm writing some Pi Pico code


I was doing some head scratching when I remembered I'd written something
very similar in the distant past to what I was doing. I had to dig
through piles of CD-Rs to find the one with the backups on from all
those years back. It still reads fine, 21st July 1998 is the date on the
CD. 26 years old.

Anyway, I've pulled the files from it on to the wee Linux machine for
updating and use in the project. There's a date in the header saying
"created 1993" and last changes were "16th July 1996". I was just
starting to go bald then!

I've been rummaging through this old CD-R looking at what I was up to
all those years ago and found all sorts of horrible 8086 segmentation management in the C code

e.g.
"
// start of barrel
EventRec far* searchp = (EventRec far*) work.bufs;

"


My eyes! My eyes! That was COMPACT model code, so 64k of code and 1MB of
data, code addresses were 16bit offsets to the CS reg and data was far
so 32 bits of segment and offset of DS or ES. And of course you had to
be extra careful of any pointer arithmetic as a far pointer wrapped
after 64k. You had to use slower HUGE pointers to get automatic
normalisation. God it was shit.

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

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

e.g.
"
    // start of barrel
    EventRec far* searchp = (EventRec far*) work.bufs;

"

My eyes! My eyes! That was COMPACT model code, so 64k of code and 1MB of data, code addresses were 16bit offsets to the CS reg and data was far
so 32 bits of segment and offset of DS or ES. And of course you had to
be extra careful of any pointer arithmetic as a far pointer wrapped
after 64k. You had to use slower HUGE pointers to get automatic normalisation. God it was shit.

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

Josef

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

On 2024-11-26, Josef Möllers <josef@invalid.invalid> wrote:

On 25.11.24 18:33, mm0fmf wrote:

My eyes! My eyes! That was COMPACT model code, so 64k of code and 1MB of
data, code addresses were 16bit offsets to the CS reg and data was far
so 32 bits of segment and offset of DS or ES. And of course you had to
be extra careful of any pointer arithmetic as a far pointer wrapped
after 64k. You had to use slower HUGE pointers to get automatic
normalisation. God it was shit.

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

Which proves once again that a shitty 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.

--
/~\ 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 26/11/2024 18:50, Charlie Gibbs wrote:

On 2024-11-26, Josef Möllers <josef@invalid.invalid> wrote:

On 25.11.24 18:33, mm0fmf wrote:

My eyes! My eyes! That was COMPACT model code, so 64k of code and 1MB of >>> data, code addresses were 16bit offsets to the CS reg and data was far
so 32 bits of segment and offset of DS or ES. And of course you had to
be extra careful of any pointer arithmetic as a far pointer wrapped
after 64k. You had to use slower HUGE pointers to get automatic
normalisation. God it was shit.

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

Which proves once again that a shitty 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
20MHz. And you could use PC development tools.

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

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

On 26/11/2024 17:37, Josef Möllers wrote:

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

e.g.
"
     // start of barrel
     EventRec far* searchp = (EventRec far*) work.bufs;

"


My eyes! My eyes! That was COMPACT model code, so 64k of code and 1MB
of data, code addresses were 16bit offsets to the CS reg and data was
far so 32 bits of segment and offset of DS or ES. And of course you
had to be extra careful of any pointer arithmetic as a far pointer
wrapped after 64k. You had to use slower HUGE pointers to get
automatic normalisation. God it was shit.

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

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'



--
Labour - a bunch of rich people convincing poor people to vote for rich
people by telling poor people that "other" rich people are the reason
they are poor.

Peter Thompson

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

On 2024-11-27, The Natural Philosopher <tnp@invalid.invalid> wrote:

On 26/11/2024 17:37, Josef Möllers wrote:

On 25.11.24 18:33, mm0fmf wrote:

My eyes! My eyes! That was COMPACT model code, so 64k of code and 1MB
of data, code addresses were 16bit offsets to the CS reg and data was
far so 32 bits of segment and offset of DS or ES. And of course you
had to be extra careful of any pointer arithmetic as a far pointer
wrapped after 64k. You had to use slower HUGE pointers to get
automatic normalisation. God it was shit.

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

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.

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

--
/~\ 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 Tue, 26 Nov 2024 18:37:02 +0100, Josef M�llers
<josef@invalid.invalid> wrote:

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

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

From https://en.wikipedia.org/wiki/IBM_Personal_Computer :

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

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

On 01/12/2024 13:29, Robert Roland wrote:

On Tue, 26 Nov 2024 18:37:02 +0100, Josef Möllers
<josef@invalid.invalid> wrote:

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

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

From https://en.wikipedia.org/wiki/IBM_Personal_Computer :

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

I also remember a zilog Z8000?


--
“The ultimate result of shielding men from the effects of folly is to
fill the world with fools.”

Herbert Spencer

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

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

Robert Roland wrote:

On Tue, 26 Nov 2024 18:37:02 +0100, Josef Möllers
<josef@invalid.invalid> wrote:

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

At the time when the design decision was made, the Motorola 68000 was
not ready for production.
From https://en.wikipedia.org/wiki/IBM_Personal_Computer :
"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.

--
https://www.greenend.org.uk/rjk/

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