PDOS for Amiga

[Thomas Richter]

Originally Posted by kerravon

Oh, I have another question. What can the Amiga be stripped down to so that it still supports PDOS-generic?

You cannot just "import parts of a library". Either a library is opened and used, or its not. If it is open, it exists entirely and completely.



Now, the functions you use are coming from dos and exec, and both of them are ROM-based. As soon as you start the dos.library (by the booting harddisk or floppy), you are already pulling in everything from the startup-sequence, so at the point you can open the dos.library, the system is already complete. Not much you can strip there.


The next "smaller" system is a system with exec, but without the dos.library.

[Thomas Richter]

Originally Posted by kerravon

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.

It depends. If you look at the code required for "far" pointers, it's ugly. A pointer is, depending on the "model", a collection of a base and an offset relative to it. I would not consider this an orthogonal approach. But that's a limit of the kludgy intel design, and fitting C on top of it. The processor is not quite the right target for a C compiler.

[Thomas Richter]

Originally Posted by kerravon

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

That depends on the "memory model".

Originally Posted by kerravon

No. It is an amazing extension of 16-bit registers to address more than the 64k they are nominally capable of.

"Amazing" as in "it hurts amazingly", then yes. It was a stupid design, and intel knew that. They used a completely different extension mechanism in later processors of their x86 processor. Never questioned why they went away from this idea?

Originally Posted by kerravon

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.

intel apparently wanted to preserve backwards compatibility to an 8-bit processor. That's all fine, but it was done in an insane way. The protected mode was the right move, but was limited by the inability to run a process in real-mode again was an important and hurting oversight. It clearly showed that intel lacked experience in design - it looks like an ad-hoc kludge.

Originally Posted by kerravon

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.

The thought process at IBM and the creation of the PC are well documented and can be found in multiple sources. As said, the idea was really to address the market segment Apple occupied with the Apple II, and the whole purpose of the machine was to be "cheap cheap". The 8086 was selected because it was cheap and available in quantities, unlike the 68000 which was not available in volumes and more expernsive.


The thought process at intel I can only guess, but giving the mistakes they made in the real mode, and later on in the protected mode, e.g. its inability to switch back to real, showed that they didn't put too much thought into their architecture.

Originally Posted by kerravon

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

Would you take control over somebody else's source you do not understand, i.e. invest time into learning somebody else's design, instead of putting the time (and money) into developing something on your own which then fits your needs perfectly?


This hasn't happened here, at least. We do use external code, of course, but that's then contracted, or in a license that's liberal enough for our needs, but it doesn't need to be "public domain" for that. We haven't taken over somebody else's work.

Originally Posted by kerravon

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

If the system is simple, I would rather develop it in house, building up the knowledge ground up. Or I would buy or contract it, and have it maintained externally.

Originally Posted by kerravon

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.

Well, good luck with that. I still fail to see what this is good for.

[kerravon]

Originally Posted by Thomas Richter

It depends. If you look at the code required for "far" pointers, it's ugly. A pointer is, depending on the "model", a collection of a base and an offset relative to it. I would not consider this an orthogonal approach. But that's a limit of the kludgy intel design, and fitting C on top of it. The processor is not quite the right target for a C compiler.

The point is the assembler that is generated by the C compiler is pretty much the same as the assembler code you would have otherwise had to write by hand to achieve the same thing. If you show me some C code - real C code - that obeys the C standard which means a single object is not bigger than 64k - I can run it through Watcom C and show you the generated assembler.

[paraj]

Originally Posted by kerravon

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?


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.

Well I could of course still be wrong, but it sounds like you want to do something like what Linux did for UNIX, except with UNIX replaced by DOS. That is, have some kind of portable OS with enough software to provide an ecosystem.


I'm sure something like ANSI/terminal commands could be made to run fast (at least acceptably) on an XT if the implementation was made with speed in mind (i.e. not rely so heavily on the BIOS). The advantage of that compared to the "framebuffer" approach (which you could of course also support in addition) is that it's already used by many applications and easily ported to other systems where the (text) screen has different characteristics.

[kerravon]

Originally Posted by Thomas Richter

That depends on the "memory model".

