Intel modes: 16- / 32- / 64-bit

[Rugxulo]

Hi, starting a new topic for more clarity,

BGB wrote:
> On 5/9/2012 12:48 AM, Marco van de Voort wrote:
> > On 2012-05-08, BGB<cr8...@hotmail.com> wrote:
> >> the CPU itself can run 64, 32, and 16 bit code all at the same time.
> >
> > Do you have a reference for that? I thought it was either 64/32 or 32/16,
> > but never 64/32/16 without the 16-bit being emulated.
>
> I thought so too originally.
>
> actually, only v86 mode was dropped, meaning that only MS-DOS programs
> would have required emulation, but not 16-bit Windows apps.
>
> apparently, MS concluded that it would have been too much pain/effort to
> keep 16-bit stuff still working, so this much is MS's fault.
>
> in the "System Programming Guide" of the Intel docs:
> 4.8.3.1: (IA-32e Mode Call Gates), it mentions the possibility of having
> 16-byte descriptors in the same descriptor table (such as GDT) as 32-bit
> and 16-bit entries.
>
> several other rules are stated regarding calls between 16, 32, and 64
> bit code.
>
> 3.4.5: Segment Descriptors
> L=0, D=0: 16-bit segment
> L=0, D=1: 32-bit segment
> L=1, D=0: 64-bit segment
> L=1, D=1: reserved

MarcoV and I have already briefly discussed this elsewhere. I'm no
kernel hacker, so I don't know or understand the details. He told me
that 16-bit pmode (only) was "mostly" still supported by AMD64 long
mode. I think I tried a few Win16 things successfully in WINE x64.

But DOSEMU x64 is a different matter. I haven't tried it much lately,
and I don't know the details. It "seemed" to only do (very slow)
software emulation for 16-bit real mode stuff. Other things like 16-
bit pmode (BP7) don't necessarily work at all. But 32-bit DJGPP stuff
(e.g. Quake) is native speed.

Win64 has no NTVDM nor DOSX (the pmode part). Win16 binaries, e.g. Win
3.0, were almost all pmode, and I think the Win16 API internally used
DPMI 16-bit, hence if there is no DOS, there's no DPMI, and thus no
Win16. I could be wrong, but that's my impression. It doesn't mean MS
doesn't (and hasn't) used software emulation before, but I guess it
wasn't a big priority considered how few rely on it these days. (And
they do obviously want us to migrate to newer technologies.) I don't
know, NTVDM is ancient to them and barely works since after WinXP.

VT-X first appeared circa 2006, right? AMD (supposedly) had "paged
real mode" support since then, and some things (Xen, VirtualBox) may?
support it. I don't have a working AMD machine anymore, so I haven't
tried. I do know that my Intel Core i5 has VT-X (though unlike lower-
end models, etc.), and it adds nested paging and other things like
"unrestricted guest mode execution" (real mode, big real mode). So
yes, I can run FreeDOS at seemingly native speeds under Win64 with
VirtualBox. Without VT-X, it's much much slower (10x or worse)!!

Supposedly with VT-X you can even run a 64-bit guest OS atop a 32-bit
one, but I've not tried (should I ??).

Anyways, VMs are only for convenience, more or less, since you can
(for now) always dual boot multiple OSes (since no emulation is
perfect, but native booting has its own bugs and drawbacks). At least
that will continue to work until UEFI becomes ubiquitous or somebody
decides to save a few transistors by killing off legacy mode (ugh).

(I know this post isn't much help, but it's all I know from limited
experience. Further clarification is obviously welcome.)

[BGB]

On 5/9/2012 6:13 PM, Rugxulo wrote:
> Hi, starting a new topic for more clarity,
>

pardon the delay, I have just recently moved and things are a little bit
disorganized at the moment.

AFAIK: for 32-bit DPMI, it is possible for emulators to run SW directly
in their own processes, which are managed by the emulator. Wine also
works this way.

however, in long-mode, virtual-86 mode (used for DOS) no longer works,
and hence needs to be emulated in software.

thus real-mode will run slower in this case.

> Win64 has no NTVDM nor DOSX (the pmode part). Win16 binaries, e.g. Win
> 3.0, were almost all pmode, and I think the Win16 API internally used
> DPMI 16-bit, hence if there is no DOS, there's no DPMI, and thus no
> Win16. I could be wrong, but that's my impression. It doesn't mean MS
> doesn't (and hasn't) used software emulation before, but I guess it
> wasn't a big priority considered how few rely on it these days. (And
> they do obviously want us to migrate to newer technologies.) I don't
> know, NTVDM is ancient to them and barely works since after WinXP.
>

actually, both Win3.x and Win9x were built on DOS.

this shouldn't matter though for running apps, since the apps did not
themselves generally access DOS (and most of what could be accessed via
16-bit pmode is things which could be faked, such as "int 0x21" calls or
similar).

unless it were something more like MS was just using a hacked up Windows
3.x, DOS crud and all, as their backwards-compatibility mechanism in
later Windows versions (rather than, say, giving DLLs which give the
same interface and behavior as the originals, but infact redirect to
32-bit calls or similar).


otherwise, I would have just assumed moving both DOS and Win16 into an
emulator, just one considerably lighter weight and better integrated
than their XPMode beast (personally, XPMode itself is a big sign that
"MS just didn't really give a crap"), since what they could have done
would be to make an emulator which maps the emulated windows more
directly into the host OS window manager (and not via an overlay), and
silently traps all "compatibility" apps into said emulator (which would
likely share the same file-systems as the host OS, maybe with or without
its own local OS drive, say if the VM-OS booted from 'Q' or similar, ...).

it wouldn't likely be beyond MS's powers to have done so.

> VT-X first appeared circa 2006, right? AMD (supposedly) had "paged
> real mode" support since then, and some things (Xen, VirtualBox) may?
> support it. I don't have a working AMD machine anymore, so I haven't
> tried. I do know that my Intel Core i5 has VT-X (though unlike lower-
> end models, etc.), and it adds nested paging and other things like
> "unrestricted guest mode execution" (real mode, big real mode). So
> yes, I can run FreeDOS at seemingly native speeds under Win64 with
> VirtualBox. Without VT-X, it's much much slower (10x or worse)!!
>

I have not personally messed with VT-X, as I was well out of the OS
space by then.

performance will depend greatly on the emulator.
some, such as DOSBox, essentially JIT the emulated code into code
running on the current HW.

oddly, I observed Quake running notably faster in DOSBox than I got it
running in VirtualPC, which is funny since VirtualPC uses virtualization.

it could be either the cost of the virtualization itself, or maybe the
cost of running a virtualized Windows environment and then running Quake
in it.

I since switched mostly to VMware (for Windows and Linux emulation),
given that, IMHO, it actually does a somewhat better job (higher
performance and more reliable).

> Supposedly with VT-X you can even run a 64-bit guest OS atop a 32-bit
> one, but I've not tried (should I ??).
>

dunno.

very likely, it will be limited to however much RAM can be used by the
host OS, which means that on a 32-bit system using much more than 256MB
or 512MB ram is not a good idea (otherwise severe swapping is likely).

I actually have a computer at the moment, which has 6GB of RAM but can
only use 3GB due to using 32-bit WinXP, but I can't install anything
else without another HDD, but I don't have one with me at the moment.

grr...

> Anyways, VMs are only for convenience, more or less, since you can
> (for now) always dual boot multiple OSes (since no emulation is
> perfect, but native booting has its own bugs and drawbacks). At least
> that will continue to work until UEFI becomes ubiquitous or somebody
> decides to save a few transistors by killing off legacy mode (ugh).
>

yep.

[Rugxulo]

Hi,

On May 19, 10:51 am, BGB <cr88...@hotmail.com> wrote:
> On 5/9/2012 6:13 PM, Rugxulo wrote:
>
> > Hi, starting a new topic for more clarity,
>
> pardon the delay, I have just recently moved and things are a little bit
> disorganized at the moment.

You have my sympathies.

> > MarcoV and I have already briefly discussed this elsewhere. I'm no
> > kernel hacker, so I don't know or understand the details. He told me
> > that 16-bit pmode (only) was "mostly" still supported by AMD64 long
> > mode. I think I tried a few Win16 things successfully in WINE x64.
>
> > But DOSEMU x64 is a different matter. I haven't tried it much lately,
> > and I don't know the details. It "seemed" to only do (very slow)
> > software emulation for 16-bit real mode stuff. Other things like 16-
> > bit pmode (BP7) don't necessarily work at all. But 32-bit DJGPP stuff
> > (e.g. Quake) is native speed.
>
> AFAIK: for 32-bit DPMI, it is possible for emulators to run SW directly
> in their own processes, which are managed by the emulator. Wine also
> works this way.
>
> however, in long-mode, virtual-86 mode (used for DOS) no longer works,
> and hence needs to be emulated in software.

Yes, but I don't know how much needs to be done. There are things like
LRMI, but tools like VirtualBox just use (I think?) their own BIOS and
VBIOS, even with VT-X enabled.

And in case it wasn't obvious, a 64-bit host is not a panacea for
speedy software emulation by any stretch. Painful and buggy (though
unavoidable with all the dark corners, I guess, esp. unpopular 16-bit
pmode).

> thus real-mode will run slower in this case.

It was really slow 16-bit real mode stuff last I tried (DOSEMU x64).
But at least DJGPP was native speed. Too bad Win64 can't do it as
well.

> > Win64 has no NTVDM nor DOSX (the pmode part). Win16 binaries, e.g. Win
> > 3.0, were almost all pmode, and I think the Win16 API internally used
> > DPMI 16-bit, hence if there is no DOS, there's no DPMI, and thus no
> > Win16. I could be wrong, but that's my impression. It doesn't mean MS
> > doesn't (and hasn't) used software emulation before, but I guess it
> > wasn't a big priority considered how few rely on it these days. (And
> > they do obviously want us to migrate to newer technologies.) I don't
> > know, NTVDM is ancient to them and barely works since after WinXP.
>
> actually, both Win3.x and Win9x were built on DOS.

Yes, but they did other (weirder) things too. ;-)

> this shouldn't matter though for running apps, since the apps did not
> themselves generally access DOS (and most of what could be accessed via
> 16-bit pmode is things which could be faked, such as "int 0x21" calls or
> similar).

Dunno, I'm not versed in all the gory details of 32-bit pmode.

> unless it were something more like MS was just using a hacked up Windows
> 3.x, DOS crud and all, as their backwards-compatibility mechanism in
> later Windows versions (rather than, say, giving DLLs which give the
> same interface and behavior as the originals, but infact redirect to
> 32-bit calls or similar).

Yes, I think their NTVDM was indeed a lot of hacked pieces from older
software. It wasn't 100% homebrewed, so perhaps they didn't know how
to fix it.

> otherwise, I would have just assumed moving both DOS and Win16 into an
> emulator, just one considerably lighter weight and better integrated
> than their XPMode beast (personally, XPMode itself is a big sign that
> "MS just didn't really give a crap"),

Yes, I feel that XP Mode was a marketing gimmick to drive sales. It
really shouldn't be necessary. Anything (esp. Win32 apps!!) that
doesn't run any longer on modern Windows proves that something is
broken, and regressions for MS are very bad for business.

> since what they could have done
> would be to make an emulator which maps the emulated windows more
> directly into the host OS window manager (and not via an overlay), and
> silently traps all "compatibility" apps into said emulator (which would
> likely share the same file-systems as the host OS, maybe with or without
> its own local OS drive, say if the VM-OS booted from 'Q' or similar, ...).
>
> it wouldn't likely be beyond MS's powers to have done so.

Dunno. They do have 90000 employees, but they seem to be focused on a
billion other goofy things.

Anyways, we do have DOSBox, which (mostly) fulfills the need (except
for compiling stuff).

