descenterace on 9/9/2005 at 22:23
<return-of-the-mad-programmer>
Would it be possible to convert the SS1 binary to some kind of bytecode, then execute it on a Virtual Machine? I started an x86 emulator a few months back but it would've been slower than DOSBox. Maybe a VM designed specifically to replace an extender?
I could write a Java app to do the initial conversion to bytecode, but the VM would probably have to either be C++ or .NET (function pointers would be a requirement).
Anyone want me to investigate this further? A VM that can cope with code created on-the-fly might be awkward, but JIT bytecode conversion and compilation might solve it. The bytecode would of course be interpreted, but I'm considering an intermediate step where fixed logical addresses would be replaced by pointers to the VM's registers and memory space.
And why is it that ideas always strike at 23:15 when I'm trying to sleep?
[edit] *eep* I might want to do this whole thing in Java, actually. Managing memory will be a bitch otherwise.
Rejoice, for soon x86 DOS games will all run on Java VMs...
A VM on a VM? Yeah, I know it's slow. So? What do you expect to use a 3GHz CPU for anyway? :p
</return-of-the-mad-programmer>
ToxicFrog on 9/9/2005 at 22:56
Java?
JAVA?! Your words are madness, for Java is a creation of the elder gods that dwell beyond space and time, created only to drive programmers insane.
(you might want to look into (
http://www.lua.org) Lua, though. Garbarge-collected, function references, highly portable and faster, in my experience, than Java)
The big thing you have to ask yourself is: will this
really be any more compatible or performant than DOSBOX?
descenterace on 10/9/2005 at 00:04
No, but it WILL run games besides SS1 without hassle on WinXP.
Plus, I want to play Terminal Velocity again.
Java certainly seems to be... suboptimal... for this task. I might go for C# instead, but I don't know if Mono is up to this task yet and I don't like .NET 1.1's lack of generics.
If only Java supported delegates.
Actually, C++ is starting to look attractive again. Memory management shouldn't be a problem since I've come up with a way of handling a native/bytecode duality in the same memory space which doesn't involve heavy GCing. Nicest thing is, it supports self-modifying code. I can even fork off a thread for do background compilation.
Using static code analysis the 'compiler' would extract semantics from the machine code during the load phase. While it's running, execution lookups look at cached bytecode. If the required address hasn't been translated during the load phase, it means that the instruction pointer is offset from the expected position by a byte or two and the code is re-examined. Delays due to this should be small, and rare too if I can develop a flow analyser based on IDA's.
Data lookups look at the native memory space. If this is modified in any way, any cached bytecode in the affected area is deleted.
So now I need a lookup system that's as close to O(n) as possible with consecutive lookups. Some form of N-tree with a large N should do it, indexed by address.
ToxicFrog on 10/9/2005 at 00:30
Quote Posted by descenterace
No, but it WILL run games besides SS1 without hassle on WinXP.
Forgive me if I'm just not getting the point here, but what it looks like is you're designing a program that does what DOSBOX already does, with no significant performance or compatibility improvements, and expending a lot of effort that
could be put into improving DOSBOX itself...
Shadowcat on 10/9/2005 at 00:39
ToxicFrog: I've not tried this out yet, but I just want to say that you rock. Awesome work. Thank you!! :)
zac1302 on 10/9/2005 at 02:52
The patches just don't work for me in XP - when I try to switch to the higher resolutions (or watch the intro) my screen turns black, like the game's using an unsupported resolution or refresh rate. I've tried it with and without NOLFB, MOUSE2KV and VDMSound and played with all the settings I could think of. Any ideas?
Quote Posted by ToxicFrog
Anyone willing to test it on a win32 box?
I'll be testing it on two radically different 98se machines later today.
TheNightTerror on 10/9/2005 at 03:13
It's not working under XP for me either. I can actually get in game and everything, but when I switch to the highest resolutions, my monitor actually shut right off because of there being no signal input. :weird:
ToxicFrog on 10/9/2005 at 03:16
o.O That shouldn't happen.
I take it that it _does_ work when using the original?
Is your original the stock CDSHOCK.EXE, or Mok's patched version?
Do both the 800x600 and 1024x768 versions do this?
TheNightTerror on 10/9/2005 at 03:27
The original works just fine, and I was using Mok's patch. Both of the versions were doing this, and I got a general protection fault when I hit 'spacebar' to play the game the first time with the 800x600 version.
ToxicFrog on 10/9/2005 at 03:36
Wow, that is very odd. Especially the GPF - at that point it the game it hasn't, as far as I can tell, even hit the codepath I modified, as 320x240 isn't a VESA mode.
The aggravating part, of course, is that even an unmodified copy will behave differently on different NT systems, we don't have the source, my efforts to feed it to windows' pathetic excuse for a debugger have failed and I can't even get a decent core file from it. :mad:
In other words, I haven't the faintest of clues what could be going wrong and I can't figure out how to fix it. I'll see if I can get more testing data, but in the meantime, sorry, I have no ideas...if you do get another BSOD, though, could you copy down the register information from it?