No. Every DOS C compiler I have looked at uses a 16-bit size_t regardless of memory model. They even use it for the rarely-used "huge" memory model, but with PDPCLIB I intend to change that, and use a 32-bit size_t for Watcom C.

"Amazing" as in "it hurts amazingly", then yes. It was a stupid design, and intel knew that. They used a completely different extension mechanism in later processors of their x86 processor. Never questioned why they went away from this idea?

Once less than 10% of your customers are using the old CP/M interface, who gives a shit if you lose 10% of your customer base?

Would you take control over somebody else's source you do not understand, i.e. invest time into learning somebody else's design, instead of putting the time (and money) into developing something on your own which then fits your needs perfectly?

I'd at least have a quick look to see if the public domain version fit any of my needs. Someone contributed pdmake which fits my needs and if I find a bug in it I'm happy to pay someone to fix it.

Well, good luck with that. I still fail to see what this is good for.

You can debug C90 applications by putting debug into the OS (PDOS-generic), regardless of what processor you are running on, and if you start becoming familiar with the OS during that process, and see a commercial opportunity for a modified version of the OS, you can sell it without restriction. And for an environment without an existing OS you only need to write the BIOS layer.

[meynaf]

Originally Posted by kerravon

I certainly don't understand the issue anyway.

I see.

Originally Posted by kerravon

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.

So every file in this machine that comes from other machines wastes 1 bit per byte. Hopefully this is just imaginary machine.

Originally Posted by kerravon

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.

It always amazes me how much people having learned on a machine (or just used it for a long time) can be forgiving about its deficiencies.

Originally Posted by kerravon

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

It IS an English word, meaning "very small".

Originally Posted by kerravon

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.

Yes it is a theoretical situation. That says it all.

Originally Posted by kerravon

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.

Very nice cherry picking.

Originally Posted by kerravon

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.

I didn't select the 8086. YOU did it.

Originally Posted by kerravon

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.

I'm afraid this possibility doesn't actually exist. Or at least, don't count on it.

Originally Posted by kerravon

Trivial to do if we happen to be living inside a computer simulation already.

But we don't. I let you imagine the vast quantity of computational power this would require. There are limits. To be able to simulate something, you must be bigger than that thing - or reduce accuracy.

Originally Posted by kerravon

You probably already believe quantum mechanics that allows for the possibility of spontaneous teleport.

No. I don't.
And current science is clear on that subject : it can NOT be used to transfer information instantly.
Actually i even believe that one day we'll discover that during all that time there was no communication at all between intricated particles.

Originally Posted by kerravon

Science hasn't ruled out time travel either.

Doesn't mean it's possible.
Consider the fact we're not invaded by tourists coming from the future. Or that we haven't seen anyone at all from there, actually.
Being able to time travel would mean previous states of the whole universe aren't lost, that they are in some way stored, like previous states of a saved game on a computer. So regular copies have to be made. This is completely crazy.

Originally Posted by kerravon

No, that's not how C works.

Tell that to all those who had to create their own data types because C didn't provide them.

Originally Posted by kerravon

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

I hope you are aware that this "single instruction" can actually take many clock cycles to complete...
But yes, it's faster to merely copy a character than attempting to interpret it. That might be an argument against your choice of ANSI, though.

Originally Posted by kerravon

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

So you lock yourself to single-tasking forever.

Originally Posted by kerravon

I used to connect to BBSes at 1200 bps and watched ANSI screens being drawn.

If your text comes from slow network, obviously it will take time to display but it's not the fault of the display itself

Originally Posted by kerravon

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.

Then it's just BIOS that's slow, and the correct reply is to not use BIOS and write something faster, not something that attempts to hide the slowness.

Originally Posted by kerravon

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.

This looks like a better solution than using file i/o.

Originally Posted by kerravon

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.

It's not gonna take 1 second if coded properly, even if not doing direct poking.
A 80x25 screen is just 2000 bytes. Even a 8086 can handle that - or 8086 is even worse than I imagined.

Originally Posted by kerravon

Which bit is tying down?

I don't know exactly, but Atari ST docs clearly state that some DOS functions aren't there because the make no sense on non-PC machines.
For example, functions $0c-$0d/$0f/$14-$18 are not there in TOS trap #1.

Originally Posted by kerravon

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.

THAT is a challenge already ? Wow.