> > VT-X first appeared circa 2006, right? AMD (supposedly) had "paged
> > real mode" support since then, and some things (Xen, VirtualBox) may?
> > support it. I don't have a working AMD machine anymore, so I haven't
> > tried. I do know that my Intel Core i5 has VT-X (though unlike lower-
> > end models, etc.), and it adds nested paging and other things like
> > "unrestricted guest mode execution" (real mode, big real mode). So
> > yes, I can run FreeDOS at seemingly native speeds under Win64 with
> > VirtualBox. Without VT-X, it's much much slower (10x or worse)!!
>
> I have not personally messed with VT-X, as I was well out of the OS
> space by then.

I don't mean I've coded any hypervisors either, I'm just saying that
VT-X is something fairly new that may or may not be a successor to the
whole V86 mode idea.

> performance will depend greatly on the emulator.
> some, such as DOSBox, essentially JIT the emulated code into code
> running on the current HW.

I have no idea what DOSBox does, but it's very slow. Perhaps you mean
"core=auto"? That doesn't always work. It's only "fast 486" speeds, at
best. It's a great piece of software, but you can't rely on it for
anything time intensive.

> oddly, I observed Quake running notably faster in DOSBox than I got it
> running in VirtualPC, which is funny since VirtualPC uses virtualization.

Yeah, I dunno, perhaps they heavily tuned it for Quake, Doom, etc.
That would make sense as they always say "only for games!". It's
really NOT faster for anything else, so maybe their VBIOS is heavily
optimized, who knows. (And their DOS is fake, BTW, it's not real like
FreeDOS, similarly the BIOS, etc.)

> it could be either the cost of the virtualization itself, or maybe the
> cost of running a virtualized Windows environment and then running Quake
> in it.

Dunno. Maybe SDL achieves most of that speedup. I think?? I heard that
SDL has some partial multi-threading nowadays, maybe for audio, can't
remember. Or maybe it uses a different speedier gfx backend nowadays
(DirectX?), dunno.

I was running Doom 1.9 shareware under various environments yesterday.
Indeed, it's "mostly" native speed under VBox + VT-X, but it still had
minor issues (and wasn't fastest, ironically). I'm not sure, a naive
guess makes me think polling to emulate SB ports for sound was slowing
it down, but I could be wrong. (Anyways, VBox devs really don't test
16-bit nor DOS that much, they focus much more heavily on other OSes.)

> I since switched mostly to VMware (for Windows and Linux emulation),
> given that, IMHO, it actually does a somewhat better job (higher
> performance and more reliable).

Dunno, I've never tried it, but I've heard good things. It may be
better, and some people I see online swear by it.

> > Supposedly with VT-X you can even run a 64-bit guest OS atop a 32-bit
> > one, but I've not tried (should I ??).
>
> dunno.
>
> very likely, it will be limited to however much RAM can be used by the
> host OS, which means that on a 32-bit system using much more than 256MB
> or 512MB ram is not a good idea (otherwise severe swapping is likely).

True, but I'm just curious. At least, I know QEMU used (?) to have a
software-only 64-bit emulation version, but here I mostly meant "as if
native" speed. So it would be cool to know for sure I can run a 64-bit
OS atop a 32-bit one. Heck, who knows, perhaps one day a 64-bit DOS
(extender) will piggyback atop VT-X (but I'm not getting my hopes up).

> I actually have a computer at the moment, which has 6GB of RAM but can
> only use 3GB due to using 32-bit WinXP, but I can't install anything
> else without another HDD, but I don't have one with me at the moment.
>
> grr...

Sorry. MS refuses to support PAE APIs there, so you're limited to
about 3.1 GB, from what I've heard. It should be enough (and besides,
XP inherently uses lots less RAM than Vista or 7). Vista on up let you
resize the NTFS, but for XP you might have to use GParted. Probably
safe, but caveat emptor.

> > Anyways, VMs are only for convenience, more or less, since you can
> > (for now) always dual boot multiple OSes (since no emulation is
> > perfect, but native booting has its own bugs and drawbacks). At least
> > that will continue to work until UEFI becomes ubiquitous or somebody
> > decides to save a few transistors by killing off legacy mode (ugh).
>
> yep.

If software emulation was 100% accurate and "fast enough", then who
could complain? But it never is, sadly. It feels like we're on a
constant upgrade treadmill. It really shouldn't be this hard to have
working software running stable across so many years (sigh).

Meh, I need to try BOCHS again, Darek M. claims to have done a lot of
good stuff over the past few years. ;-)

[BGB]

typically, emulators use their own BIOS and simulate all the HW as well,
so this is nothing new.

> And in case it wasn't obvious, a 64-bit host is not a panacea for
> speedy software emulation by any stretch. Painful and buggy (though
> unavoidable with all the dark corners, I guess, esp. unpopular 16-bit
> pmode).
>

yes, but it can be done.
one option for emulating 16-bit pmode (besides running it directly, or
using a pure software emulator) would be essentially compiling
instruction traces into the native ISA (x86 or x86-64).

>> thus real-mode will run slower in this case.
>
> It was really slow 16-bit real mode stuff last I tried (DOSEMU x64).
> But at least DJGPP was native speed. Too bad Win64 can't do it as
> well.
>

DOSBox isn't native speed, but seems to be not that drastically worse.
the main big issue is likely how the emulator is implemented, like
whether it is closer to being a plain interpreter, or closer to being a JIT.

>>> Win64 has no NTVDM nor DOSX (the pmode part). Win16 binaries, e.g. Win
>>> 3.0, were almost all pmode, and I think the Win16 API internally used
>>> DPMI 16-bit, hence if there is no DOS, there's no DPMI, and thus no
>>> Win16. I could be wrong, but that's my impression. It doesn't mean MS
>>> doesn't (and hasn't) used software emulation before, but I guess it
>>> wasn't a big priority considered how few rely on it these days. (And
>>> they do obviously want us to migrate to newer technologies.) I don't
>>> know, NTVDM is ancient to them and barely works since after WinXP.
>>
>> actually, both Win3.x and Win9x were built on DOS.
>
> Yes, but they did other (weirder) things too. ;-)
>

possibly.

>> this shouldn't matter though for running apps, since the apps did not
>> themselves generally access DOS (and most of what could be accessed via
>> 16-bit pmode is things which could be faked, such as "int 0x21" calls or
>> similar).
>
> Dunno, I'm not versed in all the gory details of 32-bit pmode.
>

well, 16-bit and 32-bit pmode are a bit different.


typically on Windows, the only "valid" way to access the OS is via API
calls (into OS DLLs). this is not the only way possible though.

IIRC, on Win9x it was still possible to use DOS interrupts (in pmode),
which would trap into DOS (in v86 mode). however, such code will (AFAIK)
no longer work on XP or newer (and did not work on WinNT).

note that in neither case is there any direct access to raw HW, rather
the application runs in a virtual address space (IIRC, there were some
differences between the Win9x and WinNT lines here, where on Win9x it
was possible to see a lot of memory shared across process/task
boundaries, including the low 1MB/DOS space, whereas the NT line ran
every process in its own fully-disjoint address space).


so, Win9x:
low 4MB: shared (read/write in Ring3), identity mapped to low 4MB of
system RAM (low 1MB was DOS space);
4MB-2GB: local space for each process;
2GB-3GB: shared memory (R/W to Ring3);
3GB-4GB: kernel memory (not accessible to Ring3).

and, WinNT/XP:
0MB-4MB: stack for main thread (low 64KB is an inaccessible NULL page);
4MB-2/3GB: local space for each process;
2GB/3GB-4GB: kernel memory.

it is possible to explicitly create shared memory in NT/XP+, but it has
no fixed location in the memory map;


for the most part, the basic idea is that one has a 2GB (9x/NT) or 3GB
(XP+) chunk of usable address space, which was unique to the process,
the only things directly existing within this space being the contents
mapped in from EXEs or DLLs, and things like allocated heap memory.


in the case of 32-bit Windows, system calls would generally be made
directly via "int 0x2e" instructions to call into the kernel.

in 64-bit Windows, the process differs some:
32-bit code will go through a thunk/trampoline, which will execute a far
jump to get into 64-bit mode, which will then call into the kernel via a
"syscall" instruction (and then use a far jump back into 32-bit code).

>> unless it were something more like MS was just using a hacked up Windows
>> 3.x, DOS crud and all, as their backwards-compatibility mechanism in
>> later Windows versions (rather than, say, giving DLLs which give the
>> same interface and behavior as the originals, but infact redirect to
>> 32-bit calls or similar).
>
> Yes, I think their NTVDM was indeed a lot of hacked pieces from older
> software. It wasn't 100% homebrewed, so perhaps they didn't know how
> to fix it.
>

dunno.

I guess if they really wanted, they could have re-implemented it.

>> otherwise, I would have just assumed moving both DOS and Win16 into an
>> emulator, just one considerably lighter weight and better integrated
>> than their XPMode beast (personally, XPMode itself is a big sign that
>> "MS just didn't really give a crap"),
>
> Yes, I feel that XP Mode was a marketing gimmick to drive sales. It
> really shouldn't be necessary. Anything (esp. Win32 apps!!) that
> doesn't run any longer on modern Windows proves that something is
> broken, and regressions for MS are very bad for business.
>

nevermind that XPMode kind of sucks...

>> since what they could have done
>> would be to make an emulator which maps the emulated windows more
>> directly into the host OS window manager (and not via an overlay), and
>> silently traps all "compatibility" apps into said emulator (which would
>> likely share the same file-systems as the host OS, maybe with or without
>> its own local OS drive, say if the VM-OS booted from 'Q' or similar, ...).
>>
>> it wouldn't likely be beyond MS's powers to have done so.
>
> Dunno. They do have 90000 employees, but they seem to be focused on a
> billion other goofy things.
>
> Anyways, we do have DOSBox, which (mostly) fulfills the need (except
> for compiling stuff).
>

