Freedos usb stick?

[llm]

>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

[Cas]

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.

[llm]

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%

[Cas]

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.

[llm]

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

Code Select Expand

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)

[Daniel3D]

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.

[llm]

that 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

[Daniel3D]

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.

[llm]

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

[llm]

Kommandline to reproduce? Exact message?

[Cas]

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.

[llm]

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

[Cas]

Yeah, sorry... I was just describing my train of thought when I got that message

[llm]

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

[Daniel3D]

That is actually fully understandable. 
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?