PDOS for Amiga

[meynaf]

Originally Posted by kerravon

It wasn't a poor design, it was the exact correct technical solution to allow 16-bit applications to access more than 64k of memory. It could have been repeated when we had 32-bit applications running on machines with 8 GiB of memory, but instead CPUs evolved to be able to cope with different modes.

It looks good only on paper. In real life, it has been a pita for everyone having to code for it. So yes it was a poor design.

Originally Posted by kerravon

If, as above, you had 32-bit applications running on an 8 GiB machine, then a "tiny" mode application could potentially be occupying the memory range 3 GiB to 7 GiB and be considered "tiny".

No. 4GiB isn't "tiny". As more than 99.9% of apps don't actually use more than that amount, even today with the current large waste we have.
The situation you describe isn't realistic, as with paged systems the 64-bit machine won't be allocating "3 to 7 GiB" to a 32-bit program...

Originally Posted by kerravon

It is the programmer, not the user, who chooses a memory model, and a standard C90 program works, completely unchanged - no need for "near" and "far" pointers.

The programmer can in some situations be seen as the user
But no, the C90 program won't work completely unchanged - or if it does, it will be at the price of horrible performance costs.

Originally Posted by kerravon

My interest is in understanding computer science thoroughly so that if I am transported back in time to 1983, working on an MSDOS system, I know what to advise programmers.

Are you conscious that you will not be transported back in 1983 ?

Originally Posted by kerravon

Sorry, I don't understand. If you have 9-bit chars and you go:

char *x;

*x = 0xab;

you have successfully defined a pointer suitable to manipulating a byte, and then manipulated it.

No. It will not work.
First, char is never 9-bit. What is sizeof(char) if it's 9-bit ?? If 1 then it can't be 9-bit, only 8. If 2, then it's 16-bit with 7 bits wasted.
So, could be 16. But then if you do "*x" you access two bytes, not just one.

Originally Posted by kerravon

I doubt that copying 25*80*2 bytes from one area of memory to another using memcpy() takes a long time, even on a 4.77 MHz 8086. And it will only take place between user interactions. The memcpy() needs to be faster than a monkey pressing a key for the monkey to even be able to detect it.

So you system is for monkeys, i see. Then perhaps you should be informed that monkeys can't read text.

Originally Posted by kerravon

The problem as I see it is that if you have a fullscreen text application, and you have drawn screen A, and because of your complicated ANSI controls, to replace screen A with screen B (which may have included a clear screen operation), then the user may be able to see the screen being drawn in say 0.3 seconds and that may look crap and that's why people preferred to directly manipulate the memory at 0xb8000.

So a memcpy even on old 8086 doesn't take much time but complicated ANSI codes do ?

Originally Posted by kerravon

But if the transition from screen A to screen B also involved some application logic, perhaps a disk access, then that entire 0.3 seconds will simply be added to the application pause time, and the screen update will look like it has been instantly updated.

Congratulations, now you're freezing everything during disk accesses.

Originally Posted by kerravon

I would like to see my screen replaced immediately rather than observe the redrawing process. Note that this is only for fullscreen applications which would be signified by setvbuf(stdout, fully-buffered).

Have you really observed such a redrawing process (for a text-only app) or is it just a theory ?

Originally Posted by kerravon

Time machine to take us back to 1983 sold separately. :-)

In case you haven't noticed, time machines don't exist in real world.

Originally Posted by kerravon

Yes, but is it really significant that you would tie your code down to a particular bit of hardware? I guess we would need some hard numbers. How many milliseconds can be saved by bypassing the ANSI stream? I can see that it is a bit odd to construct an ANSI data stream when you know it then needs to be interpreted on the same machine. Maybe it should be hidden away by "curses"?

I don't know what you mean by "curses".
Single-byte poke in comparison to string parse is an order of magnitude different. Will it be significant ? Actually, probably not.
But you are tying your code down to a particular bit of hardware - by choosing PC model.

You are also very limiting the possibilities. Consider using a proportional font, for example.
And it is so easy to abstract text output by other means, this is becoming preposterous.