possibly, but people like old stuff to keep working without issue.
breaking 16-bit apps forced me into going and finding more modern
alternatives for some apps (some of which aren't as good).

>>> VT-X first appeared circa 2006, right? AMD (supposedly) had "paged
>>> real mode" support since then, and some things (Xen, VirtualBox) may?
>>> support it. I don't have a working AMD machine anymore, so I haven't
>>> tried. I do know that my Intel Core i5 has VT-X (though unlike lower-
>>> end models, etc.), and it adds nested paging and other things like
>>> "unrestricted guest mode execution" (real mode, big real mode). So
>>> yes, I can run FreeDOS at seemingly native speeds under Win64 with
>>> VirtualBox. Without VT-X, it's much much slower (10x or worse)!!
>>
>> I have not personally messed with VT-X, as I was well out of the OS
>> space by then.
>
> I don't mean I've coded any hypervisors either, I'm just saying that
> VT-X is something fairly new that may or may not be a successor to the
> whole V86 mode idea.
>

possibly.


if observations are to be believed, hypervisors have their own costs.
although the code itself runs fast, a drawback appears to be that HW
still needs to be emulated in software, and switches in-to/out-of the
hypervisor appear to be fairly costly (and on-average, everything still
runs considerably slower than on raw HW).

this and other costs make me doubt whether they are ideal for
lightweight emulators, and whether a strategy such as trace-translation
would give considerably better overall performance for a lightweight VM,
since in many cases the emulated code will not be CPU-bound (and even
then, trace-translation should probably be able to get within 3x-5x of
native anyways).

>> performance will depend greatly on the emulator.
>> some, such as DOSBox, essentially JIT the emulated code into code
>> running on the current HW.
>
> I have no idea what DOSBox does, but it's very slow. Perhaps you mean
> "core=auto"? That doesn't always work. It's only "fast 486" speeds, at
> best. It's a great piece of software, but you can't rely on it for
> anything time intensive.
>

I was running Quake on it at fairly high resolutions (1280x1024 and
similar) and getting considerably better performance than in XPMode.

so, this is a good deal faster than any 486 I know of...

so, at least my experience with DOSBox has been fairly good here.


now, vs native, I have little idea...

>> oddly, I observed Quake running notably faster in DOSBox than I got it
>> running in VirtualPC, which is funny since VirtualPC uses virtualization.
>
> Yeah, I dunno, perhaps they heavily tuned it for Quake, Doom, etc.
> That would make sense as they always say "only for games!". It's
> really NOT faster for anything else, so maybe their VBIOS is heavily
> optimized, who knows. (And their DOS is fake, BTW, it's not real like
> FreeDOS, similarly the BIOS, etc.)
>

well, for Quake it worked pretty well...

meanwhile, Quake on XPMode was kind of laggy, as was XPMode in general.

I wasn't very impressed with what is supposed to be native-speed
execution lagging with an old game. granted, it could maybe be due to
scheduling, like native Windows limits the VirtualPC time-slice, and
then the contained WinXP limits Quake's time-slice.


VMware seems to work considerably better though.

running WinXP or Linux in VMware seems to be fairly responsive, so I
don't really know.

>> it could be either the cost of the virtualization itself, or maybe the
>> cost of running a virtualized Windows environment and then running Quake
>> in it.
>
> Dunno. Maybe SDL achieves most of that speedup. I think?? I heard that
> SDL has some partial multi-threading nowadays, maybe for audio, can't
> remember. Or maybe it uses a different speedier gfx backend nowadays
> (DirectX?), dunno.
>

I think it is still SDL.

graphics shouldn't matter so much, since in this case they are mostly
just drawing into a virtual framebuffer and then displaying the contents
of said framebuffer using GL. this isn't really a task which itself
demands high-performance.


although, DOSBox does have options to throttle back the simulated
clock-rate such that some very old DOS games don't break due to running
too fast, which could be making an issue here.

> I was running Doom 1.9 shareware under various environments yesterday.
> Indeed, it's "mostly" native speed under VBox + VT-X, but it still had
> minor issues (and wasn't fastest, ironically). I'm not sure, a naive
> guess makes me think polling to emulate SB ports for sound was slowing
> it down, but I could be wrong. (Anyways, VBox devs really don't test
> 16-bit nor DOS that much, they focus much more heavily on other OSes.)
>

yeah.

>> I since switched mostly to VMware (for Windows and Linux emulation),
>> given that, IMHO, it actually does a somewhat better job (higher
>> performance and more reliable).
>
> Dunno, I've never tried it, but I've heard good things. It may be
> better, and some people I see online swear by it.
>

well, WinXP seems less laggy in VMware, and I can install whatever OS's
in it without them breaking (VirtualPC was prone to instead cause OS
installers to break).

not compared with VirtualBox though...

>>> Supposedly with VT-X you can even run a 64-bit guest OS atop a 32-bit
>>> one, but I've not tried (should I ??).
>>
>> dunno.
>>
>> very likely, it will be limited to however much RAM can be used by the
>> host OS, which means that on a 32-bit system using much more than 256MB
>> or 512MB ram is not a good idea (otherwise severe swapping is likely).
>
> True, but I'm just curious. At least, I know QEMU used (?) to have a
> software-only 64-bit emulation version, but here I mostly meant "as if
> native" speed. So it would be cool to know for sure I can run a 64-bit
> OS atop a 32-bit one. Heck, who knows, perhaps one day a 64-bit DOS
> (extender) will piggyback atop VT-X (but I'm not getting my hopes up).
>

QEMU seems able to emulate all sorts of stuff, and I was using it to
emulate Linux/ARM on x86 a while back.

its downside though is that it is not exactly high-performance IME (or,
at least, the QEMU versions for Windows).

>> I actually have a computer at the moment, which has 6GB of RAM but can
>> only use 3GB due to using 32-bit WinXP, but I can't install anything
>> else without another HDD, but I don't have one with me at the moment.
>>
>> grr...
>
> Sorry. MS refuses to support PAE APIs there, so you're limited to
> about 3.1 GB, from what I've heard. It should be enough (and besides,
> XP inherently uses lots less RAM than Vista or 7). Vista on up let you
> resize the NTFS, but for XP you might have to use GParted. Probably
> safe, but caveat emptor.
>

I was previously running XP64 on the thing, but XP64 was on a secondary
drive which I ended up taking out. I would need to install a secondary
HDD in order to have a drive on which to install XP64 again (there are
no suitable partitions remaining on this drive, and at the moment I am
not so much inclined to install over the currently-still-working WinXP
install).

it is mostly a matter of needing another SATA HDD, but all I have
on-hand are older IDE drives.

>>> Anyways, VMs are only for convenience, more or less, since you can
>>> (for now) always dual boot multiple OSes (since no emulation is
>>> perfect, but native booting has its own bugs and drawbacks). At least
>>> that will continue to work until UEFI becomes ubiquitous or somebody
>>> decides to save a few transistors by killing off legacy mode (ugh).
>>
>> yep.
>
> If software emulation was 100% accurate and "fast enough", then who
> could complain? But it never is, sadly. It feels like we're on a
> constant upgrade treadmill. It really shouldn't be this hard to have
> working software running stable across so many years (sigh).
>
> Meh, I need to try BOCHS again, Darek M. claims to have done a lot of
> good stuff over the past few years. ;-)

"fast enough" should work for most older software...

even if it runs 100x slower than native, it is probably still running
faster than on the hardware it was originally designed for.

most 16-bit software was written for 386 and 486 systems, so even if the
emulator is slow, who really needs to care all that much?...


it is partly for these reasons I had considered the idea of trying to
port Quake to the BGBScript VM: yes, the VM isn't very fast, but would
still likely be able to run Quake faster than on the original HW.

the much bigger issue though is the part about having to write all of
the stuff to compile the C front-end's ASTs to the VM's bytecode, which
looks like a big PITA and I haven't invested much effort into this.

the other major option being a language-port (rewriting Quake from C to
BGBScript), but this also looks like a big PITA (but, is not impossible,
as the Quake codebase isn't terribly large either). a drawback though is
even if I did the port this way, Quake would still be GPL'ed, so I can't
really make much practical use of its code in an otherwise non-GPL project.


or such...

[Rugxulo]

Hi,

On May 20, 3:20 pm, BGB <cr88...@hotmail.com> wrote:
> On 5/19/2012 8:48 PM, Rugxulo wrote:
>
> > On May 19, 10:51 am, BGB<cr88...@hotmail.com>  wrote:
> >> On 5/9/2012 6:13 PM, Rugxulo wrote:
>
> > Yes, but I don't know how much needs to be done. There are things like
> > LRMI, but tools like VirtualBox just use (I think?) their own BIOS and
> > VBIOS, even with VT-X enabled.
>
> typically, emulators use their own BIOS and simulate all the HW as well,
> so this is nothing new.

Okay, but wouldn't using a real BIOS be less buggy? If LRMI can do it,
you'd think VirtualBox can too, esp. with VT-X. But I'm probably naive
here (esp. since don't know the details).

> > And in case it wasn't obvious, a 64-bit host is not a panacea for
> > speedy software emulation by any stretch. Painful and buggy (though
> > unavoidable with all the dark corners, I guess, esp. unpopular 16-bit
> > pmode).
>
> yes, but it can be done.
> one option for emulating 16-bit pmode (besides running it directly, or
> using a pure software emulator) would be essentially compiling
> instruction traces into the native ISA (x86 or x86-64).

Seems there is always an expected 10x slowdown for emulation, at best,
so that's not good, at least not for grueling tasks like compiling.

> >> thus real-mode will run slower in this case.
>
> > It was really slow 16-bit real mode stuff last I tried (DOSEMU x64).
> > But at least DJGPP was native speed. Too bad Win64 can't do it as
> > well.
>
> DOSBox isn't native speed, but seems to be not that drastically worse.
> the main big issue is likely how the emulator is implemented, like
> whether it is closer to being a plain interpreter, or closer to being a JIT.

It's fairly bad. They've tuned it only for games, so those (circa
486-586, Doom or Quake) are okay, but everything else isn't suggested.
Well, I keep thinking back when I tried to compile something with
DJGPP under DOSBox, it took way way way too long (seven minutes? vs.
maybe 30 secs native). In cases like that, VirtualBox + VT-X or DOSEMU
are obviously much faster.

BTW, I've been told that a 64-bit DOSBox is even slower, but that
apparently didn't stop Fedora 64-bit! :-/

> >> performance will depend greatly on the emulator.
> >> some, such as DOSBox, essentially JIT the emulated code into code
> >> running on the current HW.
>
> > I have no idea what DOSBox does, but it's very slow. Perhaps you mean
> > "core=auto"? That doesn't always work. It's only "fast 486" speeds, at
> > best. It's a great piece of software, but you can't rely on it for
> > anything time intensive.
>
> I was running Quake on it at fairly high resolutions (1280x1024 and
> similar) and getting considerably better performance than in XPMode.

But XP Mode explicitly isn't targeted at home users (only available
for businesses) because of reasons like this. Or so they claim. XP
Mode isn't really meant for graphics or games, which is what home
consumers typically use.

> so, this is a good deal faster than any 486 I know of...

Keep in mind that Quake was heavily tuned for an Intel Pentium
pipelined FPU. A real 486 DX (like what DOSBox pretends to be), even a
so-called fast variant, wouldn't be fast enough.

> so, at least my experience with DOSBox has been fairly good here.
>
> now, vs native, I have little idea...

Quake does run "mostly" well in DOSBox. It might depend on host cpu
speed. Actually, I remember getting some stuttering sounds from it for
some sfx, but overall it was pretty good (and similarly the DJGPP-
based port of Hexen2, aka Hammer of Thyrion). Like I said, those run
"as if native" under DOSEMU x64 since it's mostly 32-bit code anyways.

> >> oddly, I observed Quake running notably faster in DOSBox than I got it
> >> running in VirtualPC, which is funny since VirtualPC uses virtualization.
>
> > Yeah, I dunno, perhaps they heavily tuned it for Quake, Doom, etc.
> > That would make sense as they always say "only for games!". It's
> > really NOT faster for anything else, so maybe their VBIOS is heavily
> > optimized, who knows. (And their DOS is fake, BTW, it's not real like
> > FreeDOS, similarly the BIOS, etc.)
>
> well, for Quake it worked pretty well...
>
> meanwhile, Quake on XPMode was kind of laggy, as was XPMode in general.

I've never used VPC, but at one time I heard it was only an emulated
P2. And actually XP Mode originally "required" VT-X, but since lots of
computers don't have it, MS "fixed" that, heh.

> I wasn't very impressed with what is supposed to be native-speed
> execution lagging with an old game. granted, it could maybe be due to
> scheduling, like native Windows limits the VirtualPC time-slice, and
> then the contained WinXP limits Quake's time-slice.

Presumably that, yes. Actually, now that I think of it, are you
running DOSBox under XP Mode? Because I don't think Quake runs under
WinNT-based machines (near ptr unsupported there) as opposed to
earlier Win95. Well, maybe you meant a Windows port, not the
"original" DJGPP commercial version.

Yeah, it could be anything, I don't exactly know, could be the
emulated video card or any number of issues.

> VMware seems to work considerably better though.
>
> running WinXP or Linux in VMware seems to be fairly responsive, so I
> don't really know.

They've just done a better job, I suppose. They have a good rep,
presumably for a reason. ;-)

> >> it could be either the cost of the virtualization itself, or maybe the
> >> cost of running a virtualized Windows environment and then running Quake
> >> in it.
>
> > Dunno. Maybe SDL achieves most of that speedup. I think?? I heard that
> > SDL has some partial multi-threading nowadays, maybe for audio, can't
> > remember. Or maybe it uses a different speedier gfx backend nowadays
> > (DirectX?), dunno.
>
> I think it is still SDL.

Yes, I mean perhaps SDL uses DirectX as optional backend these days,
not sure.

> graphics shouldn't matter so much, since in this case they are mostly
> just drawing into a virtual framebuffer and then displaying the contents
> of said framebuffer using GL. this isn't really a task which itself
> demands high-performance.

Define "high", heheh. Quake is circa late 1996, targeting DOS in Intel
Pentium territory, heavy FPU usage specifically for that machine. So a
P60 should be fast enough, even running Win95. Even giving the typical
10x - 15x slowdown of emulation, we should easily be running at native
speed. But I guess XP Mode (due to XP?) tries to do too much. Maybe
its FPU emulation is slow, who knows, though I'd assume (hope?) they
would just use the native cpu for things like that.

> although, DOSBox does have options to throttle back the simulated
> clock-rate such that some very old DOS games don't break due to running
> too fast, which could be making an issue here.

Doubt it, though I don't know how well it "guesses" what speed to run.
In other words, I'm not sure "core=auto" always works.

For all we know, it could be your video card driver or similar. I
don't pretend to understand all those things, but I know Intel gfx
cards are fairly slow, comparatively, though I hear their latest Ivy
Bridge improves that a lot. I know a lot of software seems to stumbles
with Intel gfx for some odd reason.

> >>> Supposedly with VT-X you can even run a 64-bit guest OS atop a 32-bit
> >>> one, but I've not tried (should I ??).
>
> >> dunno.
>
> >> very likely, it will be limited to however much RAM can be used by the
> >> host OS, which means that on a 32-bit system using much more than 256MB
> >> or 512MB ram is not a good idea (otherwise severe swapping is likely).
>
> > True, but I'm just curious. At least, I know QEMU used (?) to have a
> > software-only 64-bit emulation version, but here I mostly meant "as if
> > native" speed. So it would be cool to know for sure I can run a 64-bit
> > OS atop a 32-bit one. Heck, who knows, perhaps one day a 64-bit DOS
> > (extender) will piggyback atop VT-X (but I'm not getting my hopes up).
>
> QEMU seems able to emulate all sorts of stuff, and I was using it to
> emulate Linux/ARM on x86 a while back.
>
> its downside though is that it is not exactly high-performance IME (or,
> at least, the QEMU versions for Windows).

The old KQEMU accelerator used to help a lot, but that's long
deprecated. VirtualBox has a recompiler, and it does help, but I'm not
sure how well.

> >> I actually have a computer at the moment, which has 6GB of RAM but can
> >> only use 3GB due to using 32-bit WinXP, but I can't install anything
> >> else without another HDD, but I don't have one with me at the moment.
>
> >> grr...
>
> > Sorry. MS refuses to support PAE APIs there, so you're limited to
> > about 3.1 GB, from what I've heard. It should be enough (and besides,
> > XP inherently uses lots less RAM than Vista or 7). Vista on up let you
> > resize the NTFS, but for XP you might have to use GParted. Probably
> > safe, but caveat emptor.
>
> I was previously running XP64 on the thing, but XP64 was on a secondary
> drive which I ended up taking out. I would need to install a secondary
> HDD in order to have a drive on which to install XP64 again (there are
> no suitable partitions remaining on this drive, and at the moment I am
> not so much inclined to install over the currently-still-working WinXP
> install).
>
> it is mostly a matter of needing another SATA HDD, but all I have
> on-hand are older IDE drives.

Can't you run the drive in IDE legacy mode?

> > Meh, I need to try BOCHS again, Darek M. claims to have done a lot of
> > good stuff over the past few years.   ;-)
>
> "fast enough" should work for most older software...
>
> even if it runs 100x slower than native, it is probably still running
> faster than on the hardware it was originally designed for.

