IDEA: DemoVM
category: general [glöplog]
I really loved the oldskool demos back in the pre-1995s. However they were "real" DOS demos were programmed in assembly/C and used EMS/XMS, etc.
I've tried running some demos under DOSBox and they worked. However they ran really slow, more like slide-shows. This is because DOSBox is emulating the hardware for a 486 and soundcards.
Am thinking whether it be possible to create/develop a Virtual Machine specifically to running old-skool PC demos. A virtual machine that can interpret the assembly/low-level-C-code and do some on-the-fly/just-in-time translation for "todays" PCs running under WinXP, etc.
PS: PC demos as in the scene.org demos (
ftp://hornet.madtracker.org/mirrors/hornet/demos/1995/s/solstice.zip
and it's patch update
ftp://hornet.madtracker.org/mirrors/hornet/demos/1996/s/solfix.zip
)
I've tried running some demos under DOSBox and they worked. However they ran really slow, more like slide-shows. This is because DOSBox is emulating the hardware for a 486 and soundcards.
Am thinking whether it be possible to create/develop a Virtual Machine specifically to running old-skool PC demos. A virtual machine that can interpret the assembly/low-level-C-code and do some on-the-fly/just-in-time translation for "todays" PCs running under WinXP, etc.
PS: PC demos as in the scene.org demos (
ftp://hornet.madtracker.org/mirrors/hornet/demos/1995/s/solstice.zip
and it's patch update
ftp://hornet.madtracker.org/mirrors/hornet/demos/1996/s/solfix.zip
)
Maybe tweaking Qemu might help not to start from scratch completely?
Anyways, getting yourself a Pentium with GUS and ET6000 on Ebay or from some friend would be quicker and less pointless.
Anyways, getting yourself a Pentium with GUS and ET6000 on Ebay or from some friend would be quicker and less pointless.
I would agree for a OpenSource project like this, which can be compiled on a Mac platform. Since not all Demos run on VPC!
2 things: 2 sceners got GUS cards from sceners not using them at Breakpoint. (Which RULED, thanks a million, can't wait to USE it.)
part 2:
I believe the TBL things like jizz and so on run in a virtual machine. At least if you go to the libsdl part, you can find the bit that allows it to run on modern OS's (like FreeBSD, which I ran them on a few years ago.)
Obviosuly that only works for TBL but.
part 2:
I believe the TBL things like jizz and so on run in a virtual machine. At least if you go to the libsdl part, you can find the bit that allows it to run on modern OS's (like FreeBSD, which I ran them on a few years ago.)
Obviosuly that only works for TBL but.
Kevingpo, the speed is due to an interpreter for x86 emulation - which so far has been a good thing, since some people want to watch stuff on an Apple or some other weird piece of high-preformance metal.
Obviously, the DOSBox crew is wishing to improve the emulation speed, to be able to run more recent stuff. However, as i proposed to replace the interreter by a sort-of x86-specific partial recompiler - which would be quite simple, mostly needing to patch away incompatible instructions and adjust jump targets to fit - they objected on the grounds that they wanted to stay compatible to all major executing CPUs.
They had pointed my nose onto QEMU and said: "this is our future". So, have patience, or help them embedding QEMU, which would obviously provide for a performance orders of magnitude better.
Of course, by my arrogance and lack of time, I rather advocate the way that has been taken all along: get a faster computer, you can use the extra performance anyway.
Obviously, the DOSBox crew is wishing to improve the emulation speed, to be able to run more recent stuff. However, as i proposed to replace the interreter by a sort-of x86-specific partial recompiler - which would be quite simple, mostly needing to patch away incompatible instructions and adjust jump targets to fit - they objected on the grounds that they wanted to stay compatible to all major executing CPUs.
They had pointed my nose onto QEMU and said: "this is our future". So, have patience, or help them embedding QEMU, which would obviously provide for a performance orders of magnitude better.
Of course, by my arrogance and lack of time, I rather advocate the way that has been taken all along: get a faster computer, you can use the extra performance anyway.