Originally Posted by kerravon

I do all my work from the command line and in text mode. I have a mobile phone, but it's not a smartphone. I have an interest in how blind and deafblind people use computers, and also whether there is a need for morse code. I'm angling to get my BBS operational again (but using the internet instead of phone line) and retreating behind that.

This explains that.

[meynaf]

Originally Posted by kerravon

The challenge is to deal with low capacity systems. After sorting out the 4.77 MHz XT to my satisfaction I might see what I can do with the 1 MHz Commodore 64.

And you are dealing with low capacity systems with C code. Don't you see a little problem here ?

[Thomas Richter]

Originally Posted by meynaf

First, char is never 9-bit.

It can perfectly be 9 bit, or 16 bit, or 32 bit, or 36 bit. That's not a problem for the "C virtual machine" (an entirely hypothetical machine the authors of ISO C came up with).

Originally Posted by meynaf

What is sizeof(char) if it's 9-bit ??

It's 1. Always. sizeof() doesn't measure the size in "octets" as there are machines that don't arrange memory in octets but in some other size.

[Thomas Richter]

Originally Posted by kerravon

The way I used MSDOS in the late 80s is almost unchanged from the way I use Putty to connect to Linux at my paid work in 2021.

Except that a sane Os runs at the other end, and not MS-DOS. There is a command line, sure, but the command line works by a couple of different/advanced principles MS-DOS didn't have. And you have putty, which apparently, runs in a GUI.

Originally Posted by kerravon

I have looked at generated code for different memory models, and it is only the offset that is adjusted.

Then the compiler is corrupt. The above C segment I quoted either cannot compile, or will require pointer normalization as the array it addresses is larger than 64K.

Originally Posted by kerravon

No. C does limit the size of objects - to size_t, which in all memory models, with the possible exception of huge, is 16 bit. The bottom line is if you are exceeding 64k for single objects you are trying to stretch the 8086 beyond what it was designed to do (transition from 64k total for everything), and it's time to upgrade to the 80386.

And that's the "poor design" part of it.

Originally Posted by kerravon

That is a 1 MiB array. You can't have more than 64k of data in all memory models except possibly huge, and regardless, you are exceeding size_t for this platform. This is not the purpose of the 8086.

And that's another poor design part of it...

Originally Posted by kerravon

Intel were not on drugs when they designed the 8086, and IBM was not on drugs when they selected the 8086. It is a relatively cheap 16-bit register CPU, not an expensive 32-bit one. And it provides a transition for a 16-bit code base.

IBM was on "let's make an alternative to the Apple II as cheap and quickly as possible", that's all, and intel was on the "I have no clue on designs" path. Seriously. The 8086 was a poor kludge, probably with the intention to move as quickly and cheaply as possible to the market (same as intel), but it was not the outcome of a serious thought process.

Originally Posted by kerravon

Anything you "buy in doubt" comes with strings attached. Public domain code you can convert at will into anything you want and your company takes sole ownership of with regard to maintenance and future sales.

This is not on "IP" or "copyright". This on "I depend on the work of some third party and the will of this party to provide updates and care about the product".

Originally Posted by kerravon

I'm not saying it's for everyone. I'm not saying it's for no-one either, because I haven't surveyed every company in the world. I do know of a company in Finland that picked up my public domain zmodem code and took responsibility for maintenance of their derived product, because they sent me some bug fixes (there was no obligation for them to do that, they were just nice).

I'm sorry, but a "ZModem" code is something little different than an operating system. The "zmodem code" is "fire and forget", not much depends on it, and if it breaks, you replace it. An Os is something your entire architecture depends on. That's something a little different.


There are reasons why there are companies that sell Linux, and companies that buy from them. Not to get the "IP" or the "copyright", but to be sure that the work is maintained, and guaranteed to operate on hardware that is certified for it.

Originally Posted by kerravon

Popular is one area to investigate. Fast is another area. Small is another area. Cheap is another. Simple is another. Public domain is another.

I'm not clear what you're trying to say. As company, I don't care much about "public domain". A little bit of money is worth the investment into my products if I get something in return - "less worries", and somebody else that cares about.