But native 486 speed is still "slow", IMHO. :-))

> most 16-bit software was written for 386 and 486 systems, so even if the
> emulator is slow, who really needs to care all that much?...

Depends on the app. Obviously the point is that better solutions (V86
mode) are sometimes unavailable, which does show a huge decrease in
performance. I guess we never thought V86 would go away nor realized
how painful software emulation could be.

> it is partly for these reasons I had considered the idea of trying to
> port Quake to the BGBScript VM: yes, the VM isn't very fast, but would
> still likely be able to run Quake faster than on the original HW.
>
> the much bigger issue though is the part about having to write all of
> the stuff to compile the C front-end's ASTs to the VM's bytecode, which
> looks like a big PITA and I haven't invested much effort into this.

You'd probably almost have an easier time just emulating the raw i386
assembly!

[Rod Pemberton]

"Rugxulo" <rug...@gmail.com> wrote in message
news:922ccaf1-5bd7-4959...@d33g2000yqa.googlegroups.com...

> On May 20, 3:20 pm, BGB <cr88...@hotmail.com> wrote:

> > typically, emulators use their own BIOS and simulate all
> > the HW as well, so this is nothing new.
>
> Okay, but wouldn't using a real BIOS be less buggy?
>

I think the point of that is so that the emulator can have a BIOS which
either 1) is without code for hardware or chipsets, or 2) is with code for a
very specific chipset. If without, the emulator doesn't have to emulate
that hardware too. If with, the emulator emulates a chipset that the
emulator's authors know how to emulate. If a real BIOS was used, the
emulator might encounter some code it couldn't emulate or which could cause
problems, e.g., the BIOS functions which use PM, or special registers in
certain chipsets for video modes, etc.


Rod Pemberton

[BGB]

On 5/22/2012 11:21 AM, Rugxulo wrote:
> Hi,
>
> On May 20, 3:20 pm, BGB<cr88...@hotmail.com> wrote:
>> On 5/19/2012 8:48 PM, Rugxulo wrote:
>>
>>> On May 19, 10:51 am, BGB<cr88...@hotmail.com> wrote:
>>>> On 5/9/2012 6:13 PM, Rugxulo wrote:
>>
>>> Yes, but I don't know how much needs to be done. There are things like
>>> LRMI, but tools like VirtualBox just use (I think?) their own BIOS and
>>> VBIOS, even with VT-X enabled.
>>
>> typically, emulators use their own BIOS and simulate all the HW as well,
>> so this is nothing new.
>
> Okay, but wouldn't using a real BIOS be less buggy? If LRMI can do it,
> you'd think VirtualBox can too, esp. with VT-X. But I'm probably naive
> here (esp. since don't know the details).
>

not necessarily.

a real BIOS will deal with lots of stuff which would be N/A in a
virtualized environment, such as setting up and managing DRAM, a lot of
SMM and ACPI related stuff, ... it would also mean emulating a lot of
chipset related HW, such as the northbridge and southbridge, ...).

more likely, an emulator wont bother with a lot of this, and instead
focus more on the sorts of HW the OS is more likely to care about: the
ATA controller, video card, sound-card, ...

so, very possibly, an emulated BIOS may not actually implement a lot of
functionality, but would instead trap into native code, ...

>>> And in case it wasn't obvious, a 64-bit host is not a panacea for
>>> speedy software emulation by any stretch. Painful and buggy (though
>>> unavoidable with all the dark corners, I guess, esp. unpopular 16-bit
>>> pmode).
>>
>> yes, but it can be done.
>> one option for emulating 16-bit pmode (besides running it directly, or
>> using a pure software emulator) would be essentially compiling
>> instruction traces into the native ISA (x86 or x86-64).
>
> Seems there is always an expected 10x slowdown for emulation, at best,
> so that's not good, at least not for grueling tasks like compiling.
>

it is not always 10x, it may be more or less, depending on how the
emulator is implemented...

but, seriously, if one is running some old Win 3.11 app, and it runs 10x
slower than native, but also 10x faster than the 33MHz 486 or whatever
it was designed to run on, where is the problem?...

far more likely it would be necessary to actually throttle it back to
prevent it from running too fast and then breaking.

>>>> thus real-mode will run slower in this case.
>>
>>> It was really slow 16-bit real mode stuff last I tried (DOSEMU x64).
>>> But at least DJGPP was native speed. Too bad Win64 can't do it as
>>> well.
>>
>> DOSBox isn't native speed, but seems to be not that drastically worse.
>> the main big issue is likely how the emulator is implemented, like
>> whether it is closer to being a plain interpreter, or closer to being a JIT.
>
> It's fairly bad. They've tuned it only for games, so those (circa
> 486-586, Doom or Quake) are okay, but everything else isn't suggested.
> Well, I keep thinking back when I tried to compile something with
> DJGPP under DOSBox, it took way way way too long (seven minutes? vs.
> maybe 30 secs native). In cases like that, VirtualBox + VT-X or DOSEMU
> are obviously much faster.
>

well, yes, but most people probably aren't using DOSBox for running DJGPP...

try digging out an old 386 or 486 and running the same build on that,
and it will proably also be fairly slow.


OTOH: I did have some experiences compiling code in this setup:
GCC running on Linux/ARMv5tel inside QEMU, running inside Fedora 14
x86-64, running inside VMware, running on Windows 7 x64.

admittedly, rebuilds were hardly fast (although my script VM was still
fairly usable and responsive, despite the script code apparently running
something like 20000x slower than native...).

> BTW, I've been told that a 64-bit DOSBox is even slower, but that
> apparently didn't stop Fedora 64-bit! :-/
>

possibly.
IIRC, I was using the 64-bit DOSBox for running Quake.

>>>> performance will depend greatly on the emulator.
>>>> some, such as DOSBox, essentially JIT the emulated code into code
>>>> running on the current HW.
>>
>>> I have no idea what DOSBox does, but it's very slow. Perhaps you mean
>>> "core=auto"? That doesn't always work. It's only "fast 486" speeds, at
>>> best. It's a great piece of software, but you can't rely on it for
>>> anything time intensive.
>>
>> I was running Quake on it at fairly high resolutions (1280x1024 and
>> similar) and getting considerably better performance than in XPMode.
>
> But XP Mode explicitly isn't targeted at home users (only available
> for businesses) because of reasons like this. Or so they claim. XP
> Mode isn't really meant for graphics or games, which is what home
> consumers typically use.
>

I got it because it was available for Windows 7 Professional, which I
got via the whole MSDNAA (MSDN Academic Alliance) thing (due to being a
college student).

I have also observed that emulators also really seem to like emulating
the S3 Virge (along with the RTL8139 and NE2K cards).

>> so, this is a good deal faster than any 486 I know of...
>
> Keep in mind that Quake was heavily tuned for an Intel Pentium
> pipelined FPU. A real 486 DX (like what DOSBox pretends to be), even a
> so-called fast variant, wouldn't be fast enough.
>

I ran Quake "ok" on some 486DX systems (my main computer around the time
was a 486 DX2 66). Quake was kind of laggy, but it was generally playable.

IIRC, my next computer (following this one) used an Intel Celeron.
then I was annoyed as then a game game out ("Quake 3 Arena"), which
wouldn't work on this computer (due to requiring 3D capabilities beyond
those of the S3 card I had in the thing. Q3A all like "nope, not gonna
work...").

then, later, another computer using an Athlon and a GeForce2, which ran
Q3A, UT, and HL fairly good (and by this point the Quake source was
available, so I messed with this a fair amount).

>> so, at least my experience with DOSBox has been fairly good here.
>>
>> now, vs native, I have little idea...
>
> Quake does run "mostly" well in DOSBox. It might depend on host cpu
> speed. Actually, I remember getting some stuttering sounds from it for
> some sfx, but overall it was pretty good (and similarly the DJGPP-
> based port of Hexen2, aka Hammer of Thyrion). Like I said, those run
> "as if native" under DOSEMU x64 since it's mostly 32-bit code anyways.
>

yep, fair enough.

>>>> oddly, I observed Quake running notably faster in DOSBox than I got it
>>>> running in VirtualPC, which is funny since VirtualPC uses virtualization.
>>
>>> Yeah, I dunno, perhaps they heavily tuned it for Quake, Doom, etc.
>>> That would make sense as they always say "only for games!". It's
>>> really NOT faster for anything else, so maybe their VBIOS is heavily
>>> optimized, who knows. (And their DOS is fake, BTW, it's not real like
>>> FreeDOS, similarly the BIOS, etc.)
>>
>> well, for Quake it worked pretty well...
>>
>> meanwhile, Quake on XPMode was kind of laggy, as was XPMode in general.
>
> I've never used VPC, but at one time I heard it was only an emulated
> P2. And actually XP Mode originally "required" VT-X, but since lots of
> computers don't have it, MS "fixed" that, heh.
>

