Messages

thx for keeping the project active

im still working on my 16-bit-opcode to c code converter/emulator in my very very limited spare time...
(btw: a nice and very small (due to real-mode-only) emulator able to run stunts is fake86 http://sourceforge.net/projects/fake86/)

very nice - restunts.exe seems to work ok

but the restuns-alt exe shows me just the same as the resunts.exe - how to go into mesh view mode?

nice work but... why on earth don't you use a real hex-editor like http://mh-nexus.de/en/hxd/ or others?

maybe it could help to have an good sounding midi (maybe an midi record of an roland mt32) to find out the right values by diffing to generated midi files

but anyway there shouldn't be much new stuff in it considering this midi converter works fine

clvn got still problems with the correct speed - as you can hear when listening to the midis in the zip-file

the biggest challenge would be understanding the format used for the samples - which cover both the musical instruments and the engine sounds if I'm not mistaken

any ideas :-)

[if someone wants to know why a conversion is needed]

@clvn
you can use dosbox to record the "original" midi-music - maybe that helps creating (finding) the correct values for the converter
http://ubuntuforums.org/showthread.php?t=458629

if someone wants to know why a conversion is needed
the target platforms for the port are windows and linux,... these do not allow direct control of the soundcard
so the music is needed in a more-up-to-date way for example, midi, wav,...

http://forum.stunts.hu/index.php?topic=2454.msg44125#msg44125

[thanx to clvn]

a more technical background for the restunts.exe

• the restunts.exe doesn't change anything in your stunts installation - add or remove it anytime you want
• based on the combined and cracked game.exe of the first post in this thread
• it is still a 16bit dos program, based on tasm/tlink - this is just the very first step of the reversing
• the current codebase is around 40 files and about 2.5mb of assembler code - a step by step c port ist planned
• each release needs to be tested very well - there i no way of doing an automated "this is perfect" test
• there will be an source (and tools) release later - the reversed source is still too hot :-)
• feature extention isn't very easy in this stage - its much more than just a decision to do it
• non developer users can currently only help with testing - strange crashes, wrong pictures, ...
• to reach this step, just create the very same exe - was a combination of serveral days hard word and an huge amount of low level detail knowledge - it isn't realy that easy - thanx to clvn
• the command line switch /ssb is needed for soundblaster sound - or just use the attached batch file for starting the restunts.exe

...but apparently the original ffe was written for 32-bit

oh! i forgot to mention this (small evil) difference

i was able to compile all functions in stunts into separate .obj files using tasm...

so your using the borland toolchain - i think that is the best decision - the best 16bit c and asm environment of that time
+ an wonderfull debugger - what version of borland c do you use - the one from the link above?
i think we should share our toolchain enviroment

...and a few minor adjustments...

do we need an transformer-script or something like that
is the adjustment regular enough for automation? what is you prefered language for scripting? python, perl, php...?

as an idea for the seperation: i would use a function prefix (fake namespace) in ida like unknown_, graphics_..., or msqc_ for automated
seperating the functions in different inc/asm and resulting obj files
(then we can start replacing the .obj bases with c derivates - step by step - without loosing the contact to ida)

and i think it would be great to have all the waiting-for-c-translation asm code in inline-assmbler inside an borland c projekt
(makes it much easier to play with the debugger and doing the replacing stuff)

ciao llm

and it think John Jordan is a good person to ask for the "right" way of doing the port
he creates jjffe - the reverse engeneered version of ffe (frontier first encounters) - from 16bit, dos-extender -> 3dbit win32(directx)

http://jaj22.org.uk/jjffe/jjffefaq.html#q3

as you can read here he used a special version of the ndisasm from the nasm assembler
maybe he could give good avises for doing the port

@clvn

i ask a friend of mine to diff the output of ida 4.9 freeware with a recent ida version - the differences for the
game_cracked.exe is marginal only some dos interrupts and std c library calls are better recognised

so is seems to be fully ok to go with the 4.9 version

>Hope it's useful

its informative - but a little bit outdated due to the fact that clvn already created an
combined version of the load.exe + hdr, dif, cmn and cod files - only the .drv file is still loaded at runtime
and this version is also cracked (no need for the "unoffical" stunts.com or stunts_k.exe anymore)

just use his version for further investigation (you can then delete load.exe/*.hdr/*.cmn/*.cod/*.dif and stunts.com, stunts_k.exe)

http://dl.dropbox.com/u/213479/execombiner.zip

im using the borland c++ 3.1 version from

http://vetusware.com/download/Borland%20C%2B%2B%203.1%203.1/?id=5888

the last pure dos version of "turbo" c with tasm

>i did use the freeware 4.1 version, which is rather old. mostly out of habit.
>after reading into collabreate, ive installed a newer version and upgraded the .idb,
>but havent really progressed any further. using the newer version still
>feels annoying due to some changed hotkeys.

i just saw the differences beween 4.9 and (i think) a recent 5.x version - and it produces a much better and smaller output

>so im still considering how to move forward. maybe making an intermediate 16-bit port in
>turbo c + tasm as the first step

the idea sounds good - got an version of tc/tasm around? maybe you use watcom c or djgpp

what version of ida do you use - newer version seems to do a much better job in reversing
im currently thinking about buying the latest edition