[meynaf]

Originally Posted by Thomas Richter

It can perfectly be 9 bit, or 16 bit, or 32 bit, or 36 bit. That's not a problem for the "C virtual machine" (an entirely hypothetical machine the authors of ISO C came up with).

Right, but for all practical purposes it's not.

Originally Posted by Thomas Richter

It's 1. Always. sizeof() doesn't measure the size in "octets" as there are machines that don't arrange memory in octets but in some other size.

It's 1, always ? Even when compiled for unicode support ?
Anyway, the point is : char is unsuitable for safely handling bytes. Do you at least agree on this ?

[Thomas Richter]

Originally Posted by meynaf

It's 1, always ? Even when compiled for unicode support ?

Unicode is an encoding, not a type. If you mean "wide characters", there is a wide character type wchar_t for encodings that require characters that are wider than char. "char" is not related to the selected encoding of text, it is just the smallest addressable unit on the virtual machine. Thus, yes, always.

Originally Posted by meynaf

Anyway, the point is : char is unsuitable for safely handling bytes. Do you at least agree on this ?

Depending on your definition of "byte", this is what the standard also says, just that "a byte" does not need to agree with "an octet". Thus, there are certainly existing processors, active in use, where char=short=int, and all have 16 bit.

[meynaf]

Originally Posted by Thomas Richter

Unicode is an encoding, not a type. If you mean "wide characters", there is a wide character type wchar_t for encodings that require characters that are wider than char. "char" is not related to the selected encoding of text, it is just the smallest addressable unit on the virtual machine. Thus, yes, always.

So char, not actually a character, is kind of a misnomer.
Not surprising from C, where 'x' is actually an int.

Originally Posted by Thomas Richter

Depending on your definition of "byte", this is what the standard also says, just that "a byte" does not need to agree with "an octet".

It does not need to, but let's face the fact : it usually does.
But maybe char is enough and __int8 is useless ?

Originally Posted by Thomas Richter

Thus, there are certainly existing processors, active in use, where char=short=int, and all have 16 bit.

Then, not for general purpose use. It would be incredibly bad for interoperability.

[deimos]

Originally Posted by meynaf

It does not need to, but let's face the fact : it usually does.

I think this thread deserves better than a diversion about whether a byte is really 8 bits or not.

[Thomas Richter]

Originally Posted by meynaf

So char, not actually a character, is kind of a misnomer.

Unfortunately, it is. Or rather a historical accident, where "char" was, originally, of course the character type of the machine it run on, but this type of interpretation became problematic for some architectures the language was ported to.

Originally Posted by meynaf

It does not need to, but let's face the fact : it usually does.

For the machines we typically care about in this forum, it is 8 bit, yes.

Originally Posted by meynaf

But maybe char is enough and __int8 is useless ?

Not quite. int8 is 8 bit on machines where such a datatype exists. If it doesn't exist, then the hosting machine does not have an addressable 8 bit type, and if your algorithm depends on it, you know at least that you have to find some other solution. So it certainly does serve some purpose.

Originally Posted by meynaf

Then, not for general purpose use. It would be incredibly bad for interoperability.

These are typically not general purpose processors, but DSPs, indeed. However, with some pain, one can certainly program such chips, also in some portable way. C is a solution for such architectures. But then again, you wouldn't port your average word processor to such chips. They are designed for other purposes.

[meynaf]

Originally Posted by deimos

I think this thread deserves better than a diversion about whether a byte is really 8 bits or not.

Not my fault. The point was that "char" datatype is ill-suited for handling bytes due its size is not guaranteed. That should be easy to understand. But no.

Originally Posted by Thomas Richter

Not quite. int8 is 8 bit on machines where such a datatype exists. If it doesn't exist, then the hosting machine does not have an addressable 8 bit type, and if your algorithm depends on it, you know at least that you have to find some other solution. So it certainly does serve some purpose.

So when we need to read 8-bit bytes from a file, char is ill-suited due size not guaranteed. Yes, like said above.
This is what i wanted to show to the OP. Of course it derailed.

