 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> An x86 CPU will start in 16-bit mode when it's powered-up. I don't think
> there's any way to bypass that via anything. The only thing that a
> 32/64-bit BIOS can do is to make the switch to 32/64-bit mode earlier
> in the bootup process.
>
> However, such a BIOS could theoretically allow for a x86 CPU to drop
> 16-bit support completely (if the OS can, thanks to such a BIOS, assume
> the CPU is already running in 32/64-bit mode when it boots.)
Let us hope this happens someday.
> There are some completely different CPU architectures where the
> distinction between 32-bit and 64-bit modes is much more transparent.
> The UltraSparc would be a perfect example. It's so transparent that it
> doesn't even need separate modes for 32-bit and 64-bit code: They both
> run just fine as-is, even if you mix them up.
The Motorola 68000 was a 16-bit CPU, but it had opcodes for 32-bit
operations. It's just that they take twice as long. Then if you upgrade
to an M68020 (?), it's 32-bit, and all your software goes 2x as fast.
(Because ALMOST EVERYTHING uses mostly 32-bit arithmetic.)
Going to 64-bit took longer, because nobody really needs 64-bit integer
arithmetic (and we already have 80-bit floating-point arithmetic), so
the only real advantage is increased address space. [Which only matters
once GB-sized RAM started to be manufactured.]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.01.2014 23:19, schrieb Orchid Win7 v1:
> On 22/01/2014 04:54 PM, Warp wrote:
>> Orchid Win7 v1<voi### [at] dev null> wrote:
>>> Next up: Why, in the year 2014, am I still running installers that have
>>> 16-bit dithered logos? WTF?
>>
>> Obviously you need to be able to run it in safe mode...
>
> I didn't think even Safe Mode runs in 16-bit colour any more. And even
> if it does... so make the OS convert from 24-bit down to 16-bit on the
> fly! Sheesh.
>
>> Speaking of which, even though the 80386 processor was introduced
>> in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
>> mode. Yes, even the new 64-bit ones.
>
> I got the impression that 64-bit CPUs cut back on some of the really
> ancient 16-bit stuff. (I don't have an actual site for that though.)
That might well be. After all, you could emulate them via unknown-opcode
traps.
>> The very first thing that the OS does is to switch to either 32-bit
>> mode (if the CPU is that old) or to 64-bit mode. After that it will
>> usually never revert back to 16-bit mode ever again.
>
> Ah yes - by toggling line 20 on the address bus. Obviously. (WTF?)
No, no - that A20 line thing is just for a small detail of the 16-bit mode.
> Well, that's only in so-called "IBM PC-compatibles". (How compatible are
> any of these with the 30-year old dinosaur?) I think the Apple Mac does
> it differently...
I'd be surprised if Macs came without A20 line gate. After all, it's the
type of logic that's needed for IBM PC-compatibility but has been moved
from discrete gates on the mainboard into the chipset decades ago already.
> Overall, PCs are just *full* of this crap. (Some of you may remember I
> once set out on a misguided quest to "write my own OS". I read up on
> some of this stuff.) And yet, when somebody produces a technically
> superior system that lacks lashings of backwards compatibility, nobody
> actually buys it...
... because of that very lack of backwards compatibility.
Actually, MS-DOS - and probably the IBM PCs as well - wouldn't have had
any chance of success in the first place, had it not been for MS-DOS's
backwards compatibility with CP/M at the application programming level.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.01.2014 23:19, schrieb Orchid Win7 v1:
> (Some of you may remember I
> once set out on a misguided quest to "write my own OS". I read up on
> some of this stuff.)
That does sound like an intriguing challenge, provided you don't set out
to design the best OS that has ever been.
If you get to the point where you can compile, link and run a "Hello
World" C program on that platform, that's certainly good enough for
starters.
And if PC hardware seems too messy and non-standardized (which most
certainly is the case), something like the Raspberry Pi might be an
interesting target.
Then again, why design a whole OS if I'd only want to run a very limited
set of programs on it anyway... it can't be too complicated to build a
POV-Ray version that runs directly atop the BIOS, can it? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 23 Jan 2014 01:14:01 +0100, clipka wrote:
>> I got the impression that 64-bit CPUs cut back on some of the really
>> ancient 16-bit stuff. (I don't have an actual site for that though.)
>
> That might well be. After all, you could emulate them via unknown-opcode
> traps.
I don't know if it's the case or not, but I had a recent discussion with
someone about supporting NetWare 2.x (don't ask) on modern hardware, and
the question of whether the A20 line was still supported on modern
processors came up, because at least 2.15 and earlier require that.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/22/2014 5:14 PM, clipka wrote:
>> Well, that's only in so-called "IBM PC-compatibles". (How compatible are
>> any of these with the 30-year old dinosaur?) I think the Apple Mac does
>> it differently...
>
> I'd be surprised if Macs came without A20 line gate. After all, it's the
> type of logic that's needed for IBM PC-compatibility but has been moved
> from discrete gates on the mainboard into the chipset decades ago already.
>
I thought that, some time back, the only "functional" difference between
Mac and PC had finally come down to an extra chip on the board, which
basically prevented the OS from booting, if it wasn't on a machine that
had it, and.. I am guessing the GUI functionality isn't in firmware/ROM
anymore, right? But, there was a whole huge thing with trying to get PC
stuff to boot on a Mac, and a Mac to boot on standard PC hardware, and
it all came down, not to architectural differences, so much as just,
"There is this extra chip on the board."
Or, maybe I was just imagining that?
--
Commander Vimes: "You take a bunch of people who don't seem any
different from you and me, but when you add them all together you get
this sort of huge raving maniac with national borders and an anthem."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> (Some of you may remember I
>> once set out on a misguided quest to "write my own OS". I read up on
>> some of this stuff.)
>
> That does sound like an intriguing challenge, provided you don't set out
> to design the best OS that has ever been.
Rather, I set out to design an OS that doesn't work like Unix, and
doesn't work like Windows. (Seemingly all extent OS designs are based on
one or the other - but I remember a time before that...)
> If you get to the point where you can compile, link and run a "Hello
> World" C program on that platform, that's certainly good enough for
> starters.
Again, my goal was to design an OS where nothing is ever written in C,
but rather written in safe higher-level languages with don't have buffer
overrun exploits all over the place.
> And if PC hardware seems too messy and non-standardized (which most
> certainly is the case), something like the Raspberry Pi might be an
> interesting target.
The Raspberry Pi didn't exist ten years ago, but now that I think about
it, that *would* be an interesting target...
> Then again, why design a whole OS if I'd only want to run a very limited
> set of programs on it anyway... it can't be too complicated to build a
> POV-Ray version that runs directly atop the BIOS, can it? :-P
The key problem with writing your own OS is that it's almost impossible
to debug it! Not if you run it on real hardware, anyway. Last I checked,
most VM software isn't really designed for this kind of thing either...
It's probably much, much easier to design something like the Java VM,
and then write your own proto-OS that runs inside that. And if you ever
get anywhere with that, *then* try targeting bare metal...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.01.2014 09:51, schrieb Orchid Win7 v1:
> The key problem with writing your own OS is that it's almost impossible
> to debug it! Not if you run it on real hardware, anyway. Last I checked,
> most VM software isn't really designed for this kind of thing either...
It also can't be more difficult than debugging an embedded system, and
I've been there, done that. Sending stuff to a serial port dedicated for
debugging was the standard procedure, even for "applications". For the
code portions running before the serial port was initialized, it was a
PWM output line connected to an LED or a scope.
Using the JTAG port to make the MCU single-step through the code and to
inspect the barebone register or memory values was another important tool.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> Did you know that your graphics card starts up emulating an
> IBM-manufactured video board from 27 years ago? And then you have to run
> special driver software to turn off all the pointless emulation and put
> the card into 24-bit, memory-mapped mode at a real-world screen
> resolution. Go figure...
In theory a modern PC ought to be completely backwards-compatible with
the 16-bit PCs and thus, in theory, you ought to be able to run MS-DOS
in a modern PC. (All the required hardware is still there, most of it
artificially dragging the old technology for backwards compatibility,
the BIOS still supports all the system calls used by DOS, etc.)
However, I would be *really* surprised if you actually got MS-DOS
running natively on a modern PC.
There are many hurdles that you'll encounter. Firstly, you'll need a
hard drive that's small and old enough that MS-DOS will actually be able
to use it. Also, you'll need a PS/2 keyboard because MS-DOS has no idea
what USB is. There are also probably many problems you will encounter
due to the fact that your CPU is so damn fast.
(Also, be aware that MS-DOS has no concept of keeping the CPU in idle
mode. It will run it at 100% capacity all the time, so be prepared for
some noise. Luckily it will only keep one core at 100%. The others won't
even start.)
You *might* be able to make it at least boot up, with luck and a lot
of work, and perhaps even run some programs, but eg. the majority of
old DOS games probably won't work very well. Even if a game by some
miracle runs (rather than just crashing because the computer is a
thousand times faster than even the fastest that the programmers
expected), you won't get any sounds, and you won't be able to use a mouse
(unless you have a PS/2 one).
The thing is, nobody runs MS-DOS natively anymore, and haven't done so
for well over a decade. If you really need to run an old DOS program
you'll use DOSBox anyway. Not only will the program work, it's a million
times less hassle.
So why is the PC architecture dragging all the useless stuff for MS-DOS
compatibility, when nobody's running MS-DOS anyway?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The key problem with writing your own OS is that it's almost impossible
>> to debug it! Not if you run it on real hardware, anyway. Last I checked,
>> most VM software isn't really designed for this kind of thing either...
>
> It also can't be more difficult than debugging an embedded system, and
> I've been there, done that. Sending stuff to a serial port dedicated for
> debugging was the standard procedure, even for "applications". For the
> code portions running before the serial port was initialized, it was a
> PWM output line connected to an LED or a scope.
>
> Using the JTAG port to make the MCU single-step through the code and to
> inspect the barebone register or memory values was another important tool.
Yeah, embedded systems have a serial port so you can find out what's
happening. But if the software on a desktop PC stops working... it's a
brick. There's no way to interact with it. The best you can do is reboot it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/01/2014 03:20 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull> wrote:
>> Did you know that your graphics card starts up emulating an
>> IBM-manufactured video board from 27 years ago? And then you have to run
>> special driver software to turn off all the pointless emulation and put
>> the card into 24-bit, memory-mapped mode at a real-world screen
>> resolution. Go figure...
>
> In theory a modern PC ought to be completely backwards-compatible with
> the 16-bit PCs and thus, in theory, you ought to be able to run MS-DOS
> in a modern PC. (All the required hardware is still there, most of it
> artificially dragging the old technology for backwards compatibility,
> the BIOS still supports all the system calls used by DOS, etc.)
> However, I would be *really* surprised if you actually got MS-DOS
> running natively on a modern PC.
Oh I don't know... It'll probably work.
> There are many hurdles that you'll encounter. Firstly, you'll need a
> hard drive that's small and old enough that MS-DOS will actually be able
> to use it.
I suspect so long as it isn't native 4K sectors, it'll just be reported
as 2GB.
> Also, you'll need a PS/2 keyboard because MS-DOS has no idea
> what USB is.
Many PCs have a BIOS option for PS/2 emulation. That is, to make a USB
keyboard appear to be a PS/2 one.
> There are also probably many problems you will encounter
> due to the fact that your CPU is so damn fast.
Hell yes!
> The thing is, nobody runs MS-DOS natively anymore, and haven't done so
> for well over a decade.
I'm pretty sure the in-store management system that John Lewis use is
still DOS-based. (Whether it's running natively or in some emulation
layer is another matter...)
> If you really need to run an old DOS program
> you'll use DOSBox anyway. Not only will the program work, it's a million
> times less hassle.
>
> So why is the PC architecture dragging all the useless stuff for MS-DOS
> compatibility, when nobody's running MS-DOS anyway?
No idea. Presumably because it would mean changing stuff?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
