16 November 2021, 08:08 | #281 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,331
|
Quote:
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. |
|
16 November 2021, 08:10 | #282 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,331
|
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.
|
16 November 2021, 08:33 | #283 | |||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,331
|
Quote:
Quote:
Quote:
Quote:
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. Quote:
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. Quote:
Quote:
Well, good luck with that. I still fail to see what this is good for. |
|||||||
16 November 2021, 08:41 | #284 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
|
|
16 November 2021, 08:58 | #285 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,239
|
Quote:
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. |
|
16 November 2021, 09:16 | #286 | |||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
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.
Quote:
Quote:
Quote:
|
|||
16 November 2021, 09:26 | #287 | ||||||||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,365
|
I see.
Quote:
Quote:
It IS an English word, meaning "very small". Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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. 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. Tell that to all those who had to create their own data types because C didn't provide them. Quote:
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. Quote:
Quote:
Quote:
Quote:
Quote:
A 80x25 screen is just 2000 bytes. Even a 8086 can handle that - or 8086 is even worse than I imagined. 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. Quote:
Quote:
No, really, designing a good abstraction layer for this, shouldn't be difficult. Quote:
Oh, and smaller too. Usually by at least a factor 2. Quote:
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). Quote:
Quote:
Of course you don't see this, as you don't try to decode byte streams. Or worse, emulate a cpu. |
||||||||||||||||||||
16 November 2021, 09:36 | #288 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,365
|
Quote:
I remember having read somewhere that by the time they made the choice, 68000 wasn't available at all yet. |
|
16 November 2021, 09:40 | #289 | ||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Quote:
|
||
16 November 2021, 09:47 | #290 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,365
|
Quote:
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. Rather, show us some good 68k asm that's compiler-generated - just for a laugh. |
|
16 November 2021, 10:57 | #291 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
With the above restrictions, the Amiga could potentially have a new life as a Windows clone at the source level? |
|
16 November 2021, 11:24 | #292 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,365
|
|
16 November 2021, 11:30 | #293 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
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.
|
16 November 2021, 11:56 | #294 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,365
|
Quote:
Most Windows users don't even know what a command line is. |
|
16 November 2021, 12:16 | #295 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
|
16 November 2021, 12:43 | #296 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,365
|
|
16 November 2021, 17:17 | #297 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,331
|
Quote:
|
|
16 November 2021, 21:07 | #298 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
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.
|
17 November 2021, 07:58 | #299 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,331
|
Quote:
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? |
|
17 November 2021, 08:39 | #300 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
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? |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
|
|