[paraj]

Yeah, this is getting into language lawyer territory, but "char" is better thought of as "minimally addressable" unit, which is usually 8 bits (it can not be less in C90 or later, you can check it with CHAR_BIT - the standard says: "maximum number of bits for smallest object that is not a bit-field (byte)").

Everyone that's not targeting weird DSP chips either just assumes CHAR_BIT==8, use e.g. uint8_t (or their own typedefs) or add compile/configure-time checks.

@OP: Many pages back I said you might be better off just ignoring ANSI stuff, but now that I think I understand what you're trying to do, you may be better off embracing it (or using a curses like interface as others have suggested)!

The reason I suggested ignoring it, is that not many original applications used it because it was slow, and thus maybe a distraction. You may find this article interesting regarding why it was slow.

[kerravon]

Originally Posted by meynaf

Not my fault. The point was that "char" datatype is ill-suited for handling bytes due its size is not guaranteed. That should be easy to understand. But no.

I certainly don't understand the issue anyway.

So when we need to read 8-bit bytes from a file, char is ill-suited due size not guaranteed. Yes, like said above.
This is what i wanted to show to the OP. Of course it derailed.

The char's that are stored in the file would have been 9 bits with the high bit set to 0 in the first place. So when the fgetc() primitive is used to read a 9-bit char back from the file, the underlying infrastructure will presumably set the high bit to 0 as well, as part of a 9-bit-char CPU interfacing with a presumably 8-bit hardware device.

I've never personally dealt with 9-bit chars myself so I don't know if I'm missing something that you are seeing. I do know that sizeof(char) is always 1 though, so that's not an issue.

[kerravon]

Originally Posted by paraj

@OP: Many pages back I said you might be better off just ignoring ANSI stuff, but now that I think I understand what you're trying to do, you may be better off embracing it (or using a curses like interface as others have suggested)!

Perhaps you can explain in your own words what you think I am trying to do so that I can confirm we have a meeting of the minds?

The reason I suggested ignoring it, is that not many original applications used it because it was slow, and thus maybe a distraction. You may find this article interesting regarding why it was slow.

I read the article.

You know, I think an argument can be made that all stops should be pulled out to ensure that the application is viable on an IBM PC XT. Everyone else has the grunt (or is of lesser importance) that they can convert from that model to the ANSI control characters or whatever else that they need.

[kerravon]

Originally Posted by meynaf

It looks good only on paper. In real life, it has been a pita for everyone having to code for it. So yes it was a poor design.

I programmed for the XT starting in 1987 from memory. It wasn't a pita. I programmed in C90 and selected an appropriate memory model. I still write C90 programs in 2021 that will run perfectly fine on an XT. Unless you want to be specific, the problem was with programmers, not the 8086.

No. 4GiB isn't "tiny". As more than 99.9% of apps don't actually use more than that amount, even today with the current large waste we have.

"tiny" is a model, not an English word.

The situation you describe isn't realistic, as with paged systems the 64-bit machine won't be allocating "3 to 7 GiB" to a 32-bit program...

It is a theoretical situation in computer science. The processor may not have paging. When it was the 8086, it wasn't even theoretical. It was just a different number of bits per register. The maths is identical.

The programmer can in some situations be seen as the user
But no, the C90 program won't work completely unchanged - or if it does, it will be at the price of horrible performance costs.

What "horrible" performance costs did you measure? I selected the compact memory model for one of my applications that I actually timed, so that I could use bigger memory buffers. I don't remember any horrible performance problem switching from Turbo C's default small memory model. Quite the reverse because the bigger buffers improved disk performance.

And at this level, if you're worried about performance issues, the problem is not the 8086 segmentation model, the problem is you selected the 8086 instead of the 80286 or 80386 for the better clock speed rather than an architecture change.

Are you conscious that you will not be transported back in 1983 ? In case you haven't noticed, time machines don't exist in real world.

https://www.hermit.org/b7/Episodes/s...Dawn-Gods.html

AVON There is no known power in the universe that can operate a traction beam over that distance.

