I'm Bringing It Up Again...

[Mentor]

TBH it would probably be easier to rip the gfx and write a GPX2 version of the game in question (apart from the fact that the GFX would be copyrighted), at least then you know the program concerned is going to run full speed (in the case of older DOS games anyway) since you don`t have that massive overhead in converting intel instructions into arm instructions plus all that architecture difference to allow for etc.

I have often wondered if emulation is the way to go, for the huge amount of work involved maybe someone could write an "alike" compiler, that takes the original exe and then breaks it down into bits (this draws this block of mem to the screen, this reads the keyboard etc), it would have a conversion program that takes the exe and spots all the IO calls, then converts that exe to run on the "emulator", but rather than emulate the cpu it just uses the equivalent ARM commands (or combinations), not as simple for the user to use as true emulator, but since the program has been "pre-calculated" so to speak.

So the user takes his EXE, has the "converter" change the exe to run on the "emulator" and then it should run a lot faster, it would write the equivalent emulated sequence, then convert to optimised ARM code with libs that handle IO and screen/sound etc, beyond my C skills, but it should be possible imo.

Mentor.

 

[craigix]

Hello Rayek,

My answer was entirely tongue in cheek, I was not being seriously nasty ;p

-Craig

 

[AireTamStorm]

Interesting. Interesting that a CPU designed to run games made in the early nineties is more complex than that of one that processes 3D images in more complex games.

​

x86 is braindead. It is a lousy, inefficient architecture, that needs to be scrapped, but m$ doesn't want to redevelop Windows because it would cost them LOTS of $$$ and so they put the pressure on for backwards compatibility. So even though it has been outdated several hundred times already, isn't dead yet.

 

[Rayek]

Microsoft is out there to make loads of money, and the way they can is by capitalizing on old systems that aren't worth anything? Makes sense to me, with emphasis on backward-compatibility. And even if they developed a better system for DOS or x86 programs, they wouldn't release the source, heavens no!

Craig:
Thanks for the response. The internet knows no tone!

 

[igboo]

I've just looked at the source for DOSbox........all i can say is its not exactly a small task....

​

I've been noodling through the source for Dosbox for the last couple of days, and your right... it's gonna be a lot of work.

What I see happening is this. All of the command line stuff will get ripped out and instead any start up commands for each program will go into a script. This will allow startup just like any other emu. Just pick the script name from the file list and let it run.

Max CPU I'm guessing without further testing will be approx a 386DX/25 or 50. Just enough to run most of Apogee's older stuff. And I'm gonna have to re-learn some Arm assembly to get that.

Keyboard mapping is still a pain that I haven't really looked into yet, but there are a lot of games that use their own control mapping that's different from anybody elses. Maybe that'll be something for the start up scripts.

Hmmm. With the time I've got to work on this stuff, I'm sure somebody else will beat me to it. It should make for some interesting learning though.

Igboo

 

[Jarska333]

Don't forget GUS-support!

 

[Z80]

Max CPU I'm guessing without further testing will be approx a 386DX/25 or 50.

That's good enough for Gunship 2000, I really want to play it on a handheld.

 

[igboo]

Don't forget GUS-support!

​

Yeah, yeah... add in a whole 'nother nasty processor for me to deal with along with midi patches,etc. Won't that be fun. :rolleyes:

At this point, I'm looking at Adlib, SBPro and PC speaker. And that'll be if I figure out how to get the GP2x's second processor involved.



Igboo

 

[nubie]

TBH it would probably be easier to rip the gfx and write a GPX2 version of the game in question (apart from the fact that the GFX would be copyrighted), at least then you know the program concerned is going to run full speed (in the case of older DOS games anyway) since you don`t have that massive overhead in converting intel instructions into arm instructions plus all that architecture difference to allow for etc.

I have often wondered if emulation is the way to go, for the huge amount of work involved maybe someone could write an "alike" compiler, that takes the original exe and then breaks it down into bits (this draws this block of mem to the screen, this reads the keyboard etc), it would have a conversion program that takes the exe and spots all the IO calls, then converts that exe to run on the "emulator", but rather than emulate the cpu it just uses the equivalent ARM commands (or combinations), not as simple for the user to use as true emulator, but since the program has been "pre-calculated" so to speak.

So the user takes his EXE, has the "converter" change the exe to run on the "emulator" and then it should run a lot faster, it would write the equivalent emulated sequence, then convert to optimised ARM code with libs that handle IO and screen/sound etc, beyond my C skills, but it should be possible imo.

Mentor.

​

I think there is a thread on this somewhere.
It's possible, not feasable, and your IQ/Experience should be over 150 before you even attempt it.
I think it's probably easier to get ahold of the source code then to try and reverse-engineer it .

That said, it might be possible to reverse engineer old-school dos games, considering how small they are, and what they do is fairly well known because their architecture is so simple.

Ironically we would probably be back in DosBox, copying down the instruction calls to see how the game is put together

 

[Robster]

x86 is braindead. It is a lousy, inefficient architecture, that needs to be scrapped, but m$ doesn't want to redevelop Windows because it would cost them LOTS of $$$ and so they put the pressure on for backwards compatibility. So even though it has been outdated several hundred times already, isn't dead yet.

​

AireTamStorm: Your comments about x86 are half-right, but you miss the point. Even though x86 is register-starved and its instruction decoding is appallingly complicated, so much has work has been done on optimising the architecture that it really does perform well. Especially with AMD's architecture (it's well accepted that Intel dropped the ball badly with NetBurst), the incredibly clever branch-prediction, out-of-order execution, multiple issue etc features produce an overall product that is no easy-beat.

If x86 was so disastrous, then UltraSPARC, or Alpha, or even ARM would have knocked it off top spot, even with Microsoft's huge weight behind x86. Just remember, making a new architecture to become the new king isn't easy... Itanium, anyone?

 

[AireTamStorm]

If x86 was so disastrous, then UltraSPARC, or Alpha, or even ARM would have knocked it off top spot, even with Microsoft's huge weight behind x86. Just remember, making a new architecture to become the new king isn't easy... Itanium, anyone?

​

Microsoft is pretty much the only real reason that x86 hasn't been redesigned (dropping backwards compatibility in order to support new features and increase efficiency). x86 probably wont die for a while, but there are CPUs out there that put it to shame with less power consumption and lower clock rates. I mean, just look at the Cell, although thats a very recent innovation.

For the most part I agree with you though. But it is my opinion that x86 should die.

I mean look at all those proud owners of AMD64s! They're using 64 bit CPUs that are mostly running 16 bit code. Anyone that's done x86 assembly knows that it takes some roundabout instructions just to get 32 bit precision, who knows what it takes to get the rest on x86_64. And if you're running a 32 bit OS on it.... really, whats the point?

 

[haplo]

it's great that the x86 archetcure has been so optimized, but those are CPUs with billion dollar R&D behind them. Software x86 emulators I doubt can be that advanced So they'll certainly be slower.

as for x86 still being around, things are getting interesting. Apple just dropped PPC for the x86 which sort of seems retarded, although Intel seems to be moving towards power efficent CPUs now for apple at least, which is good. How ever this amusingly left IBM in the lurnch with a whole ton of few year old PPC factories. So they;re havd to do the only thing they could... push Linux. They've made an OpenPPC site and are puhing Linux of PPC for servers at least decently aggresivly, because it's the only thing that will run on their chips now . PPC is kind of becoming the archetecure of Linux. I hope soon we can get some power efficent PPC desktops and Laptops from IBM with Linux on them. I'd buy one.