well, whatever the reason, I was not particularly impressed on this front.


in general, in contrast, VMware performance is solid, apart from the
lack of 3D HW acceleration.

>> I wasn't very impressed with what is supposed to be native-speed
>> execution lagging with an old game. granted, it could maybe be due to
>> scheduling, like native Windows limits the VirtualPC time-slice, and
>> then the contained WinXP limits Quake's time-slice.
>
> Presumably that, yes. Actually, now that I think of it, are you
> running DOSBox under XP Mode? Because I don't think Quake runs under
> WinNT-based machines (near ptr unsupported there) as opposed to
> earlier Win95. Well, maybe you meant a Windows port, not the
> "original" DJGPP commercial version.
>
> Yeah, it could be anything, I don't exactly know, could be the
> emulated video card or any number of issues.
>

I ran the DOS version of Quake:
in DOSBox (64 bit version) running directly on Windows 7 x64;
inside of a command prompt inside of XPMode.

in both cases, it ran, but performed much better in DOSBox (including in
1280x1024, which is the highest resolution I could use, and Quake didn't
support the native 1680x1050 of the monitor I was using).


general stats of the computer being used:
Athlon II X4 4400+
16GB DDR3
NVidia GTX 460
2TB of HDD space
Windows 7 x64
...

>> VMware seems to work considerably better though.
>>
>> running WinXP or Linux in VMware seems to be fairly responsive, so I
>> don't really know.
>
> They've just done a better job, I suppose. They have a good rep,
> presumably for a reason. ;-)
>

probably.

>>>> it could be either the cost of the virtualization itself, or maybe the
>>>> cost of running a virtualized Windows environment and then running Quake
>>>> in it.
>>
>>> Dunno. Maybe SDL achieves most of that speedup. I think?? I heard that
>>> SDL has some partial multi-threading nowadays, maybe for audio, can't
>>> remember. Or maybe it uses a different speedier gfx backend nowadays
>>> (DirectX?), dunno.
>>
>> I think it is still SDL.
>
> Yes, I mean perhaps SDL uses DirectX as optional backend these days,
> not sure.
>

it is possible, SDL does apparently use DirectX on Windows.

>> graphics shouldn't matter so much, since in this case they are mostly
>> just drawing into a virtual framebuffer and then displaying the contents
>> of said framebuffer using GL. this isn't really a task which itself
>> demands high-performance.
>
> Define "high", heheh. Quake is circa late 1996, targeting DOS in Intel
> Pentium territory, heavy FPU usage specifically for that machine. So a
> P60 should be fast enough, even running Win95. Even giving the typical
> 10x - 15x slowdown of emulation, we should easily be running at native
> speed. But I guess XP Mode (due to XP?) tries to do too much. Maybe
> its FPU emulation is slow, who knows, though I'd assume (hope?) they
> would just use the native cpu for things like that.
>

I can't really say for sure what was going on there.

>> although, DOSBox does have options to throttle back the simulated
>> clock-rate such that some very old DOS games don't break due to running
>> too fast, which could be making an issue here.
>
> Doubt it, though I don't know how well it "guesses" what speed to run.
> In other words, I'm not sure "core=auto" always works.
>
> For all we know, it could be your video card driver or similar. I
> don't pretend to understand all those things, but I know Intel gfx
> cards are fairly slow, comparatively, though I hear their latest Ivy
> Bridge improves that a lot. I know a lot of software seems to stumbles
> with Intel gfx for some odd reason.
>

the computer I was using doesn't use Intel graphics.

ironically, the computer in question is not presently here (it is
probably making a trip cross-country or similar), and the laptop I am
currently using does have lame graphics HW (Intel GMA).

>>>>> Supposedly with VT-X you can even run a 64-bit guest OS atop a 32-bit
>>>>> one, but I've not tried (should I ??).
>>
>>>> dunno.
>>
>>>> very likely, it will be limited to however much RAM can be used by the
>>>> host OS, which means that on a 32-bit system using much more than 256MB
>>>> or 512MB ram is not a good idea (otherwise severe swapping is likely).
>>
>>> True, but I'm just curious. At least, I know QEMU used (?) to have a
>>> software-only 64-bit emulation version, but here I mostly meant "as if
>>> native" speed. So it would be cool to know for sure I can run a 64-bit
>>> OS atop a 32-bit one. Heck, who knows, perhaps one day a 64-bit DOS
>>> (extender) will piggyback atop VT-X (but I'm not getting my hopes up).
>>
>> QEMU seems able to emulate all sorts of stuff, and I was using it to
>> emulate Linux/ARM on x86 a while back.
>>
>> its downside though is that it is not exactly high-performance IME (or,
>> at least, the QEMU versions for Windows).
>
> The old KQEMU accelerator used to help a lot, but that's long
> deprecated. VirtualBox has a recompiler, and it does help, but I'm not
> sure how well.
>

I don't think KQEMU is available on the Windows port.

>>>> I actually have a computer at the moment, which has 6GB of RAM but can
>>>> only use 3GB due to using 32-bit WinXP, but I can't install anything
>>>> else without another HDD, but I don't have one with me at the moment.
>>
>>>> grr...
>>
>>> Sorry. MS refuses to support PAE APIs there, so you're limited to
>>> about 3.1 GB, from what I've heard. It should be enough (and besides,
>>> XP inherently uses lots less RAM than Vista or 7). Vista on up let you
>>> resize the NTFS, but for XP you might have to use GParted. Probably
>>> safe, but caveat emptor.
>>
>> I was previously running XP64 on the thing, but XP64 was on a secondary
>> drive which I ended up taking out. I would need to install a secondary
>> HDD in order to have a drive on which to install XP64 again (there are
>> no suitable partitions remaining on this drive, and at the moment I am
>> not so much inclined to install over the currently-still-working WinXP
>> install).
>>
>> it is mostly a matter of needing another SATA HDD, but all I have
>> on-hand are older IDE drives.
>
> Can't you run the drive in IDE legacy mode?
>

?...

no, the problem is partly that the MOBO uses SATA, but the only drives
on-hand are older IDE drives. I can't even really hook the things up to
the MOBO (because the cabling is different, ...).

>>> Meh, I need to try BOCHS again, Darek M. claims to have done a lot of
>>> good stuff over the past few years. ;-)
>>
>> "fast enough" should work for most older software...
>>
>> even if it runs 100x slower than native, it is probably still running
>> faster than on the hardware it was originally designed for.
>
> But native 486 speed is still "slow", IMHO. :-))
>

fair enough.

>> most 16-bit software was written for 386 and 486 systems, so even if the
>> emulator is slow, who really needs to care all that much?...
>
> Depends on the app. Obviously the point is that better solutions (V86
> mode) are sometimes unavailable, which does show a huge decrease in
> performance. I guess we never thought V86 would go away nor realized
> how painful software emulation could be.
>

possibly.

it took a while for me to adapt to the effective loss of some 16-bit
apps, which are otherwise a hassle to run in something like XPMode (even
with the desktop integration and similar).

>> it is partly for these reasons I had considered the idea of trying to
>> port Quake to the BGBScript VM: yes, the VM isn't very fast, but would
>> still likely be able to run Quake faster than on the original HW.
>>
>> the much bigger issue though is the part about having to write all of
>> the stuff to compile the C front-end's ASTs to the VM's bytecode, which
>> looks like a big PITA and I haven't invested much effort into this.
>
> You'd probably almost have an easier time just emulating the raw i386
> assembly!

I actually already have an interpreter for x86 machine code (though I
haven't run anything like Quake on it).


but I had intended it more as a thing like "see, I can run actual code
in this VM".

except, a number of issues make C not ideally suited to a VM
environment, and I would almost be better off doing a language port.

but, it would be hard to justify the amount of effort required to do
something like this (and for something that basically amounts to "hey,
look, I ported Quake to some obscure ECMAScript variant...").

[Rugxulo]

Hi,

On May 22, 4:12 pm, BGB <cr88...@hotmail.com> wrote:
> On 5/22/2012 11:21 AM, Rugxulo wrote:
>
> > BTW, I've been told that a 64-bit DOSBox is even slower, but that
> > apparently didn't stop Fedora 64-bit!   :-/
>
> possibly.
> IIRC, I was using the 64-bit DOSBox for running Quake.

Did you compile it yourself? Because I don't think they ever offered a
Win64 build officially. So you were probably using the stock 32-bit
build.

> >>>> performance will depend greatly on the emulator.
> >>>> some, such as DOSBox, essentially JIT the emulated code into code
> >>>> running on the current HW.
>
> >>> I have no idea what DOSBox does, but it's very slow. Perhaps you mean
> >>> "core=auto"? That doesn't always work. It's only "fast 486" speeds, at
> >>> best. It's a great piece of software, but you can't rely on it for
> >>> anything time intensive.
>
> >> I was running Quake on it at fairly high resolutions (1280x1024 and
> >> similar) and getting considerably better performance than in XPMode.
>
> > But XP Mode explicitly isn't targeted at home users (only available
> > for businesses) because of reasons like this. Or so they claim. XP
> > Mode isn't really meant for graphics or games, which is what home
> > consumers typically use.
>
> I got it because it was available for Windows 7 Professional, which I
> got via the whole MSDNAA (MSDN Academic Alliance) thing (due to being a
> college student).

It's available on their website, I think, but "officially" not for end
users. I don't really want it. 2x requirements is too much.

> I have also observed that emulators also really seem to like emulating
> the S3 Virge (along with the RTL8139 and NE2K cards).

Yeah, must be easier to implement, I suppose.

> >> so, this is a good deal faster than any 486 I know of...
>
> > Keep in mind that Quake was heavily tuned for an Intel Pentium
> > pipelined FPU. A real 486 DX (like what DOSBox pretends to be), even a
> > so-called fast variant, wouldn't be fast enough.
>
> I ran Quake "ok" on some 486DX systems (my main computer around the time
> was a 486 DX2 66). Quake was kind of laggy, but it was generally playable.

Dunno, supposedly the Pentium was "up to 5x faster FPU" due to
pipelining and other improvements. Too bad about the FDIV bug, but
apparently that wasn't "significant" enough to affect Quake
negatively, heh.

> IIRC, my next computer (following this one) used an Intel Celeron.
> then I was annoyed as then a game game out ("Quake 3 Arena"), which
> wouldn't work on this computer (due to requiring 3D capabilities beyond
> those of the S3 card I had in the thing. Q3A all like "nope, not gonna
> work...").

I think Quake 1 was one of the first to (optionally) use minimal
hardware acceleration, even in DOS (often overlooked). I'm very old-
fashioned in that I hate the idea that a game needs a specific
graphics card. But it's a sign of the times.

> then, later, another computer using an Athlon and a GeForce2, which ran
> Q3A, UT, and HL fairly good (and by this point the Quake source was
> available, so I messed with this a fair amount).

Yes, IIRC, Quake was GPL'd in late 1999, while it was still quite
fresh, all things considered. The game itself was commercially
released (after 18 months of development) in late 1996. They had cross-
compiled on DEC Alphas via DJGPP 2.00 beta 3 libc and GCC 2.7.2.

> >> I wasn't very impressed with what is supposed to be native-speed
> >> execution lagging with an old game. granted, it could maybe be due to
> >> scheduling, like native Windows limits the VirtualPC time-slice, and
> >> then the contained WinXP limits Quake's time-slice.
>
> > Presumably that, yes. Actually, now that I think of it, are you
> > running DOSBox under XP Mode? Because I don't think Quake runs under
> > WinNT-based machines (near ptr unsupported there) as opposed to
> > earlier Win95. Well, maybe you meant a Windows port, not the
> > "original" DJGPP commercial version.
>
> > Yeah, it could be anything, I don't exactly know, could be the
> > emulated video card or any number of issues.
>
> I ran the DOS version of Quake:
> in DOSBox (64 bit version) running directly on Windows 7 x64;
> inside of a command prompt inside of XPMode.

DOSBox runs on Win7 x64 even without XP Mode, though. I assume you
knew that much, but this whole direct / indirect, emulation / sub-
emulation / native thing is confusing me. :-)