TARRANT Just because you don't know how to build a high-energy traction beam doesn't mean that no one else knows how to build one.

While ever the possibility of god(s) exist, and note that a majority of people in the world believe at least one exists, literally anything is possible. I don't know what you think Heaven/Hell may look like, but they could involve reliving life with your current knowledge. Trivial to do if we happen to be living inside a computer simulation already. You probably already believe quantum mechanics that allows for the possibility of spontaneous teleport. Science hasn't ruled out time travel either.

No. It will not work.
First, char is never 9-bit. What is sizeof(char) if it's 9-bit ?? If 1 then it can't be 9-bit, only 8. If 2, then it's 16-bit with 7 bits wasted.
So, could be 16. But then if you do "*x" you access two bytes, not just one.

No, that's not how C works.

So a memcpy even on old 8086 doesn't take much time but complicated ANSI codes do ?

That is correct. A memcpy() is in fact a single instruction on the 8086. Interpreting ANSI codes requires a lot of instructions.

Congratulations, now you're freezing everything during disk accesses.

MSDOS is single-tasking, so everything is being frozen regardless.

Have you really observed such a redrawing process (for a text-only app) or is it just a theory ?

I used to connect to BBSes at 1200 bps and watched ANSI screens being drawn. I can't remember specifically ANSI applications being run on the same machine. But ansi.sys almost certainly used the BIOS, and the only figure I have for that is someone reporting an XT simulator takes around 1 second to draw a whole screen using the BIOS.

I don't know what you mean by "curses".

It's a package that used to be used on Unix, not sure where else, where you give it the primitives you want to do, and it constructs the ANSI (or some other codes) required to drive your terminal.

Single-byte poke in comparison to string parse is an order of magnitude different. Will it be significant ? Actually, probably not.

Well, 1 second is significant, so if I want to begin this process in 1983 it is appropriate to do poking, I think. But PDOS-generic was just going to run micro-emacs using ANSI controls for the fullscreen editor.

But you are tying your code down to a particular bit of hardware - by choosing PC model.

Which bit is tying down?

You are also very limiting the possibilities. Consider using a proportional font, for example.

I'm not trying to solve the problem of proportional fonts. I just need fixed width fonts, with English text (not Chinese, not inverse text), monochrome to work on the IBM PC XT in a way that still works on the Amiga. Just getting that to work is a challenge already.

And it is so easy to abstract text output by other means, this is becoming preposterous.

It's not preposterous. I'm not even restricting this to run on a 64k machine like MSDOS 1.0 was designed to cope with.

[kerravon]

Originally Posted by meynaf

And you are dealing with low capacity systems with C code. Don't you see a little problem here ?

Not at all. C is basically portable assembler. What's the issue? Have you looked at the assembler code C compilers generate? It's beautiful. Although I've only looked at 16-bit and 32-bit register sizes. 8-bit is not a problem I'm dealing with at the moment.

[kerravon]

Originally Posted by meynaf

It does not need to, but let's face the fact : it usually does.
But maybe char is enough and __int8 is useless ?

Yes, ignore the post-C90 crap like int8_t and "long long". It goes against C's design.

[kerravon]

Originally Posted by Thomas Richter

Except that a sane Os runs at the other end, and not MS-DOS. There is a command line, sure, but the command line works by a couple of different/advanced principles MS-DOS didn't have.

And for my work of editing/compiling/testing I don't care if there are more advanced principles being used behind the scenes.

And you have putty, which apparently, runs in a GUI.

Yes, and if they instead give me a VT200 my work will continue unchanged. I'll solve the same bug the same way.

Then the compiler is corrupt. The above C segment I quoted either cannot compile, or will require pointer normalization as the array it addresses is larger than 64K.

No, your scenario is invalid. C90 programs running on an 8086 are limited to a size_t of 64k.

And that's the "poor design" part of it.

And that's another poor design part of it...

No. It is an amazing extension of 16-bit registers to address more than the 64k they are nominally capable of. If you're willing to abandon 16-bit programming in one fell swoop and switch to a pure 32-bit environment, that's a different scenario for what the 8086 was designed for.

