Has anyone tried to make one of those, and put Stunts on it? :D
No time tonight, but I might give it a try in the future, for CTG's joy!
get know if you are lucky :)
That would be a nice thing to have. I hardly remember what playing under pure DOS felt like ::) (I once tried doing that in a VM, but it didn't work first time and I was too lazy to try and tune FreeDOS until it worked.)
ZakStunts hosted a FreeDos based bootable CD image including full competition archive around 2005 for several years, prepared for the second WSM. It was working well so assume it should be the same case with a USB stick - with the extra benefit of being able to save your replay directly on the USB stick.
Small update: creating a Freedos usb stick is very easy using Rufus (http://rufus.akeo.ie/)!
Quote from: dreadnaut on October 03, 2013, 10:51:09 PM
Has anyone tried to make one of those, and put Stunts on it? :D
No time tonight, but I might give it a try in the future, for CTG's joy!
I have tried without success with freedos. I ran into multiple problems.
first with the executable, it could not run stunts (packaged file.. error) this seemed to be fixed with the LOADFIX program.
Then i ran into memory errors. e.g. Not enough memory to run.
that could not be solved with the standard Himemx en 386 counterpart.
Jemmex solved the memory problem but ran into an error when starting stunts.
I also downloaded Dos 7.1 and copied HYMEM and EMM386 from there.
No luck with either of them.
after about 4 days i setup a VM to boot from my freedos USB,
and an other VM that booted DOS7.1 from another USB.
that speeded testing up a whole bit.
VM Freedos had the same errors, worked on it a while and gave up,
Dos 7.1 ran no problem, with sound and everything right form install. no editing necessary,
But when i booted DOS7.1 on my regular machine the CPU gave problems. No fix as far as i can tell.
But i have a cheap old (1CPU 1ghz with 1gig ram) laptop.
That gave some EMM386 errors that would feezeup the system
but i managed to solve that, (see link below)
I have now a MS-DOS 7.1 on USB that runs Stunts perfectly.
(just need to work on sound a bit but i haven't even looked at that yet)
It looks like original dos is an easier option to go for in this case for me.
I used Dos-to-USB, and it worked.
https://download.cnet.com/DOS-on-USB/3000-2094_4-10795476.html (https://download.cnet.com/DOS-on-USB/3000-2094_4-10795476.html)
for the EMM386 memory problems:
http://www.abandonia.com/vbullet/showthread.php?t=9744 (http://www.abandonia.com/vbullet/showthread.php?t=9744)
I don´t think that this will work on all systems. But its a start.
I have some ideas for Freedos to try. but i wanted to share this.
Overall this has kept me bussy for about 2 weeks ???
Oh! I haven't tried those utilities to create a FreeDOS or MSDOS 7.1 USB flash drive. I think I tried at some point long ago and had difficulties, but I don't remember which method I used. Anyway, on my computer, I have FreeDOS in a separate partition and it boots well and can run Stunts, but I installed FreeDOS from a CD. What I can add are the following points:
- FreeDOS, MSDOS and any DOS are real mode operating systems and depend on BIOS functions and on the MBR partitioning system. They will fail to install and/or run properly if your computer does not have ROM BIOS functions or does not support MBR system. New computers typically come ready for the UEFI system, but many can still be configured to work in MBR mode (especially desktop computers). In order for DOS to work, you have to partition your hard drive in MBR mode. Even if you're not installing DOS on your hard drive, some UEFIs won't be able to boot flash drives in MBR mode unless all drives are set up in that mode too. That seems to be the case of my newer desktop computer. Same goes for boot CDs.
- I'm pretty sure that Stunts does not require EMS, so I wouldn't recommend running DOS with an expanded memory manager to run Stunts. EMMs also put your processor in virtual 86 mode, which makes old real mode programs slightly more unstable. Better use pure real mode. HIMEM.SYS provides access to extended memory. I don't remember if Stunts uses this, but it won't hurt. Not sure about LoadFix, but LoadHigh will be useful to keep drivers in high memory (not the same as extended memory). Also, don't load a CD ROM driver. It takes lots of conventional memory and Stunts doesn't need it. FreeDOS sets up a CD ROM driver by default so you may want to remove this from your CONFIG.SYS or AUTOEXEC.BAT.
- Sound... well, that's hard to solve in pure DOS. If you have a computer old enough like the motherboard has ISA card slots, you're in luck. Almost every ISA sound card you can find in stock somewhere will be compatible with SoundBlaster Pro. Some PCI sound cards do have some degree of compatibility with SB Pro, but that won't help for Stunts. They mostly have to be cards by Creative and while the compatibility is reasonable for the DSP (sampling), it usually fails for FM synthesis (which is what Stunts uses). Newer cards are guaranteed not to work. Up to some point, computers at least included an internal PC Speaker, but now most don't. Still, many computers that don't include such speaker do have the pins in the motherboard where you can plug one. These speakers are cheap and can be found in electronic shops.
- If you can get a booting FreeDOS, but you would like a newer version and that one is not working, you can just install the old one and then copy the kernel and other files directly on top of that install and that'll be fine. If you have problems booting MSDOS 7.1, you can get a copy of bad-old Windows 95 or 98 and strip it from everything but the DOS part.
My two laptop's are both old enough to support MBR. (Legacy mode it's called in one of them)
So I have hope. Booting from usb is not a problem either.
CAS, can you please send me a copy of your cofig.sys (fdconfig.sys) and autoexec.bat?
Maybe I can figure it out 8)
Right now, I have it installed with what I think is the default. I'll upload them here. But it's been some time since I last ran Stunts in pure DOS, so I'll give it a try now and I'll tell you how it does with the different menu options....
Alright... I wasn't able to get it to run properly. This is as much as I could get:
I booted with the last option and I was getting "Packed file is corrupt" errors. My first thought was that it had to do with game speed, so I used a TSR that slows programs down, but it didn't work. Then I tried loadfix and was able to run the Setup, which hints that this is a memory geometry problem, but Stunts itself wouldn't run with loadfix. It doesn't give the former error message, but it crashes.
So I restarted with nothing by using F8 and skipping everything but the basics. It doesn't work. Then I tried again with HIMEM only. This sort of worked. I was able to get Stunts to start by running it with loadfix. No sound whatsoever, having set it up for internal PC speaker, meaning I don't have one. I can use the menu, but when I try to race, I get a sign telling me that there isn't enough memory, which isn't true. Other games run fine.
My guess is that Stunts has a complex strategy in memory handling to try to maximise conventional memory available at run time. This was common in old games, but sadly, makes it non-standard and it turns out that many modern computers have a very weird low-memory geometry as they reserve blocks there for UEFI stuff perhaps. As a result, only games that manage their memory exclusively by calling DOS interrupts will have a good chance to run well or those that do it via a DPMI. Others... it depends... There probably is a way to trick Stunts with a EMM driver so that it thinks it's accessing a region, but actually, it's another, but it'll take me some time to find the configuration and it will probably not be the same as you would need on your computer. Besides, Stunts might not like the driver and become unstable. I'd say you need a really old computer with a pure BIOS-based system to run Stunts without problems natively, I'm afraid.
I've noticed that freedos has 635k of conventional memory in stead of 640k in MS-DOS.
Stunts in VGA mode requires the full 640k to run
E.g. it seems that it isn't possible to run stunts in freedos unless this can be altered.
::Side note:: does 'restunts' have an effect on memory handeling?
Can't download it anymore so I can not test this.
Quote from: Daniel3D on July 30, 2020, 04:30:19 PM
E.g. it seems that it isn't possible to run stunts in freedos unless this can be altered.
For a different point in configuration space, I did manage to run Stunts (while actually getting to drive) under FreeDOS + VirtualBox a while ago. The main difficulty was with sound: PC speaker doesn't work, and Sound Blaster crashes on game startup no matter what. To get working sound, I had to switch from VirtualBox to QEMU and find out appropriate BLASTER settings for AUTOEXEC.BAT (http://wiki.stunts.hu/index.php?title=Sound#Virtual_machines) (this QEMU test was done with MSDOS, but I suspect FreeDOS would also have worked).
Virtually, DOSBox does such a great job, that I've never tried any other thing. I do have a few old computers, but I would have to clean them, find some DIN5 keyboard and a serial adapter for the mouse, etc.
About conventional memory, yes, some games used to be more demanding than others, but having the full 640k free is almost impossible. Remember that MEM substracts its own memory consumption for the estimation and COMMAND.COM unloads its transient part when running programs, keeping the resident part (which is usually loaded high), so the estimation is not totally accurate.
About high memory and UMBs
I think the problem here has to do with high memory and upper memory blocks. The thing is this: the first megabyte is composed first of 640k that are guaranteed to be RAM. The first kilobyte is used by the BIOS to store some configuration and by the microprocessor to keep track of the interrupt vectors. A portion of the DOS kernel lies usually in the lower part of these 640K and, if you use DOS=HIGH, it's moved to "high memory" or if you use "UMB", to upper memory blocks. The thing is conventional memory goes up to 9000:FFFF. After that, you have the video RAM, from A000 :0000 to B000:FFFF. From that point on, it all depends a lot on your computer. There is a region that's often used by expanded memory managers, another one that points to parts of the ROM BIOS, but these may be located differently. Any RAM available from that point onwards is called high memory and UMBs are a particular region that, if I remember correctly, are often taken by ROM, but sometimes not, so then you can use them. The thing is that it seems new computers usually don't respect these old non-standard trends and everything after the video RAM is pretty unpredictable. This is why memory management for DOS on new computers is not good and some games are never satisfied. DOSBox, as an emulator, does respect this very well: it's its job.
Memory management in Stunts is weird
When I was working on the Vizcacha project, I had problems because of how Stunts manages its memory. I examined the structure of the memory used by Stunts with a TSR, but then, when I made another TSR to make use of that, I realised that Stunts not only loaded at a different point in memory with my TSR, but also, distributed its memory blocks in a comlpetely different fashion from what it did with the other TSR. Because of this, besides my TSR not being able to achieve the desired goal, its presence tended to mess up with Neverlock, which was now unablet o find the memory block were Stunts held its copy protection scheme data. As a consequence, copy protection was enabled when entering Stunts. LOAD.EXE does very weird things including copying parts of other executable code pieces on top of itself as it runs. Very hard to solve :S
Yeah, stunts is a pain to get to run outside a virtualized environment. But it was possible, so I want to make it work. (I'm so close)
Two Three thoughts.
Some games from the 640k era were later revived with a new memory handeling. (Dos4gw?? I believe)
Stunts missed that.
And I would like to know is restunts changes memory handeling (I am afraid not) because it bypasses load.exe..
See: http://forum.stunts.hu/index.php?topic=2454.0 (http://forum.stunts.hu/index.php?topic=2454.0)
About the copy protection. Could we remove all the answers with stressed? Then no crack is needed..
Quote from: Cas on July 31, 2020, 03:16:21 AM
...Because of this, besides my TSR not being able to achieve the desired goal, its presence tended to mess up
with Neverlock, which was now unablet o find the memory block were Stunts held its copy protection scheme data.
As a consequence, copy protection was enabled when entering Stunts. LOAD.EXE does very weird things
including copying parts of other executable code pieces on top of itself as it runs. Very hard to solve :S
Stunts can run in CGA/EGA/MCGA/Tandy Mode (configured sound driver get loaded dynamically after the game is started)
the stunts exe would have become too big back in that days so the developers invented a system that allows to
create a real dos exe - in memory - from the game-code and configured graphics-mode-code, that is the purpose of the LOAD.EXE
- to reduce executable size
there are two programs (one by user clvn the other by w4kfu - see the reverse engineering thread)
which can do this upfront resulting in a plain dos executable for each graphic mode
(these executables are the base for the restunts project)
svn://anders-e.com/restunts/trunk/restunts/src/execombiner
the copy protection is just a single byte switch
btw: i've also managed to integrate the sounde-driver directly into the game-exe
(so no dynamic code loading anymore just to ease reverse engineering even a bit more)
svn://anders-e.com/restunts/trunk/restunts/src/drvcombiner
the stunts executeable just allocates all free memory and handles the rest of allocations with an self written
internal memory mananger - thats it
Quote from: Daniel3D on August 01, 2020, 07:01:47 AM
Two Three thoughts.
Some games from the 640k era were later revived with a new memory handeling. (Dos4gw?? I believe)
Stunts missed that.
And I would like to know is restunts changes memory handeling (I am afraid not) because it bypasses load.exe..
See: http://forum.stunts.hu/index.php?topic=2454.0 (http://forum.stunts.hu/index.php?topic=2454.0)
About the copy protection. Could we remove all the answers with stressed? Then no crack is needed..
DOS4GW is a 32Bit DOS Extender - Stunts is a 16bit real mode (80186er Code) program - so there is absolutely no use for that
the stunts game needs to be compiled different (for 32bit and with an extender) to use that - but that is not possible without the source code
stunts just uses all conventional memory it can - no EMS/XMS etc. himem could be of use to get dos out of the way
i don't think that restunts reduces the needed memory amount - but i've never got any problem to get it run
under Dosbox or in Virtual Machines under a real dos (with the very same memory constraints) - so whats the problem?
is freedos just to memory consuming?
Stressed does not work in any way with the executeable - but its easy to create the non LOAD.EXE using the execombiner
and patch the single byte to prevent copy protection
see subversion links with code and this post: http://forum.stunts.hu/index.php?topic=2454.msg43618#msg43618
Quote from: llm on August 01, 2020, 11:41:30 AM
- so whats the problem?
I think mainly my poor understanding of DOS
and i've never tried stunts with freedos :)
i've tested freedos + stunts on real hardware - worked out of the box for me
my howto:
1. download Rufus: https://rufus.ie/
2. download FreeDos: http://www.freedos.org/download/download/FD12FULL.zip
3. extract zip
4. start rufus and install the FD12FULL.img on a FAT32 USB-Stick that is bootable
5. copy over the stunts folder
6. boot you pc with the usb stick and play stunts!
the Rufus builtin FreeDos Option didn't work for me - im getting out of memory messages on starting stunts
I've done that and just did it again to be sure.
Boot's fine,
First try a packet file error.
With loadfix I get an io error. I starting to suspect it's a CPU that is not DOS compatible.
Quote from: Daniel3D on August 01, 2020, 06:18:05 PM
I've done that and just did it again to be sure.
Boot's fine,
First try a packet file error.
With loadfix I get an io error. I starting to suspect it's a CPU that is not DOS compatible.
That loadfix program? https://www.dosbox.com/wiki/LOADFIX
Its definitly not needed for Stunts which is not in any form memory size problematic
A not DOS compatible CPU is also very unlikely
Stunts is a very simple, clean plain dos program without any bad programming as in some other old games
sorry i usually use the execombiner executeable because this stunts_k.com-Neverlock thing is not even part of the original release
its some sort of crack program (that can be problematic) i do not trust this program and its not needed when the loader.exe get replaced with the original exe
i've attached my executeables - game.exe is directly created with the restunts-execombiner tool (based on the original stunt files)
game_ad/pc.exe is adlib or speaker sound driver directly integrated with the restunts-drvcombiner - all in MCGA mode - already cracked
just start game.exe or game_pc.exe in the stunts folder
there is no loading or runtime patching happening, game.exe is the pure original game executable (and because of that much easier to reverse engineere)
Does it matter which version of Stunts I use with these files?
I don't know, these exe were created using files from stunts 1.1 from kalpen: http://stunts.kalpen.de/downldst.htm, i would try it first with that version (im currently not at my computer)
Works with all versions except 1.0 in dosbox.
Works with fresh freedos (game.exe at least) on my laptop. (1 of them)
ill have to work on the sound
the funny thing is that i had the errors with the original executable to.
I checked that.
You need to use commandline parameters with game.exe
/ssb - use soundblaster (ad15.drv) instead of pc speaker
/sXY - use driver XY15.drv instead of pc speaker (e.g /sad for soundblaster)
So game.exe /sad or game.exe /spc
At least game_pc.exe should give you pc speaker sound
All 80x86 and AMD64 compatible CPUs are compatible with Stunts. I think the problem lies in the UEFI/BIOS installed in your computer main board. Stunts executables has a very normal behaviour for a 1990 DOS program, but this is not the same as what computer designers and DOS makers would consider normal.
For example, when protected mode came up, CPU manufacturers expected new OSs would run natively in it, but instead, drivers like HIMEM.SYS were created to make it possible to access extra memory by jumping back and forth between real mode and protected mode, so DOS could continue to run in real mode. People don't like changing and try hard to continue to do things their old way.
When OSs finally started to migrate fully to protected mode, CPU and OS design forced programmers to not "misbehave" anymore in some aspects. It was common in DOS to access memory that was not reserved for your program, to tweak things in the system without asking the OS to do it for you, etc. Now memory protection made that impossible. Also, you couldn't modify the memory were your executable code was loaded because the OS made it write-protected. So, looking at Stunts code or many other DOS programs of the time, one could say now the code is "misbehaved", but of course, this wouldn't be the way of seeing it back in 1990. These strategies were considered optimisations back then. Self-unpacking provided a way to take less precious disk space, self-overwriting made the code more obscure for automatic unassemblers, making the program less hackable. Loading external binary files on top of part of your code manually would make your programs load much faster than having to request the OS to link your code in memory to a library. And CPUs were not that fast, so that was important.
Of course, if I knew exactly what's going on, I'd be able to give you an easy fix for your computer. I don't. I just suspect from the behaviour that it's this. I'm having the same problem on my current desktop computer. I'm not surprised because I've experienced similar things in the past. One thing I can say for sure: if you try the same on an older computer, it'll work. Newer computers are very real-mode-unfriendly. Not CPUs... computers, like... the mainboard, the interface, the firmware, etc.
@Cas
Protection like you described is a hardware thing that needs the correct cpu mode and configuration done by the OS, wich is not the case here, the original stunts code works just ot of the box, only this crack stunts_k.exe wich is not part of the official release got problems, it seems to work under real microsoft dos so i think that freedos is doing something different - for example freedos still can't run win 3.11 in enhanced mode due to diffenences in memory managment etc. I think that is the reason and the solution is to use the original game exe and not depend on some cracking loader stuff
I'm a bit confused. (Don't worry, I'm used to it)
The cracked executable gives problems, that's understandable.
Restunts game.exe runs fine everywhere (dosbox, freedos and MS-DOS)
The original executable stunts.com won't run in freedos or MS-DOS either.
That is my experience, so there's a difference in the way the program is executed.
.... I'll get back to this....
Im also confused...
Is stunts.com part of the official disk images: http://stunts.kalpen.de/downldst.htm, the first two zips with original package disks?
ok stunts.com is part of the official package
All my stunts versions are from kalpen.de or except for the competition version.
But maybe it crashed on sound. I haven't setup a sound driver but maybe the copy of Stunts is looking for it. Will look into this later..
stunts.com is identical for all "reachable" installations (http://stunts.kalpen.de/downldst.htm and http://wiki.stunts.hu/index.php/Download)
and gives mit a "packed blabla corrupted" error message
stunts.com is only a starter for load.exe
does it also happen if you start stunts with "load.exe /u MCGA /spc" - UPDATE: yes it does
so its the load.exe that make the problem - not stunts.com, not stunts_k.exe
Solution!!!
the load.exe itself is packed with EXEPACK (an old executable compressor from Microsoft)
unpacking it with unp (http://unp.bencastricum.nl/) makes it startable under FreeDos (maybe also under DOS)
normal start of stunts works like this
1. load & run stunts.com
2. load & run load.exe(EXEPACK unpack)
3. combines some files from stunts (also unpack them with an stunts unpack algorithm)
4. start game in memory
or use the execombiner exe which is just
1. load & run game
:)
It was the sound.
ran setup and disabled sound, no problem. on PC speaker also no problem
so stunts runs. problem solved. [EDIT] runs in MS-DOS. [/EDIT]
next stop, getting sound...
NB: haven't done sound config in dos on 25 years or so.,. and never on a "modern" laptop.
modern is relative here since the laptop was designed for windows XP
to be continued....
EDIT::
sound not supported in dos, not possible either according to internet. Chipset not reverse compatible.
I'm gonna put this project on hold for now..
Its an EXEPack Bug - official and well known by Microsoft: https://jeffpar.github.io/kbarchive/kb/072/Q72360/
using loadfix is a Microsoft tip to prevent this EXEPack Bug - but that does not work if used on stunts.com only on load.exe will help
PROVE!!: https://pasteboard.co/JktVtei.png -
so you're right Cas it is something from the Hardware - good old A20 Gate :)
https://www.bamsoftware.com/software/exepack/ (there is also a windows exe available for unpacking)
QuoteA20 bug?
"yes" means the stub relies on 8086-style 20-bit address wraparound; i.e., it requires the address fff0:0123 to map to the linear address 0x23, not 0x100000023. Stubs with this bug may falsely error out with "Packed file is corrupt" when run at a low address in memory.
http://www.os2museum.com/wp/exepack-and-the-a20-gate/
Quoteclearly points at the real problem: "The Gate A20 signal is in the wrong state after the system is booted."
some versions of EXEPack did not suffer from this problem
easily to fix by unpacking the exe - its easy and does not change anything in the game - the original developers also runned the EXEPack Tool AFTER creating the exe from source - to make it smaller - we just revert this process and remove the buggy unpacker from the original file
the primary problem that there is no clean official package that solves such problems for everyone - time to speak to Kalpen to update the package :)
Quote from: llm on August 02, 2020, 11:36:46 AM
the primary problem that there is no clean official package that solves such problems for everyone - time to speak to Kalpen to update the package :)
You mean a repack of the original files that are clean but keeping as much in tact as possible (except copy protection) ?
QuoteYou mean a repack of the original files that are clean but keeping as much in tact as possible (except copy protection) ?
A: at least the EXEPack unpacked load.exe (if that still work with stunts_k.exe for unprotecting?)
the unpacked load.exe just removes the buggy unpacking stub and does not change any code of the game
B: or using the execombiner versions: but then you need a game_mcga.exe,game_cga.exe etc. one excutable for each grafix setup (cga/ega/tandy/mcga)
and the stunts.com, setup.exe is then not useable/needed anymore
C: unpack the load.exe, unpack the code-files, remove copy protection and compress the files again to be useable with load.exe
Option A doesn't feel right. It fixes the problem but a crack is still needed.
Option B is kind of what restunts does. So we already have that.
Option C is most appealing to me as it fixes the issue and the need for a crack.
Of course this all only matters if you want to play without emulator.
Quote from: Daniel3D on August 02, 2020, 07:11:21 PM
Option A doesn't feel right. It fixes the problem but a crack is still needed.
Option B is kind of what restunts does. So we already have that.
Option C is most appealing to me as it fixes the issue and the need for a crack.
Of course this all only matters if you want to play without emulator.
A is the least changing, only load.exe gets modified, setup still works
B is the one with the most new executeables, no changes, setup does not work with these you need to configure sound setting via commandline
C is the one with most changed files: .cod, load.exe, etc., setup still works
True. But in de end you only have (modified) original files. So basically what you had on the disk.
Feels most authentic to me.
Copy protection is outdated, nobody cares (probably) and it's a nuisance.
I don't know what the others think about this.
There is another problem with C
To remove the copy protection the files that get combined in memory with load.exe needs to be unpacked using https://github.com/dstien/gameformats/tree/master/stunts/stunpack
, patched to unprotected - its not clear if load.exe can handle unpacked files or if the files need to get repacked - i don't know an implementation for packing, only for unpacking
Found a compressor: https://github.com/w4kfu/Stunts/tree/master/comp
Quote from: llm on August 01, 2020, 11:41:30 AM
...and patch the single byte to prevent copy protection
see subversion links with code and this post: http://forum.stunts.hu/index.php?topic=2454.msg43618#msg43618
Quote. some further analysis reveals the the output game.exe from the above program is compressed with exepack, as with load.exe.
to remove the copy protection, uncompress with unp and put a byte 0x1 at offset 0x2b3c
I'm not sure in which file.
But it seems like 1 file for the copy protection
And if it's another file load.exe that needs repack.
So 2 files to alter for option C
(Unless I totally missed something)
Although I can follow the conversation I'm not going to attempt to make these changes. Not comfortable with this level of editing :P
Edit: missed end quote...
Hey, guys... It's late and I'm super sleepy, so excuse me for not reading all recent messages in detail. After giving a quick look, I'm thinking of these things:
- As I understood it before and I think it's the same as stated now, stunts.com reads the config and calls load.exe with the command line corresponding to the configuration. Then, load.exe runs and unpacks itself. Once unpacked, depending on the command line, selects a graphics driver and writes the driver file on top of itself at some part in memory to modify the game's code so that it works for that adapter. After that, the game continues without significant modification of the code segment. Am I right?
- If I'm right about the previous thing, then unpacking load.exe and precombining it with the MCGA driver, which is the only graphics driver we really use and then running that final executable file, without needing to recompress it, would yield a normal EXE file that would not do weird things in memory. Can that be done? I really haven't read restunts in much detail. Maye all this is already thought of.
- Finally, stunts_k is a TSR that works by waiting for Stunts to be in memory, unpacked an all, and then checks a certain region of memory in order to crack the "security system". If it fails to find this region, it does nothing, potentially making the game unstable. Modifying the executable has a chance of interfering with stunts_k. I've confirmed in the past that loading other TSRs before stunts_k does often interfere too. I think if we have the keys, it's "healthier" to just avoid stunts_k, but we can continue to use it whenever things work well.
Thx, i forgott that the combined result is also exepacked, makes it even harder to reach just C
(more then 10 years since ive worked on the load.exe analyzation...)
load.exe combines stuntspacked files which results in a in memory game executable that itself is exepacked, its easy to patch the protection in the end result, but very hard in the starting components
Quote from: Cas on August 03, 2020, 07:04:15 AM
If im right about the previous thing, then unpacking load.exe and precombining it with the MCGA driver, which is the only graphics driver we really use and then running that final executable file, without needing to recompress it, would yield a normal EXE file that would not do weird things in memory. Can that be done? I really haven't read restunts in much detail. Maye all this is already thought of.
Thought out and working for the last decade :) that is what the execombiner from the restunts project does, that is the base for all reverse engineering analysis
svn://anders-e.com/restunts/trunk/restunts/src/execombiner (uses https://github.com/dstien/gameformats/tree/master/stunts/stunpack)
other implementation: https://github.com/w4kfu/Stunts/tree/master/makegame
the drvcombiner goes even further and integrates a selected sound driver into the exe
svn://anders-e.com/restunts/trunk/restunts/src/drvcombiner
an svn client is needed for the svn:// repos - like subversion on command line or for example TortoiseSvn
all that is done to ease the analyze process with IDA or Ghidra - something that is very hard using this high dynamical behaving load.exe
So, if i understand correctly it is very difficult to remove the copy protection from the original file without using execombiner to make a new executable.
Not that i'm opposed to the idea. But it would have been nice to have a ' Freeware ' edition with only original files and working setup..
QuoteSo, if i understand correctly it is very difficult to remove the copy protection from the original file without using execombiner to make a new executable.
correct
the freeware edition would have changes in serveral files and setup is then dead
we could have serveral executables and our own stunts.com (using setup.dat for configuration calling the correct game executable with correct parameters) - but then is maybe more like an "extended" edition
That's sounds reasonable. We could update the version number to 1.2 or something so it is clearly something new.
(I've done that in my testing copy. 8) just because I can )
Quote from: Daniel3D on August 03, 2020, 01:27:05 PM
That's sounds reasonable. We could update the version number to 1.2 or something so it is clearly something new.
ok - will take a look what is needed
Quote from: Daniel3D on August 03, 2020, 01:27:05 PM
(I've done that in my testing copy. 8) just because I can )
"Once you start down the dark path, forever will it dominate your destiny, consume you it will."
QuoteBut how am I to know the good side from the bad?
Some way to distinguish the alternate version would be sensible. If only for support reason's
It'd be great if that were fully solved and we were all just using the simplified version. So that's the idea behind Restunts, ha, ha. This has happened to me many times: I watch somebody else's code or read a book about something... I understand nothing. Then I sit down to think alone and I come up with the same ideas that were there. My programming is very much lone-wolf-styled :P I've programmed this way since 1991 or so.
Quote from: Cas on August 04, 2020, 02:07:03 AM
It'd be great if that were fully solved and we were all just using the simplified version. So that's the idea behind Restunts, ha, ha.
Restunts is splitted in three parts:
First: the delevopment of tools that remove cracking or any dynamic loading to ease it for reengineering tools:
DONE around 2009: so working for the last 11 years :)
--> that is the game.exe i attached here for Daniel3D
Second: Reverse the game to assembler that assembles to the very same (100%) original exe:
DONE around late 2009: so also for the last 11 years :)
--> that was the first restunts.exe that is sometimes attached in forum post around the "Reverse Engineering" Topic
Third: Porting function by function to C code and link that to the remaining assembler code (producing the restunts.exe): the creation/function overloading is fully scripted and working for the last 11 years - but the function porting (~800 Functions, 2.5MB of assembler) is not easy an takes much much time -
maybe 50-60% done in 2009-2012... i think
--> that are restunts.exe that is are attached in following forum post around the "Reverse Engineering" Topic
--> also the rpldump tool is based on that code
there are no technical obstacles - just much much of manual asm to c porting work and much much reverse engineering understanding of the asm code
everything is public available, buildable from source and nearly working right out of the box
Oh, then it's much more advanced than I thought! One thing is coming to my mind.... What if the code were translated as-is to native assembly, plus C for modern systems? That is, replacing DOS function calls with their "equivalents" for each system, and so on. This could be done pretty fast and would allow to compile and run the game immediately and then, continue analysing the code and turning assembly into C, but we wouldn't have to wait until it's fully completed to use it.
Quote from: Cas on August 04, 2020, 08:27:57 AM
Oh, then it's much more advanced than I thought! One thing is coming to my mind.... What if the code were translated as-is to native assembly, plus C for modern systems? That is, replacing DOS function calls with their "equivalents" for each system, and so on. This could be done pretty fast and would allow to compile and run the game immediately and then, continue analysing the code and turning assembly into C, but we wouldn't have to wait until it's fully completed to use it.
Stunts is 16 bit segment/offset real mode code that means you can only run in 16bit emulation mode under Windows - without ability to call even 32bit APIs, direct graphics and sound programming is also a big problem - most games that are reversed like that are already 32bit flat-mode code with dos-extender (for example Syndicate Wars) - converting the 2.5MB/~300KLOC 16bit asm to 32bit asm is nearly impossible and can't be done in small steps
i've always thought about converting the 16bit asm to functional equivalent C-code (like https://github.com/xor2003/masm2c does) but its still a huge challenge to come to the same behaving code, xor2003 startet to write a new asm parser/generator right now for stunts - but that will still take some time
another idea was to use DosBox as an environment like Bright-Eyes (https://github.com/Henne/Bright-Eyes, process-description: https://github.com/Henne/Bright-Eyes/issues/49) does intercept the function calling and routes that to real real C functions interacting with the emulated environment - thats why i played with some sort of emulation and changed the simple x86 emulator Fake86 to become a StuntsVM (which is only and direct capable to run stunts - also available here in the Forum) - but its all very time consuming
the current restunts function were ported under DOS with simple debuggers etc. very time consuming etc.
Yes, I imagine :( It's too much assembly code!
Of course, translating assembly manually would take just as long as translating C, perhaps, so there's no point, but I was hoping it'd be possible to "automatically" convert assembly. Like... the code is separated in its functions and then each call to each function is transformed into a 32bit call to a 32bit memory region instead of 16bit segment:offset. Non-flow instructions are translated to their equivalents in 32bit, sometimes an instruction would turn into two or vice-versa. Calls to code outside Stunts, such as DOS interrupts are recognised and turned into calls to home made system functions that are analogous to DOS ones. Calls to sound functions are redirected to null functions temporarily. Once the whole thing works, the 32bit assembly program is converted to a C based inline assembler and the functions that have already been translated to C are replaced and the program recompiled in C with inline assembly. Of course, all this work will fail if Stunts does any weird thing like writing on its own code. Data memory regions would also have to be accounted for. A memory map has to be created before making the program to perform this huge operation. Yes, it's tons of work and harder, but maybe, in the end, faster. Still, I understand you... just thinking of it makes me feel like ditching the idea, ha, ha.
Quotebut I was hoping it'd be possible to "automatically" convert assembly.
thats the only way it could be done without introducing to many errors
problem with that is: currently not every offset is a symbol - sometimes only ax+0834 or something, it could happen that
the different 32bit code size changes the offsets etc.
the rest is more or less the ideas that are aorund - but its just a spare time thing
QuoteOf course, all this work will fail if Stunts does any weird thing like writing on its own code.
as far is i know - no self modifying code in stunts
i've attached the lastest asm-source (that gets you to a nearly 100% identical version of the original exe) so you can have a look how complex/time consuming it could be :)
the big problem are also 16bit offsets as function parameters that then get combined with some segements to form a real address - hard to follow that automaticly without semantic knowledge
Side question...
Since I don't have any problems with memory with the game.exe.
Does game.exe still load in real mode memory? Or secretly in extended?
I don't know how to check that..
>Since I don't have any problems with memory with the game.exe.
the "memory problems" are a missinterpretion(of you?) and come only from the buggy Microsoft ExePack packing of the original load.exe and
maybe also from the loader in memory combined game exectuable that is also ExePacked - has nothing to do with not enough free memory
1. load.exe gets loaded by DOS, decompress itself in memory using the ExePack code that is attached in the compressed load.exe
2. load.exe combines some files of the stunts folder into the real game code wich itself is ExePacked (same procedure as in 1)
3. real game code starts
ExePack is a Microsoft program to reduce executable sizes like UPX(https://upx.github.io/) today - its just buggy and some versions relies unnecessary
on very old Hardware behavior that is not given with todays still compatible hardware, it happens when the code is loaded too low, loadfix can sometimes prevent that - but its still a official known Microsoft Bug
game.exe is the original pure game executeable
its just step 3 without any unpacking/loading before
>Does game.exe still load in real mode memory? Or secretly in extended?
real mode memory is not a thing - its called conventional (640k) memory
stunts allocates all available conventional memory (no EMS/XMS is ever used) on start and does the
needed allocation while game runs with its own builtin memory manager
Stunts is itself not very memory demanding
Some brainstorming....
Yeah, in 1990, many games did not use memory beyond the first megabyte even when things like HIMEM.SYS and EMM386.EXE already existed. Now, there are two things as regards conventional memory being reserved by EXE programs. First, when loading a program, DOS would assign one or more memory regions to load it there, depending on the information in the EXE header. But then, at run-time, a program could request more memory dynamically. These dynamic blocks could be resized and freed when the program thought it best. Sometimes, there was enough available conventional memory, but there wasn't any continuous region large enough to provide the requested amount in one block. This is why some old programs report "insufficient memory" when there's still a lot of it. Fragmentation. Another thing was that, as DOS was a single-user operating system, it was not uncommon for a program, after loading, to reserve all available conventional memory for itself, all of it! No matter how much it was going to use. I have no idea if Stunts did any of these two things, but I do know it did use dynamic memory allocation (which shouldn't be a problem) because I had to deal with that when I was working on Vizcacha. Loadfix may have been made for a completely different purpose, but as it changes where the program is going to be loaded, it may have an effect on how much memory the program sees as available and whether it loads stably or not. Again, I really don't know. Then there's also the problem with high memory and UMBs on new machines. As long as Stunts uses only memory assigned by DOS, it should be OK, unless DOS "thinks" the memory can be used and it turns out that physically, there isn't any RAM there.
There is no brainstorming needed: we,ve got the full assembler code and the exe header tells the rest of the story - just one allocate all available conventional memory at start thats it, no EMS or XMS - i've wrote an emulator for the game and know all details 100% ;)
Perfect! I think I should read in more detail and hopefully start helping the project. It's still a lot to do, but one more person helps.
here is a log what stunts is doing on start - its some sort of Dosbox but based on Fake86 (currently XTulator) + logging every DOS API, BIOS, etc. access - this emulator implements only Hardware,BIOS,DOS features stunts needs - not a bit more
there are a few (re)allocs at start
StuntsVM v0.1 (heavily based on Mike Chambers Fake86 v0.13.10.2) (c)2010-2013 Mike Chambers
[A portable, open-source 8086 PC emulator]
Initializing CPU... OK!
Initializing emulated hardware:
- Intel 8253 timer: OK
- Intel 8259 interrupt controller: OK
- Adlib FM music card: OK
OK
Initializing audio stream... OK! (48000 Hz, 100 ms, 4800 sample latency)
8259 status before stunts
nextintr_i8259_state: irr=0x00, imr=0xBC, isr=0x00, icw=0x00,0x13,0x08,0x00,0x09
dos_get_version(call: 0) position: 0x0002D0E4
program_PSP_seg should be: 0x1038
start get_dos_version()
start dos_realloc(new_size_in_paragraphs=0x3932 (bytes: 0x39320 234272)), segment_of_block_to_resize=0x1038)
dos_get_version(call: 1) position: 0x0002D1AA
start get_dos_version()
start dos_get_interrupt_vector(int_num=0x00)
start dos_set_interrupt_vector(int_num=0x00 DS:DX=0x2D0D:0x00B4 (inside_image: TRUE))
result dos_set_interrupt_vector() ok
start ioctl_get_device_info(handle=stdprn)
start ioctl_get_device_info(handle=stdaux)
start ioctl_get_device_info(handle=stderr)
start ioctl_get_device_info(handle=stdout)
start ioctl_get_device_info(handle=stdin)
write86 into vector table RAM[0x00000024]=0xA6 vector_table[0x09][byte: 0] from_image: TRUE
write86 into vector table RAM[0x00000025]=0x1E vector_table[0x09][byte: 1] from_image: TRUE
write86 into vector table RAM[0x00000026]=0xEA vector_table[0x09][byte: 2] from_image: TRUE
write86 into vector table RAM[0x00000027]=0x2E vector_table[0x09][byte: 3] from_image: TRUE
int: 0x09 (keyboard data ready), IDA-file-ofs: 0x00023156
write86 into vector table RAM[0x00000058]=0x85 vector_table[0x16][byte: 0] from_image: TRUE
write86 into vector table RAM[0x00000059]=0x1F vector_table[0x16][byte: 1] from_image: TRUE
write86 into vector table RAM[0x0000005A]=0xEA vector_table[0x16][byte: 2] from_image: TRUE
write86 into vector table RAM[0x0000005B]=0x2E vector_table[0x16][byte: 3] from_image: TRUE
int: 0x16 (bios keyboard), IDA-file-ofs: 0x00023235
read in BIOS Data Area (BDA) ofs32: 0x00000417, local_offset: 0x00000017 ==> 0x00, IDA-file-ofs: 29398
keyboard_shift_flags_1: 0x00
write in BIOS Data Area (BDA) ofs32: 0x00000417, local_offset: 0x00000017 ==> 0x00, IDA-file-ofs: 29398
dos_get_version(call: 2) position: 0x00031502
start get_dos_version()
start get_current_PSP_address()
start dos_alloc(number_of_paragraphs=0x64 (bytes: 0x640 1600))
start dos_realloc(new_size_in_paragraphs=0x5695 (bytes: 0x56950 354640)), segment_of_block_to_resize=0x496B)
start dos_realloc(new_size_in_paragraphs=0x5695 (bytes: 0x56950 354640)), segment_of_block_to_resize=0x496B)
start video_get_current_mode()
read in BIOS Data Area (BDA) ofs32: 0x00000410, local_offset: 0x00000010 ==> 0x41, IDA-file-ofs: 24E4F
read in BIOS Data Area (BDA) ofs32: 0x00000411, local_offset: 0x00000011 ==> 0x40, IDA-file-ofs: 260AE
equipment_word: 0x4041
read in BIOS Data Area (BDA) ofs32: 0x00000410, local_offset: 0x00000010 ==> 0x41, IDA-file-ofs: 260AE
write in BIOS Data Area (BDA) ofs32: 0x00000410, local_offset: 0x00000010 ==> 0x51, IDA-file-ofs: 260B8
write in BIOS Data Area (BDA) ofs32: 0x00000411, local_offset: 0x00000011 ==> 0x40, IDA-file-ofs: 260B8
start video_set_background_border_color(color=0x00)
start video_set_mode(mode=0x13)
mode 0x13 #1
write in BIOS Data Area (BDA) ofs32: 0x00000449, local_offset: 0x00000049 ==> 0x13, IDA-file-ofs: 260C6
write in BIOS Data Area (BDA) ofs32: 0x0000044A, local_offset: 0x0000004A ==> 0x28, IDA-file-ofs: 260C6
write in BIOS Data Area (BDA) ofs32: 0x0000044B, local_offset: 0x0000004B ==> 0x00, IDA-file-ofs: 260C6
write in BIOS Data Area (BDA) ofs32: 0x00000484, local_offset: 0x00000084 ==> 0x18, IDA-file-ofs: 260C6
mode 0x13 #2
write86 into vector table RAM[0x00000020]=0x09 vector_table[0x08][byte: 0] from_image: TRUE
write86 into vector table RAM[0x00000021]=0x19 vector_table[0x08][byte: 1] from_image: TRUE
write86 into vector table RAM[0x00000022]=0xEA vector_table[0x08][byte: 2] from_image: TRUE
write86 into vector table RAM[0x00000023]=0x2E vector_table[0x08][byte: 3] from_image: TRUE
int: 0x08 (timer), IDA-file-ofs: 0x00022BB9
start system_reset_pointing_device()
start mouse_reset_driver_and_read_status()
start mouse_set_horizontal_range(min=0, max=638)
start mouse_set_vertical_range(min=0, max=199)
start mouse_define_mickey_pixel_ratio(mickeys_horizontal=16, mickeys_vertical=16)
start dos_set_interrupt_vector(int_num=0x24 DS:DX=0x2EEA:0x093C (inside_image: TRUE))
result dos_set_interrupt_vector() ok
start dos_set_DTA_address(DS:DX=0x3BBF:0x406A (inside_image: TRUE, of32: 0x0003FC5A, IDA-fofs: 0x3206A))
start dos_find_first(attributes=0x6(hidden,system), file_spec="sdmain.PVS")
result dos_find_first
attribute: archive
time: 0x3CF6 07:39:44
date: 0x4703 03.08.2015
size: 1176 0x498
name: SDMAIN.PVS
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="sdmain.PVS")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_read_file(handle=0x0005, bytes=4, buffer=3BBF:C830)
result dos_read_file(error=0x0, wanted_bytes=4, number_of_bytes_actually_read=4, data={...})
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="sdmain.PVS")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_seek_file(handle=0x0005, origin_of_move=end, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=1176)
start dos_seek_file(handle=0x0005, origin_of_move=start, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=0)
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="sdmain.PVS")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_read_file(handle=0x0005, bytes=16384, buffer=4992:0)
result dos_read_file(error=0x0, wanted_bytes=16384, number_of_bytes_actually_read=1176, data={...})
start dos_close_file(handle=0x0005)
start video_set_block_of_DAC_registers(start_color_register=0x0000, numbers_of_registers_to_set=256)
set block of dac registers
start dos_get_interrupt_vector(int_num=0x00)
start dos_set_interrupt_vector(int_num=0x00 DS:DX=0x1A24:0x0109 (inside_image: TRUE))
result dos_set_interrupt_vector() ok
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="main.res")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_seek_file(handle=0x0005, origin_of_move=end, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=1504)
start dos_seek_file(handle=0x0005, origin_of_move=start, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=0)
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="main.res")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_read_file(handle=0x0005, bytes=16384, buffer=498F:0)
result dos_read_file(error=0x0, wanted_bytes=16384, number_of_bytes_actually_read=1504, data={...})
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="fontdef.fnt")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_seek_file(handle=0x0005, origin_of_move=end, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=1837)
start dos_seek_file(handle=0x0005, origin_of_move=start, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=0)
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="fontdef.fnt")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_read_file(handle=0x0005, bytes=16384, buffer=49ED:0)
result dos_read_file(error=0x0, wanted_bytes=16384, number_of_bytes_actually_read=1837, data={...})
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="fontn.fnt")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_seek_file(handle=0x0005, origin_of_move=end, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=1443)
start dos_seek_file(handle=0x0005, origin_of_move=start, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=0)
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="fontn.fnt")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_read_file(handle=0x0005, bytes=16384, buffer=4A60:0)
result dos_read_file(error=0x0, wanted_bytes=16384, number_of_bytes_actually_read=1443, data={...})
start dos_close_file(handle=0x0005)
start dos_set_DTA_address(DS:DX=0x3BBF:0x406A (inside_image: TRUE, of32: 0x0003FC5A, IDA-fofs: 0x3206A))
start dos_find_first(attributes=0x6(hidden,system), file_spec="sdtitl.*")
result dos_find_first
attribute: archive
time: 0x3CF6 07:39:44
date: 0x4703 03.08.2015
size: 9984 0x2700
name: SDTITL.PVS
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="DEFAULT.trk")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_read_file(handle=0x0005, bytes=16384, buffer=4D46:1C94)
result dos_read_file(error=0x0, wanted_bytes=16384, number_of_bytes_actually_read=1802, data={...})
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="pcskidms.vce")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_seek_file(handle=0x0005, origin_of_move=end, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=1232)
start dos_seek_file(handle=0x0005, origin_of_move=start, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=0)
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="pcskidms.vce")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_read_file(handle=0x0005, bytes=16384, buffer=5406:0)
result dos_read_file(error=0x0, wanted_bytes=16384, number_of_bytes_actually_read=1232, data={...})
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="pcskidtitl.kms")
result dos_open_file(error=0x2, file_handle=<ERROR>)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="pcskidtitl.Pkm")
result dos_open_file(error=0x2, file_handle=<ERROR>)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="geskidtitl.kms")
result dos_open_file(error=0x2, file_handle=<ERROR>)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="geskidtitl.Pkm")
result dos_open_file(error=0x2, file_handle=<ERROR>)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="skidtitl.kms")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_seek_file(handle=0x0005, origin_of_move=end, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=2590)
start dos_seek_file(handle=0x0005, origin_of_move=start, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=0)
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="skidtitl.kms")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_read_file(handle=0x0005, bytes=16384, buffer=5453:0)
result dos_read_file(error=0x0, wanted_bytes=16384, number_of_bytes_actually_read=2590, data={...})
start dos_close_file(handle=0x0005)
start dos_set_DTA_address(DS:DX=0x3BBF:0x406A (inside_image: TRUE, of32: 0x0003FC5A, IDA-fofs: 0x3206A))
start dos_find_first(attributes=0x6(hidden,system), file_spec="sdtitl.PVS")
result dos_find_first
attribute: archive
time: 0x3CF6 07:39:44
date: 0x4703 03.08.2015
size: 9984 0x2700
name: SDTITL.PVS
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="sdtitl.PVS")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_read_file(handle=0x0005, bytes=4, buffer=3BBF:CB5E)
result dos_read_file(error=0x0, wanted_bytes=4, number_of_bytes_actually_read=4, data={...})
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="sdtitl.PVS")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_seek_file(handle=0x0005, origin_of_move=end, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=9984)
start dos_seek_file(handle=0x0005, origin_of_move=start, signed_offset_from_origin=0 0x0)
result dos_seek_file(error=0x0, new_position=0)
start dos_close_file(handle=0x0005)
start dos_open_file access_mode=read_only, sharing_mode=compatibility_mode filename="sdtitl.PVS")
result dos_open_file(error=0x0, file_handle=0x0005)
start dos_read_file(handle=0x0005, bytes=16384, buffer=6589:0)
result dos_read_file(error=0x0, wanted_bytes=16384, number_of_bytes_actually_read=9984, data={...})
start dos_close_file(handle=0x0005)
Quote from: llm on August 05, 2020, 01:19:05 PM
Stunts is itself not very memory demanding
that may be so, and probably is. In the stunts manual not a single word is spent on system requirements or installation. (there was a separate quick reference card however)
in the 4D sports driving manual there is a lot written about it. (see attachment)
that's why in thought memory was more important.
Quotethat may be so, and probably is.
the question is what makes you think that there is a not enough free memory problem?
are we still talking about the ExePack Bugs? what are the exact messages you get?
the on-the-fly load.exe unpacked game code does need "some" bytes more space than the game.exe but not even kilobytes
I only know I got a not enough memory message if I managed to load with loadfix.
Even with as much as possible set as load high or in umb.
That in combination with the manual stating you need 640k to run the game gave me that impression.
With game.exe on a fresh DOS, not optimized at all it loaded first time.
That made me think there is a difference.
That was the whole observation that my question was based on.
So I don't know. Maybe it's an exepack thing. Maybe the unpacking process needs temporary extra memory. Maybe it is nothing but my poor understanding of DOS mechanics.
But thank you for taking it seriously.
loadfix just consumes lower conventional memory - per default 64k (according to https://www.dosbox.com/wiki/LOADFIX)
64k is a decent amount of memory - could reduce the available memory too much
and loadfix is (my understanding) is used to avoid the ExePack Bug by no allowing load.exe to be in a memory area were the Bug occures - because loadfix claims this space before
Kommandline to reproduce? Exact message?
Yes, I too had the not-enough-memory message when using loadfix. Of course, that is because of loadfix and not because of Stunts requiring a lot of memory. Now, when loadfix is not loaded, FreeDOS on new machines is unable to load Stunts without a crash or a "packed file is corrupt" error. This makes me think, personally, of a memory fragmentation + physical memory geometry problem. It's not that Stunts really consumes much conventional memory, but FreeDOS probably assumes it can use lower memory in a way it can't because the BIOS is not providing the blocks that were common on older computers (still, the lower 640K should be OK). Then, I imagine something like this happening:
- Stunts asks DOS to allocate a block
- DOS says "uhm, this block looks free enough" and tells Stunts it can use it, but it turns out there's no actual RAM there because of the BIOS
- Stunts opens a packed file and tries to load it there
- If an expanded memory manager is loaded, the CPU is in Virtual86 mode and this access generates an exception followed by a crash
- If no expanded memory manager is loaded, the CPU just ignores the accesses and Stunts believes the file data was copied there, but no
- When Stunts gets back to the memory and tries to unpack the file in RAM, the data is random (maybe all 255s) so it's not valid. Stunts then returns a "packed file is corrupt" message and returns to DOS
If all this assumption is right, the solution would be to examine the memory geometry and load some TSR that would mark the non-working memory blocks as unavailable before loading Stunts. DOS defines memory blocks at the beginning of each and not in an index list somewhere else, so there's a chance that this is not possible.
Sorry Cas but its a well official know and described bug with ExePack, as stated several times here in this topic with screenshots and description links (http://www.os2museum.com/wp/exepack-and-the-a20-gate/), you just need to read some of the posts before getting in full-blown-assumption mode ;) and some of your assumptios are just technical not correct, DOS oder FreeDOS will never try to use BIOS claimed memory, its not "a" packed file, its stunts itself, its a bug in the ExePacker stub that relies on Gate A20 state, there is no need for a TSR to examing the problem and even if we were not aware of the ExePack bug, reading the asm code would be better to understand the correlation that results in this message
Yeah, sorry... I was just describing my train of thought when I got that message
Ive read it several times on the internet, loadfix was developed by microsoft to keep programs out of the low 64k memory area were this silly ExePack Bug can happen (with a few versions of ExePack), there seems to be no other use scenario for loadfix then preventing this microsoft bug: this official microsoft bug report from around ~2000 explains it and gives information how to use loadfix to prevent the problem (https://jeffpar.github.io/kbarchive/kb/072/Q72360/)
the ExePack Bug and the introduction of loadfix in MS DOS 5 is not a coincidence - its the official fix for the bug on newer hardware
@Daniel3D due to the nature of stunts to allocate all available conventional memory the only changes to find out what stunts memory needs really are
would be some sort of TSR that allocates a given amount of memory before loading game.exe - until it shows the error
or try to reduce the memory by 64k with loadfix on game.exe (does that also give the out of memory message?)
UPDATE: dosbox's loadfix (https://www.dosbox.com/wiki/LOADFIX) allows permanent reduction of the conventional memory
"mem" shows me 633kb free conventional memory
"loadfix -100" reduces that down to 532kb memory
game.exe still can start the race
if i reduce the memory further the game will error with out of memory while loading the race
"loadfix -f" deallocate the used ram
i don't think that the real DOS got the feature to define the amount of kbs or free the memory - but i don't know
that means stunts MCGA needs at least ~532kb free ram for be usable with the first track - could be more with others - and still no used of extended/expanded memory - i know that for sure because my emulator did not implement the expanded/extendende memory interface and the game runs still
so at least ~532kb(for the game) + 64k (for loadfix itself) +- some bytes = ~600-610KB at least
are the needed free memory for stunts using stunts.com/load.exe and only ~532 when using game.exe
That is actually fully understandable. 8)
Except for the part directed @me ::)
That explains it all.
About the stunts emulator you made. I read about it on the forum. But can't seem to download it.
But I am curious. Can you send me a link?
Need to compile it first, but yes no problem
It works, is very small but sadly Fake86 - the emulator i based on got some emulation problems that give sometimes gfx glitches and replay missbehavior, my hope is that the successor Xtulator will fix these: issue with comparison video: https://github.com/mikechambers84/XTulator/issues/4#issuecomment-659561467
here it is: x86 Build with VS2017 under Win7 - could need some vcredist (https://support.microsoft.com/de-de/help/2977003/the-latest-supported-visual-c-downloads)
just copy into your stunts folder
Wow, thanks.
I didn't expect it so quickly 8)
Edit:
needed some vcredist indeed.
Runs fine in the beginning.. Love how nicely it starts. But after 46 seconds racing it freezes en crashes to desktop... :-\
(may be a W10 issue?)
but i love it. I'm dyslectic and dropt DOS like a brick when windows 1.1 came available to me when i was 10 or so.
Have grown up with windows, so i tent to shy away form command line interfaces for regular use.
(can't get a grip on linux, i keep breaking it)
EDIT 2:
in compatibility mode i could finish the race but CTD in evaluation menu...
Both times about 1:30 minutes after start of the game...
just tested 2 times. not enough data for meaningful results...
To hot up here now. wil test later. still love it 8)
i will prepare a XTulator (successor of my emulator base) test-image for you would be nice if you would do some testing
I would love to.
(Maybe time for a new topic? As we are a bit of topic ???)
power-of-topic :)
xtulator stunts: just run start.bat
last post: http://s000.tinyupload.com/index.php?file_id=16239375281510167399
Quote from: Daniel3D on August 08, 2020, 09:46:22 AM
Wow, thanks.
I didn't expect it so quickly 8)
Again... 8)
edit.
it runs and works ok. it needs work obviously but its drivable.
Report if you find other errors :)
Visualy the same glitches as in the previous.
It seems like the rendering of the clouds has the glitch.
The most irritating is the sound. I don't mind the pc speaker sound. But the engine sound while driving is useless. 8)
If you can find a solution for that it's a great bonus.
But I've only done an indy quick lap on default. No other menu touched.
Do you have a document of know issues?
Its not my code, i used the previous version of this emulator for my stuntsvm, that removes the need for a bios,hd-image and dos (im emulating that enough for stunts to work) i hope the xtulator author will fix the still occuring bugs so i can switch my stuntsvm to the xtulator backend: https://github.com/mikechambers84/XTulator, report bugs at github or here
Ok,
been tinkering a bit myself.
replaced game_pc with game_ad.exe and the sound is working fine now.
also no glitches if clouds are turned off..
speed of the emulation is good to. same as dosbox.
is there a way to scale the window??
Xtulator is still in a early stage, sound is not working very good
Scaling is a missing feature
What glichtes are gone if clouds turned off?
Use the captura tool in former post to make simple videos and post them here
Link to the capture tool and free video uploading site is in the xtulator issue for stunts
I have no problems with sound so far. Maybe that is hardware dependent.
Th glitch i der is with the rendering of one type of clouds. The lowest one, the gray shadow is extended to the right side until the screen edge.
Other than that, scaling and mouse locked in but not appearing I have no issues so far.
It's nice to be able to start stunts from my start menu. 8) hehehe.
Additional:: I'll see if that capture thingie works tomorrow.
Sound is completely emulated in software its implementation is just not finished
Would be great to have some descent issue descriptions with small videos
QuoteFreeDOS 1.3 Arrives, First Major Update Since 2016
By Mark Tyson published 5 days ago
Key new features include a bootable live-image CD, and Zip (de)compression as standard.
Bootable USB should be easy now. I hope sound support is good also. I have a mini laptop waiting for a third life..
https://www.tomshardware.com/news/freedos-update-released (https://www.tomshardware.com/news/freedos-update-released)
http://freedos.org/download/ (http://freedos.org/download/)