> in both cases, it ran, but performed much better in DOSBox (including in
> 1280x1024, which is the highest resolution I could use, and Quake didn't
> support the native 1680x1050 of the monitor I was using).
>
> general stats of the computer being used:
> Athlon II X4 4400+
> 16GB DDR3
> NVidia GTX 460
> 2TB of HDD space
> Windows 7 x64

I can't remember if DOSBox uses an asm x87 core or not. I think it
does, but it also has a more portable one, I think. Maybe that's why,
as Quake was heavy into FPU, or so I thought (never looked that
closely). I don't remember Doom requiring an FPU explicitly, but maybe
they emulated it (or did fixed point). For sure Doom was less
intensive since it wasn't really 3d (commonly called "2.5d", right?
heh) with raster sprite graphics (or whatever).

But yes, obviously your hardware was more than sufficient for running
Quake at native speed, even emulated (or so I'd think!).

> >> although, DOSBox does have options to throttle back the simulated
> >> clock-rate such that some very old DOS games don't break due to running
> >> too fast, which could be making an issue here.
>
> > Doubt it, though I don't know how well it "guesses" what speed to run.
> > In other words, I'm not sure "core=auto" always works.
>
> > For all we know, it could be your video card driver or similar. I
> > don't pretend to understand all those things, but I know Intel gfx
> > cards are fairly slow, comparatively, though I hear their latest Ivy
> > Bridge improves that a lot. I know a lot of software seems to stumbles
> > with Intel gfx for some odd reason.
>
> the computer I was using doesn't use Intel graphics.
>
> ironically, the computer in question is not presently here (it is
> probably making a trip cross-country or similar), and the laptop I am
> currently using does have lame graphics HW (Intel GMA).

Actually, I think Quake used VESA (2.0?), so maybe that is really slow
under VPC because few OSes use it directly anymore. Unlike DOSBox
where it is more of a priority.

> > The old KQEMU accelerator used to help a lot, but that's long
> > deprecated. VirtualBox has a recompiler, and it does help, but I'm not
> > sure how well.
>
> I don't think KQEMU is available on the Windows port.

It used to be, and I used it successfully, but that's long been
deprecated and removed. A lot has happened since the old 0.9.0 days.

> >>> Meh, I need to try BOCHS again, Darek M. claims to have done a lot of
> >>> good stuff over the past few years.   ;-)
>
> >> "fast enough" should work for most older software...
>
> >> even if it runs 100x slower than native, it is probably still running
> >> faster than on the hardware it was originally designed for.
>
> > But native 486 speed is still "slow", IMHO.    :-))
>
> fair enough.

Anything beyond GCC 2.7.x is too slow for running on a 486 host, IMO.
Even that was moderately painful (e.g. rebuilding Allegro). A lot of
software wasn't ever designed for speed, or esp. not for 486s. It
really was a different era back then. (We're more or less the same
age, I think, so I'm not pretending to have insider knowledge or
anything, just saying, heh, 486 is too slow.)

> >> it is partly for these reasons I had considered the idea of trying to
> >> port Quake to the BGBScript VM: yes, the VM isn't very fast, but would
> >> still likely be able to run Quake faster than on the original HW.
>
> >> the much bigger issue though is the part about having to write all of
> >> the stuff to compile the C front-end's ASTs to the VM's bytecode, which
> >> looks like a big PITA and I haven't invested much effort into this.
>
> > You'd probably almost have an easier time just emulating the raw i386
> > assembly!
>
> I actually already have an interpreter for x86 machine code (though I
> haven't run anything like Quake on it).
>
> but I had intended it more as a thing like "see, I can run actual code
> in this VM".
>
> except, a number of issues make C not ideally suited to a VM
> environment, and I would almost be better off doing a language port.
>
> but, it would be hard to justify the amount of effort required to do
> something like this (and for something that basically amounts to "hey,
> look, I ported Quake to some obscure ECMAScript variant...").

Google ported Quake to their Native Client (NaCl). I know that
probably doesn't help you specifically, but it can be done. :-)

Actually, one other guy ported DOSBox to Java (jDOSBox), and now you
can automatically download and run Doom within your browser via
plugin.

EDIT: Hmmm, seems someone has ported Doom, Quake, and DOSBox all to
NaCl also. Weird world. (And that's ignoring jsdosbox and jslinux!)

[BGB]

On 5/23/2012 10:23 AM, Rugxulo wrote:
> Hi,
>
> On May 22, 4:12 pm, BGB<cr88...@hotmail.com> wrote:
>> On 5/22/2012 11:21 AM, Rugxulo wrote:
>>
>>> BTW, I've been told that a 64-bit DOSBox is even slower, but that
>>> apparently didn't stop Fedora 64-bit! :-/
>>
>> possibly.
>> IIRC, I was using the 64-bit DOSBox for running Quake.
>
> Did you compile it yourself? Because I don't think they ever offered a
> Win64 build officially. So you were probably using the stock 32-bit
> build.
>

I IIRC there was an x64 build available (possibly a non-official build,
I forget).

>>>>>> performance will depend greatly on the emulator.
>>>>>> some, such as DOSBox, essentially JIT the emulated code into code
>>>>>> running on the current HW.
>>
>>>>> I have no idea what DOSBox does, but it's very slow. Perhaps you mean
>>>>> "core=auto"? That doesn't always work. It's only "fast 486" speeds, at
>>>>> best. It's a great piece of software, but you can't rely on it for
>>>>> anything time intensive.
>>
>>>> I was running Quake on it at fairly high resolutions (1280x1024 and
>>>> similar) and getting considerably better performance than in XPMode.
>>
>>> But XP Mode explicitly isn't targeted at home users (only available
>>> for businesses) because of reasons like this. Or so they claim. XP
>>> Mode isn't really meant for graphics or games, which is what home
>>> consumers typically use.
>>
>> I got it because it was available for Windows 7 Professional, which I
>> got via the whole MSDNAA (MSDN Academic Alliance) thing (due to being a
>> college student).
>
> It's available on their website, I think, but "officially" not for end
> users. I don't really want it. 2x requirements is too much.
>

I got it, and later concluded that it "wasn't very good".

>> I have also observed that emulators also really seem to like emulating
>> the S3 Virge (along with the RTL8139 and NE2K cards).
>
> Yeah, must be easier to implement, I suppose.
>

maybe, or they just implement whatever technology was fairly popular and
thus has good general driver support.


I don't remember the specifics of the S3 Virge (been a long time since I
was in OS land). I don't remember it being particular complex (vs normal
VGA, for which I remember the "register dance" being a bit confusing).

IIRC, the RTL8139 was basically just 2 memory-mapped ring buffers (using
wraparound), one for transmit and the other for receive. on recieve, it
would write the packet into the buffer, advance an offset, and generate
an IRQ. the interrupt handler would read the packet, and advance another
offset.

transmitting was basically similar, as it consisted of writing the
packet into the buffer, and advancing the offset (the card would then
send the packet, update the offset, and maybe generate another IRQ).

the packets were basically raw Ethernet frames, and IIRC ports could be
used to retrieve the card's built-in MAC address.

>>>> so, this is a good deal faster than any 486 I know of...
>>
>>> Keep in mind that Quake was heavily tuned for an Intel Pentium
>>> pipelined FPU. A real 486 DX (like what DOSBox pretends to be), even a
>>> so-called fast variant, wouldn't be fast enough.
>>
>> I ran Quake "ok" on some 486DX systems (my main computer around the time
>> was a 486 DX2 66). Quake was kind of laggy, but it was generally playable.
>
> Dunno, supposedly the Pentium was "up to 5x faster FPU" due to
> pipelining and other improvements. Too bad about the FDIV bug, but
> apparently that wasn't "significant" enough to affect Quake
> negatively, heh.
>

"5x faster FPU" sounds like a bit of a stretch.

Quake was kind of laggy on a 486 DX2 66, but not that much drastically
worse than a Pentium 90 (besides what could be reasonably expected due
to clock-rate, ...).

>> IIRC, my next computer (following this one) used an Intel Celeron.
>> then I was annoyed as then a game game out ("Quake 3 Arena"), which
>> wouldn't work on this computer (due to requiring 3D capabilities beyond
>> those of the S3 card I had in the thing. Q3A all like "nope, not gonna
>> work...").
>
> I think Quake 1 was one of the first to (optionally) use minimal
> hardware acceleration, even in DOS (often overlooked). I'm very old-
> fashioned in that I hate the idea that a game needs a specific
> graphics card. But it's a sign of the times.
>

AFAIK, only the Windows versions could use HW acceleration.
(the DOS version could use VESA/VBE, but I don't think this counts).

both Quake 1 and 2 could use either SW rendering or OpenGL (or GLide),
where in Quake 1, it involved using a different EXE, and in Quake 2 it
could be chosen via a menu.

Quake 3 was OpenGL only.

>> then, later, another computer using an Athlon and a GeForce2, which ran
>> Q3A, UT, and HL fairly good (and by this point the Quake source was
>> available, so I messed with this a fair amount).
>
> Yes, IIRC, Quake was GPL'd in late 1999, while it was still quite
> fresh, all things considered. The game itself was commercially
> released (after 18 months of development) in late 1996. They had cross-
> compiled on DEC Alphas via DJGPP 2.00 beta 3 libc and GCC 2.7.2.
>

yes, some time around then.
at this time, messing with the new-found powers of OpenGL (vs SW
rendering), I ended up fairly quickly making a switch to using primarily
OpenGL.

although, I think there was a brief intermediate stage, where I was
using either OpenGL, or using vaguely similar commands to drive a SW
renderer (emit polygons, it gets passed to "driver", which would then
pass it either to GL or use a polygon-drawing function).

this mechanism died off and faded away though.

>>>> I wasn't very impressed with what is supposed to be native-speed
>>>> execution lagging with an old game. granted, it could maybe be due to
>>>> scheduling, like native Windows limits the VirtualPC time-slice, and
>>>> then the contained WinXP limits Quake's time-slice.
>>
>>> Presumably that, yes. Actually, now that I think of it, are you
>>> running DOSBox under XP Mode? Because I don't think Quake runs under
>>> WinNT-based machines (near ptr unsupported there) as opposed to
>>> earlier Win95. Well, maybe you meant a Windows port, not the
>>> "original" DJGPP commercial version.
>>
>>> Yeah, it could be anything, I don't exactly know, could be the
>>> emulated video card or any number of issues.
>>
>> I ran the DOS version of Quake:
>> in DOSBox (64 bit version) running directly on Windows 7 x64;
>> inside of a command prompt inside of XPMode.
>
> DOSBox runs on Win7 x64 even without XP Mode, though. I assume you
> knew that much, but this whole direct / indirect, emulation / sub-
> emulation / native thing is confusing me. :-)
>

no, these were the 2 ways I was running Quake.

Form A: in DOSBox (64 bit version) running directly on Windows 7 x64.

Form B: inside of a command prompt inside of XPMode.

note that ';' is not ','.


I was not running DOSBox in XPMode, as this would defeat the point.

>> in both cases, it ran, but performed much better in DOSBox (including in
>> 1280x1024, which is the highest resolution I could use, and Quake didn't
>> support the native 1680x1050 of the monitor I was using).
>>
>> general stats of the computer being used:
>> Athlon II X4 4400+
>> 16GB DDR3
>> NVidia GTX 460
>> 2TB of HDD space
>> Windows 7 x64
>
> I can't remember if DOSBox uses an asm x87 core or not. I think it
> does, but it also has a more portable one, I think. Maybe that's why,
> as Quake was heavy into FPU, or so I thought (never looked that
> closely). I don't remember Doom requiring an FPU explicitly, but maybe
> they emulated it (or did fixed point). For sure Doom was less
> intensive since it wasn't really 3d (commonly called "2.5d", right?
> heh) with raster sprite graphics (or whatever).
>