IBM was on "let's make an alternative to the Apple II as cheap and quickly as possible", that's all, and intel was on the "I have no clue on designs" path. Seriously. The 8086 was a poor kludge, probably with the intention to move as quickly and cheaply as possible to the market (same as intel), but it was not the outcome of a serious thought process.

I'm not intimately familiar with the thought processes of Intel and IBM. All I can say is that the 8086 was fit for purpose of extending 16-bit registers beyond 64k.

This is not on "IP" or "copyright". This on "I depend on the work of some third party and the will of this party to provide updates and care about the product".

Sometimes a company doesn't want a third party to maintain the product they want to take control of it themselves.

I'm sorry, but a "ZModem" code is something little different than an operating system. The "zmodem code" is "fire and forget", not much depends on it, and if it breaks, you replace it. An Os is something your entire architecture depends on. That's something a little different.

Even more reason to take a relatively simple and understandable system and maintain it yourself instead of relying on a third party.

There are reasons why there are companies that sell Linux, and companies that buy from them. Not to get the "IP" or the "copyright", but to be sure that the work is maintained, and guaranteed to operate on hardware that is certified for it.

The best way to guarantee anything is to take control of it yourself instead of relying on others to do it.

I'm not clear what you're trying to say. As company, I don't care much about "public domain". A little bit of money is worth the investment into my products if I get something in return - "less worries", and somebody else that cares about.

Not all companies think the same way. One person did contact me about PDOS saying that it met his objective of providing a base for his own OS.

[kerravon]

Originally Posted by kerravon

I've never personally dealt with 9-bit chars myself so I don't know if I'm missing something that you are seeing. I do know that sizeof(char) is always 1 though, so that's not an issue.

I think I know the problem. Some machines have 9-bit chars, 18-bit shorts and 36-bit longs. So when I talk about 9-bit chars, I'm talking about the smallest addressable unit (as others mentioned). But you seem to be talking about a character set such as Vietnamese which (sort of) requires more than 256 characters to represent its entire alphabet.

Note that to support Vietnamese I'm planning on having a slightly modified VISCII - I have a different set of control characters I wish to relinquish to allow them to fit into 8 bits without disturbing *printable* ASCII.

Chinese/Japanese/Korean I have no interest in at all. They can simply use their respective alphabets like everyone else does.

So everything I want to do in 1983 and 1990 can be done in 8-bit chars, and machines with 9-bit chars are not an issue either.

[kerravon]

Originally Posted by kerravon

You know, I think an argument can be made that all stops should be pulled out to ensure that the application is viable on an IBM PC XT. Everyone else has the grunt (or is of lesser importance) that they can convert from that model to the ANSI control characters or whatever else that they need.

I was thinking more about this, and I think what we actually need in 1983 is a lightweight curses or equivalent that allows you to build with direct poking on an IBM PC or ANSI on some other machine.

And the application I really want to run is micro-emacs, and it already has the equivalent of curses, and supports a flavor that accesses 0xb8000 and an ANSI version.

So I can't see any technical barrier to the Amiga being a viable MSDOS machine in 1985, if we have cooperative programmers in 1983.

And PDOS-generic would deliver that environment on top of the Amiga. You don't need Commodore's permission. And you can use Lattice C (SAS/C).

So the only question remaining is - is there anything deficient about PDOS-generic's design before it gets released around 1986?

[kerravon]

Originally Posted by kerravon

So the only question remaining is - is there anything deficient about PDOS-generic's design before it gets released around 1986?

Oh, I have another question. What can the Amiga be stripped down to so that it still supports PDOS-generic? It would be floppy-based circa 1986. I only need the following APIs to exist in memory:

void *Input(void);
void *Output(void);
void *Open(const char *fnm, long b);
long Read(void *a, void *b, long c);
long Write(void *a, void *b, long c);
long Seek(void *a, long offs, long c);
int Close(void *a);
struct DateStamp *DateStamp(struct DateStamp *d);

void *AllocMem(size_t a, long b);
void FreeMem(void *a, size_t b);