Originally Posted by kerravon

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.

I didn't say you were preposterous. Don't confuse what you are and what you are doing.
No, really, designing a good abstraction layer for this, shouldn't be difficult.

Originally Posted by kerravon

Not at all. C is basically portable assembler. What's the issue?

C isn't portable assembler. It's slow. Everything C you write, if it's cpu bound and can't use external asm-written library for the hard work then i can rewrite a faster version of it in assembler (obviously in 68k). And not by just 10%.
Oh, and smaller too. Usually by at least a factor 2.

Originally Posted by kerravon

Have you looked at the assembler code C compilers generate? It's beautiful.

I have disassembled megabytes of it and it was just horrible.
Simple, naive. Quite readable but terrifyingly inefficient. Often much too long and very stupid.
So no, it's not beautiful. And it's not fast either. I have already beaten GCC by a factor 4.

You are starting with a wrong belief (a quite common one these days, though).

Originally Posted by kerravon

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.

That's ok, 68k has 32-bit register sizes. I'm ready for a code challenge against the Amiga compiler of your choice.

Originally Posted by kerravon

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

The problem is that sometimes C's design fails miserably.
Of course you don't see this, as you don't try to decode byte streams. Or worse, emulate a cpu.

[meynaf]

Originally Posted by Thomas Richter

The 8086 was selected because it was cheap and available in quantities, unlike the 68000 which was not available in volumes and more expernsive.

Actually, it's 8088 that was selected for original IBM PC 5150.
I remember having read somewhere that by the time they made the choice, 68000 wasn't available at all yet.

[kerravon]

Originally Posted by paraj

Well I could of course still be wrong, but it sounds like you want to do something like what Linux did for UNIX, except with UNIX replaced by DOS. That is, have some kind of portable OS with enough software to provide an ecosystem.

Yes, that's a good way of putting it. And I guess I could do the same thing Linux did with WINE and have a little Windows library that calls the DOS API. And given that this can all run on the Amiga, the Amiga could be turned into a mini-Windows environment too.

I'm sure something like ANSI/terminal commands could be made to run fast (at least acceptably) on an XT if the implementation was made with speed in mind (i.e. not rely so heavily on the BIOS).

Actually, that's an excellent point! There's no reason why PDOS/86 can't directly write to 0xb8000. So long as the application defers the write to stdout until all the screen manipulations are ready, ie be fully-buffered, there will be minimal overhead in doing the DOS interrupt. So the only extra overhead will be constructing and interpreting the ANSI sequences unnecessarily.

[meynaf]

Originally Posted by kerravon

The point is the assembler that is generated by the C compiler is pretty much the same as the assembler code you would have otherwise had to write by hand to achieve the same thing.