Doom used a mix of fixed-point and integer math.

most of the world was 16-bit integer math, with some amount of
fixed-point math used internally.

actually, Quake also used a lot of 12.4 fixed-point math, which is part
of why Quake was limited to a world size of a 4096-unit cube (+-2048).

Quake 2 went to 13.3 instead, so the world size was an 8192 unit cube
(+-4096).

where each unit was 1.5 inches.
this didn't exactly lead to large world sizes...

> But yes, obviously your hardware was more than sufficient for running
> Quake at native speed, even emulated (or so I'd think!).
>

yep.

>>>> although, DOSBox does have options to throttle back the simulated
>>>> clock-rate such that some very old DOS games don't break due to running
>>>> too fast, which could be making an issue here.
>>
>>> Doubt it, though I don't know how well it "guesses" what speed to run.
>>> In other words, I'm not sure "core=auto" always works.
>>
>>> For all we know, it could be your video card driver or similar. I
>>> don't pretend to understand all those things, but I know Intel gfx
>>> cards are fairly slow, comparatively, though I hear their latest Ivy
>>> Bridge improves that a lot. I know a lot of software seems to stumbles
>>> with Intel gfx for some odd reason.
>>
>> the computer I was using doesn't use Intel graphics.
>>
>> ironically, the computer in question is not presently here (it is
>> probably making a trip cross-country or similar), and the laptop I am
>> currently using does have lame graphics HW (Intel GMA).
>
> Actually, I think Quake used VESA (2.0?), so maybe that is really slow
> under VPC because few OSes use it directly anymore. Unlike DOSBox
> where it is more of a priority.
>

possibly.

VirtualPC taking a performance hit from VESA calls is a possibility I guess.

>>> The old KQEMU accelerator used to help a lot, but that's long
>>> deprecated. VirtualBox has a recompiler, and it does help, but I'm not
>>> sure how well.
>>
>> I don't think KQEMU is available on the Windows port.
>
> It used to be, and I used it successfully, but that's long been
> deprecated and removed. A lot has happened since the old 0.9.0 days.
>

ok.

>>>>> Meh, I need to try BOCHS again, Darek M. claims to have done a lot of
>>>>> good stuff over the past few years. ;-)
>>
>>>> "fast enough" should work for most older software...
>>
>>>> even if it runs 100x slower than native, it is probably still running
>>>> faster than on the hardware it was originally designed for.
>>
>>> But native 486 speed is still "slow", IMHO. :-))
>>
>> fair enough.
>
> Anything beyond GCC 2.7.x is too slow for running on a 486 host, IMO.
> Even that was moderately painful (e.g. rebuilding Allegro). A lot of
> software wasn't ever designed for speed, or esp. not for 486s. It
> really was a different era back then. (We're more or less the same
> age, I think, so I'm not pretending to have insider knowledge or
> anything, just saying, heh, 486 is too slow.)
>

possibly. I was born back in the early 80s, FWIW.
spent pretty much my whole life fiddling around with computers and
writing software.

personally, I find trying to build large C++ codebases too slow for
modern HW, having a while back had the experience of waiting something
like 30 minutes or so for Doom 3 to recompile from source.

my motivation to mess with it is hindered by its slow recompile times.

at least C compiles a good deal faster.

>>>> it is partly for these reasons I had considered the idea of trying to
>>>> port Quake to the BGBScript VM: yes, the VM isn't very fast, but would
>>>> still likely be able to run Quake faster than on the original HW.
>>
>>>> the much bigger issue though is the part about having to write all of
>>>> the stuff to compile the C front-end's ASTs to the VM's bytecode, which
>>>> looks like a big PITA and I haven't invested much effort into this.
>>
>>> You'd probably almost have an easier time just emulating the raw i386
>>> assembly!
>>
>> I actually already have an interpreter for x86 machine code (though I
>> haven't run anything like Quake on it).
>>
>> but I had intended it more as a thing like "see, I can run actual code
>> in this VM".
>>
>> except, a number of issues make C not ideally suited to a VM
>> environment, and I would almost be better off doing a language port.
>>
>> but, it would be hard to justify the amount of effort required to do
>> something like this (and for something that basically amounts to "hey,
>> look, I ported Quake to some obscure ECMAScript variant...").
>
> Google ported Quake to their Native Client (NaCl). I know that
> probably doesn't help you specifically, but it can be done. :-)
>

except NaCl runs C and C++ code on a modified x86 ISA, so this isn't
really anything major.

> Actually, one other guy ported DOSBox to Java (jDOSBox), and now you
> can automatically download and run Doom within your browser via
> plugin.
>
> EDIT: Hmmm, seems someone has ported Doom, Quake, and DOSBox all to
> NaCl also. Weird world. (And that's ignoring jsdosbox and jslinux!)

(IIRC, there is a JS port of Quake3 as well...).
nevermind that someone else (at Adobe) had ported Quake over to Flash.
...


I didn't mean running Quake within a DOS emulator or similar, but rather
directly porting the source-code to run directly on the Script VM.

I could probably do it, it is just harder to justify investing the time
and effort to do so.

the VM should be fast enough to manage it effectively (assuming I don't
stumble on any major bugs or memory leaks, which is also possible).


the main things it involves is either:
investing the time and effort needed to write the logic to compile C
code to the BGBScript VM (still has a number of non-trivial issues I
would have to work through);
invest a good deal of effort into essentially rewriting Quake into
BGBScript (could be done, but would be a huge PITA).


that or I try porting something probably simpler, like Doom or Wolf3D...

[Rod Pemberton]

"BGB" <cr8...@hotmail.com> wrote in message
news:jpllgs$hqp$1...@news.albasani.net...

> [...]

> Doom used a mix of fixed-point and integer math.
>
> most of the world was 16-bit integer math, with some amount
> of fixed-point math used internally.
>
> actually, Quake also used a lot of 12.4 fixed-point math, which
> is part of why Quake was limited to a world size of a 4096-unit
> cube (+-2048).
>
> Quake 2 went to 13.3 instead, so the world size was an 8192
> unit cube (+-4096).
>
> where each unit was 1.5 inches.
> this didn't exactly lead to large world sizes...

Well, with 32-bit integers at 1 in/unit, that'd be just over 1 sq-mi.
That's decently sized. It would allow very precise shots at long distances.
Etc.


Rod Pemberton

[BGB]

well, yes, except that Quake and Quake 2 were using 16 bit shorts in
these cases (thus why there was such a severe world-size limit).

512ft is not a very large distance.


some of my own variants of the engines had extended this to 32-bits.

in the case of the Quake 2, in a partially backwards-compatible way,
IIRC something like a flag that said "yeah, hey, the origin for this
entity uses 32-bit coords".

my own engine has no particular world-size limits, apart from those due
to floating-point accuracy limitations (presently this is more like
999999 units, as much past this and floats start having issues).

[Rugxulo]

Hi,

On May 24, 10:52 am, BGB <cr88...@hotmail.com> wrote:
> On 5/23/2012 10:23 AM, Rugxulo wrote:
>
> > On May 22, 4:12 pm, BGB<cr88...@hotmail.com>  wrote:
> >> On 5/22/2012 11:21 AM, Rugxulo wrote:
>
> >>> BTW, I've been told that a 64-bit DOSBox is even slower, but that
> >>> apparently didn't stop Fedora 64-bit!   :-/
>
> >> possibly.
> >> IIRC, I was using the 64-bit DOSBox for running Quake.
>
> > Did you compile it yourself? Because I don't think they ever offered a
> > Win64 build officially. So you were probably using the stock 32-bit
> > build.
>
> I IIRC there was an x64 build available (possibly a non-official build,
> I forget).

That may have been the source of your slowdown, ironically.

> >> IIRC, my next computer (following this one) used an Intel Celeron.
> >> then I was annoyed as then a game game out ("Quake 3 Arena"), which
> >> wouldn't work on this computer (due to requiring 3D capabilities beyond
> >> those of the S3 card I had in the thing. Q3A all like "nope, not gonna
> >> work...").
>
> > I think Quake 1 was one of the first to (optionally) use minimal
> > hardware acceleration, even in DOS (often overlooked). I'm very old-
> > fashioned in that I hate the idea that a game needs a specific
> > graphics card. But it's a sign of the times.
>
> AFAIK, only the Windows versions could use HW acceleration.
> (the DOS version could use VESA/VBE, but I don't think this counts).
>
> both Quake 1 and 2 could use either SW rendering or OpenGL (or GLide),
> where in Quake 1, it involved using a different EXE, and in Quake 2 it
> could be chosen via a menu.
>
> Quake 3 was OpenGL only.

I'm pretty positive (though never tried) that even the DOS one had
some minimal hardware gfx acceleration but only with certain cards and
driver shims. I don't know the details, and I'm not sure if that means
VBE/AF or not (doubt it). But yes it definitely used VESA, and no
that's not considered accelerated.

> >> I ran the DOS version of Quake:
> >> in DOSBox (64 bit version) running directly on Windows 7 x64;
> >> inside of a command prompt inside of XPMode.
>
> > DOSBox runs on Win7 x64 even without XP Mode, though. I assume you
> > knew that much, but this whole direct / indirect, emulation / sub-
> > emulation / native thing is confusing me.   :-)
>
> no, these were the 2 ways I was running Quake.
>
> Form A: in DOSBox (64 bit version) running directly on Windows 7 x64.
>
> Form B: inside of a command prompt inside of XPMode.

That can't be right, can it? I'm pretty sure that the DOS version
never ran on NT-based Windows due to nearptrs.

> note that ';' is not ','.
>
> I was not running DOSBox in XPMode, as this would defeat the point.

Yes, that wouldn't be very speedy, but XP doesn't run 100% of DOS
stuff, esp. gfx-based. XP isn't a real DOS-based OS, hence its DOS
support is slightly wonky at best (esp. since it wasn't a priority for
them).

> > Actually, I think Quake used VESA (2.0?), so maybe that is really slow
> > under VPC because few OSes use it directly anymore. Unlike DOSBox
> > where it is more of a priority.
>
> possibly.
>
> VirtualPC taking a performance hit from VESA calls is a possibility I guess.

I actually get much much better framerate in Hexen2 (DOS port) under
DOSEMU than natively in DOS. So take from that what you will.

> > Anything beyond GCC 2.7.x is too slow for running on a 486 host, IMO.
> > Even that was moderately painful (e.g. rebuilding Allegro). A lot of
> > software wasn't ever designed for speed, or esp. not for 486s. It
> > really was a different era back then. (We're more or less the same
> > age, I think, so I'm not pretending to have insider knowledge or
> > anything, just saying, heh, 486 is too slow.)
>
> possibly. I was born back in the early 80s, FWIW.
> spent pretty much my whole life fiddling around with computers and
> writing software.

I was born in 1979. But my experience is heavily dwarfed by yours. I
play around, but I'm more of a power user (if even) than a skilled
programmer.

> personally, I find trying to build large C++ codebases too slow for
> modern HW, having a while back had the experience of waiting something
> like 30 minutes or so for Doom 3 to recompile from source.

30 mins. isn't actually that bad, but yeah, could be better. Is that
the whole thing from scratch or just part? Makefiles are supposed to
help, but they are often such an ugly kludge.

> my motivation to mess with it is hindered by its slow recompile times.

I agree, slow compiles are a drag.

> at least C compiles a good deal faster.

At least there are several C++ compilers to choose from. The fastest
is (allegedly) Digital Mars. And presumably Linux G++ is faster than
Windows due to faster subprocess execution (or whatever).

But yeah, I've seen you briefly mention modules, reparsing headers,
precompiled, etc. Yes, that makes a difference too, apparently.

> > Google ported Quake to their Native Client (NaCl). I know that
> > probably doesn't help you specifically, but it can be done.   :-)
>
> except NaCl runs C and C++ code on a modified x86 ISA, so this isn't
> really anything major.

If you say so. :-)

> I didn't mean running Quake within a DOS emulator or similar, but rather
> directly porting the source-code to run directly on the Script VM.
>
> I could probably do it, it is just harder to justify investing the time
> and effort to do so.

Agreed, all the good ideas take forever to implement. :-/

> the VM should be fast enough to manage it effectively (assuming I don't
> stumble on any major bugs or memory leaks, which is also possible).
>
> the main things it involves is either:
> investing the time and effort needed to write the logic to compile C
> code to the BGBScript VM (still has a number of non-trivial issues I
> would have to work through);
> invest a good deal of effort into essentially rewriting Quake into
> BGBScript (could be done, but would be a huge PITA).
>
> that or I try porting something probably simpler, like Doom or Wolf3D...

Yeah, something simpler is probably a good idea. Though I don't know
which would be easier. Naively, I'd almost think Wolf3d due to real
mode only, but maybe all the segment fiddling would end up harder, who
knows. The problem is that you're going to be struggling with memory
models, video gfx, audio, OS calls, etc. It's hard to mix all of that.
Perhaps Wolf4SDL would be easier, who knows.

[BGB]

On 5/26/2012 4:14 PM, Rugxulo wrote:
> Hi,
>
> On May 24, 10:52 am, BGB<cr88...@hotmail.com> wrote:
>> On 5/23/2012 10:23 AM, Rugxulo wrote:
>>
>>> On May 22, 4:12 pm, BGB<cr88...@hotmail.com> wrote:
>>>> On 5/22/2012 11:21 AM, Rugxulo wrote:
>>
>>>>> BTW, I've been told that a 64-bit DOSBox is even slower, but that
>>>>> apparently didn't stop Fedora 64-bit! :-/
>>
>>>> possibly.
>>>> IIRC, I was using the 64-bit DOSBox for running Quake.
>>
>>> Did you compile it yourself? Because I don't think they ever offered a
>>> Win64 build officially. So you were probably using the stock 32-bit
>>> build.
>>
>> I IIRC there was an x64 build available (possibly a non-official build,
>> I forget).
>
> That may have been the source of your slowdown, ironically.
>

well, except it was XPMode which was being slow, not DOSBox.

>>>> IIRC, my next computer (following this one) used an Intel Celeron.
>>>> then I was annoyed as then a game game out ("Quake 3 Arena"), which
>>>> wouldn't work on this computer (due to requiring 3D capabilities beyond
>>>> those of the S3 card I had in the thing. Q3A all like "nope, not gonna
>>>> work...").
>>
>>> I think Quake 1 was one of the first to (optionally) use minimal
>>> hardware acceleration, even in DOS (often overlooked). I'm very old-
>>> fashioned in that I hate the idea that a game needs a specific
>>> graphics card. But it's a sign of the times.
>>
>> AFAIK, only the Windows versions could use HW acceleration.
>> (the DOS version could use VESA/VBE, but I don't think this counts).
>>
>> both Quake 1 and 2 could use either SW rendering or OpenGL (or GLide),
>> where in Quake 1, it involved using a different EXE, and in Quake 2 it
>> could be chosen via a menu.
>>
>> Quake 3 was OpenGL only.
>
> I'm pretty positive (though never tried) that even the DOS one had
> some minimal hardware gfx acceleration but only with certain cards and
> driver shims. I don't know the details, and I'm not sure if that means
> VBE/AF or not (doubt it). But yes it definitely used VESA, and no
> that's not considered accelerated.
>

would have to dig around in the source, but I am not aware of any
particular HW acceleration for the DOS version.

there was, however, the Windows versions (GLQuake and WinQuake).

unless by some off chance someone had a DOS port of OpenGL, and there
was a port of GLQuake for this, but I hadn't heard of anything like this.

>>>> I ran the DOS version of Quake:
>>>> in DOSBox (64 bit version) running directly on Windows 7 x64;
>>>> inside of a command prompt inside of XPMode.
>>
>>> DOSBox runs on Win7 x64 even without XP Mode, though. I assume you
>>> knew that much, but this whole direct / indirect, emulation / sub-
>>> emulation / native thing is confusing me. :-)
>>
>> no, these were the 2 ways I was running Quake.
>>
>> Form A: in DOSBox (64 bit version) running directly on Windows 7 x64.
>>
>> Form B: inside of a command prompt inside of XPMode.
>
> That can't be right, can it? I'm pretty sure that the DOS version
> never ran on NT-based Windows due to nearptrs.
>

AFAIK, it worked up until Vista and Windows 7.

I was also remembering using the DOS version of Quake a fair amount on
Win2K as well (though I typically used Windows builds a lot more later
on, typically GLQuake).

>> note that ';' is not ','.
>>
>> I was not running DOSBox in XPMode, as this would defeat the point.
>
> Yes, that wouldn't be very speedy, but XP doesn't run 100% of DOS
> stuff, esp. gfx-based. XP isn't a real DOS-based OS, hence its DOS
> support is slightly wonky at best (esp. since it wasn't a priority for
> them).
>

yes, but Quake does work last I tested, at least on 32-bit Windows.

or, at least, it did in the past...
trying to fire up the DOS version on a 32-bit WinXP seems to have it
crashing with a GPF.

hmm, it is a mystery...


well, at least GLQuake still works, sort-of, apart from being kind of
dark and gameplay going really fast (a bug I have also seen recently
with Minecraft on this computer, where MC seems to randomly get faster
and slower).

then again, the computer had been powered off for a fairly long time (~
1 year, and unplugged about 6 months of this), and when I had powered it
back on (since my other computer isn't presently available) its clock
had drifted by a fairly large amount (several months).

the Windows clock still seems to be working pretty much correctly
though, so I am not entirely sure what is going on here.

>>> Actually, I think Quake used VESA (2.0?), so maybe that is really slow
>>> under VPC because few OSes use it directly anymore. Unlike DOSBox
>>> where it is more of a priority.
>>
>> possibly.
>>
>> VirtualPC taking a performance hit from VESA calls is a possibility I guess.
>
> I actually get much much better framerate in Hexen2 (DOS port) under
> DOSEMU than natively in DOS. So take from that what you will.
>

possibly, dunno...

>>> Anything beyond GCC 2.7.x is too slow for running on a 486 host, IMO.
>>> Even that was moderately painful (e.g. rebuilding Allegro). A lot of
>>> software wasn't ever designed for speed, or esp. not for 486s. It
>>> really was a different era back then. (We're more or less the same
>>> age, I think, so I'm not pretending to have insider knowledge or
>>> anything, just saying, heh, 486 is too slow.)
>>
>> possibly. I was born back in the early 80s, FWIW.
>> spent pretty much my whole life fiddling around with computers and
>> writing software.
>
> I was born in 1979. But my experience is heavily dwarfed by yours. I
> play around, but I'm more of a power user (if even) than a skilled
> programmer.
>

fair enough.

>> personally, I find trying to build large C++ codebases too slow for
>> modern HW, having a while back had the experience of waiting something
>> like 30 minutes or so for Doom 3 to recompile from source.
>
> 30 mins. isn't actually that bad, but yeah, could be better. Is that
> the whole thing from scratch or just part? Makefiles are supposed to
> help, but they are often such an ugly kludge.
>

Doom 3 came set up as a Visual Studio project, and VS seems to rebuild
the whole damn thing every time (setting it up for a debug build makes
it go a little faster, but it is still slow).


my similarly sized C project manages to recompile (even doing a clean
rebuild) considerably faster.

>> my motivation to mess with it is hindered by its slow recompile times.
>
> I agree, slow compiles are a drag.
>

I think the main thing I did was to comment out some copy-protection
stuff, mostly as it was being annoying (me like "I am rebuilding the
thing from source, I don't need to endlessly re-enter the CD-key", like
it seemed to forget the CD-key each time the engine was rebuilt or
something).

tracing through the code, it turned out the copy-protection was
controlled by a #define, and it was either comment or uncomment (I
forget which) to turn it off.

>> at least C compiles a good deal faster.
>
> At least there are several C++ compilers to choose from. The fastest
> is (allegedly) Digital Mars. And presumably Linux G++ is faster than
> Windows due to faster subprocess execution (or whatever).
>

GCC and G++ on Windows are "pretty damn slow...".

MSVC is much faster than GCC on Windows WRT compile times.

> But yeah, I've seen you briefly mention modules, reparsing headers,
> precompiled, etc. Yes, that makes a difference too, apparently.
>

well, yes, but as-is these would only effect my own tools, whereas I am
mostly building using generic compilers (MSVC and GCC).

the fancy stuff is mostly related to my own tools, which code run in a
VM environment, and currently typically compile code on-demand.

>>> Google ported Quake to their Native Client (NaCl). I know that
>>> probably doesn't help you specifically, but it can be done. :-)
>>
>> except NaCl runs C and C++ code on a modified x86 ISA, so this isn't
>> really anything major.
>
> If you say so. :-)
>

that was sort of the point of NaCl, it is a "native" client because its
ISA is x86-based, and so can be run directly on the host CPU.

what NaCl did was mostly to run a lot of proofs and similar over the
machine-code, mostly to prove that it can't break out of its sandbox.

>> I didn't mean running Quake within a DOS emulator or similar, but rather
>> directly porting the source-code to run directly on the Script VM.
>>
>> I could probably do it, it is just harder to justify investing the time
>> and effort to do so.
>
> Agreed, all the good ideas take forever to implement. :-/
>

yeah.

>> the VM should be fast enough to manage it effectively (assuming I don't
>> stumble on any major bugs or memory leaks, which is also possible).
>>
>> the main things it involves is either:
>> investing the time and effort needed to write the logic to compile C
>> code to the BGBScript VM (still has a number of non-trivial issues I
>> would have to work through);
>> invest a good deal of effort into essentially rewriting Quake into
>> BGBScript (could be done, but would be a huge PITA).
>>
>> that or I try porting something probably simpler, like Doom or Wolf3D...
>
> Yeah, something simpler is probably a good idea. Though I don't know
> which would be easier. Naively, I'd almost think Wolf3d due to real
> mode only, but maybe all the segment fiddling would end up harder, who
> knows. The problem is that you're going to be struggling with memory
> models, video gfx, audio, OS calls, etc. It's hard to mix all of that.
> Perhaps Wolf4SDL would be easier, who knows.

actually, it would not be running in real-mode, and actually it wouldn't
even be directly running on the x86 ISA either (rather, it would be
running on a high-level bytecode).

probably nearly anything related to memory management would need to be
rewritten.

technically, the BGBScript VM has a lot more in common with the JVM than
it does with x86, although it isn't nearly as restrictive as the JVM.


technically, porting C code to BGBScript shouldn't be itself
particularly difficult, apart from maybe due to the hassles of having to
rewrite a big pile of code from one language into another, where the
languages don't have exactly the same syntax or features (though C and
BS still are "kind of similar" in many ways, they are still "not exactly
the same thing" in many areas, and there is not always a 1:1 mapping
between language features, and how they work internally is considerably
different).

the main thing about Doom or Wolf3D is that they have less code, and
probably less code to rewrite. the worry is that there may not
necessarily be less things that are difficult to port between languages.



although, I did recently go and mess with the Flash port of Quake, and
yes, it was Quake (more or less).

oddly enough, it said it would work on Flash Player or Adobe AIR. I had
both installed, and it didn't work (Firefox had no idea apparently what
to do with an SWF file, just kept popping up a thing to save it to
disk). went and installed "Adobe Shockwave", and then it worked...

maybe I will read some about SWF, maybe something will be interesting.


note that my VM can currently package things together using a loosely
WAD-based container format (it is called "ExWAD", and is technically an
extended form of the WAD2 format with a slightly different header).
(extensions: Deflate compression, paths, ability to escape-encode names
longer than 16 chars, ...).

or such...