Actually, not at all.
For x86 we can hardly compare, as it's so unwieldy for this purpose that even I wouldn't write asm for it (ok, there is worse - don't ask me for mips or alpha asm...). And don't say it's beautiful - x86 asm is ugly, regardless of what or who wrote it.
But a compiler converts the code, where a decent asm programmer converts the algorithm. This is a big difference.
I can prove you wrong with 68k asm any time.

Originally Posted by kerravon

If you show me some C code - real C code - that obeys the C standard which means a single object is not bigger than 64k - I can run it through Watcom C and show you the generated assembler.

Rather, show us some good 68k asm that's compiler-generated - just for a laugh.

[kerravon]

Originally Posted by kerravon

Yes, that's a good way of putting it. And I guess I could do the same thing Linux did with WINE and have a little Windows library that calls the DOS API. And given that this can all run on the Amiga, the Amiga could be turned into a mini-Windows environment too.

The Win32 executables that I produce are already universal - running on PDOS/386 and Win 95 upwards, Linux WINE, Freedos or MSDOS + HX. But I only produce Win32 executables that use C90 functions or do FAT manipulation.

With the above restrictions, the Amiga could potentially have a new life as a Windows clone at the source level?

[meynaf]

Originally Posted by kerravon

With the above restrictions, the Amiga could potentially have a new life as a Windows clone at the source level?

Windows is more about using GUI than anything else - hence its name. As a command-line environment it is useless.

[kerravon]

Originally Posted by meynaf

Windows is more about using GUI than anything else - hence its name. As a command-line environment it is useless.

I think there are plenty of people who use the Unix command line. Why not the Windows one instead? I use the Windows command line all the time. For all my development work. Including the recent activity of getting GCC and binutils to target the Amiga.

[meynaf]

Originally Posted by kerravon

I think there are plenty of people who use the Unix command line. Why not the Windows one instead? I use the Windows command line all the time. For all my development work. Including the recent activity of getting GCC and binutils to target the Amiga.

Most Windows programs have a GUI.
Most Windows users don't even know what a command line is.

[kerravon]

Originally Posted by meynaf

Most Windows programs have a GUI.
Most Windows users don't even know what a command line is.

But what about programmers who use the command line? Any reason why they shouldn't choose the Windows version instead of Linux?

[meynaf]

Originally Posted by kerravon

But what about programmers who use the command line? Any reason why they shouldn't choose the Windows version instead of Linux?

That's not the point.
What about programmers who don't use the command line ? Any reason why they can't use any version at all ?

[Thomas Richter]

Originally Posted by kerravon

Actually, that's an excellent point! There's no reason why PDOS/86 can't directly write to 0xb8000. So long as the application defers the write to stdout until all the screen manipulations are ready, ie be fully-buffered, there will be minimal overhead in doing the DOS interrupt. So the only extra overhead will be constructing and interpreting the ANSI sequences unnecessarily.

Urgh. So we are back to screen poking? Why, just why? What if you want to have memory in this region, and your graphics card memory does not fit into 64K?

[kerravon]

Originally Posted by Thomas Richter

Urgh. So we are back to screen poking? Why, just why? What if you want to have memory in this region, and your graphics card memory does not fit into 64K?

I don't understand this concern at all. The memory at 0xb8000 is well-known and a fixed 4000 bytes (25 * 80 * 2). Secondly, the poking of this memory would be done in the 8086 OS (PDOS/86), not in applications, so if for any reason poking is an issue and you need to use the BIOS, you can simply recompile PDOS/86 to use the slower BIOS.

[Thomas Richter]

Originally Posted by kerravon

I don't understand this concern at all. The memory at 0xb8000 is well-known and a fixed 4000 bytes (25 * 80 * 2). Secondly, the poking of this memory would be done in the 8086 OS (PDOS/86), not in applications, so if for any reason poking is an issue and you need to use the BIOS, you can simply recompile PDOS/86 to use the slower BIOS.

Fixed hardware addresses and magic pointers I would definitely not use for a new design. How do you know that your graphics hardware is accessible in this area? What if not? Thus, now your "Os" depends on hardware designers following an outdated design spec as well. What happens if you want to run this in a virtual machine? Do I really need to emulate CGA hardware for that?

[kerravon]

Originally Posted by Thomas Richter

Fixed hardware addresses and magic pointers I would definitely not use for a new design. How do you know that your graphics hardware is accessible in this area? What if not? Thus, now your "Os" depends on hardware designers following an outdated design spec as well. What happens if you want to run this in a virtual machine? Do I really need to emulate CGA hardware for that?

I believe we are talking cross-purposes.

First, the year is 1983 and MSDOS 2.0 has just been released. I need advice to give to MSDOS programmers. My tentative advice is "don't directly manipulate memory at 0xb8000, use ANSI instead". If they say "but ANSI is slow!" then the correct technical response is to change/replace ansi.sys or even change MSDOS 2.0 to PDOS/86, so that it stops using the BIOS and directly manipulates the hardware, so should be fast enough even on an IBM PC XT.

By doing this, MSDOS *applications* are clean at the source code level. There is no particular reason for MSDOS 2.0 or PDOS/86 (ie the OS, not apps) to be "BIOS-only", but if there is, the correct technical solution is to have two builds of these - one that uses the hardware and one that uses the BIOS.

The new design is PDOS-generic, and destined to grace the Amiga when it comes out in 1985. It will be source compatible with the MSDOS applications above.

This is a far better flavor of MSDOS on the Amiga, in the 1980s, than what actually happened which was attempts to emulate the 8086. At least for someone interested in an MSDOS command-line interface for development, as I was then, and still are today.

If you can agree with all of the above, then the only remaining thing is to discuss the PDOS-generic design. ie can you see anything wrong with having a pure C90 system?