Jump to content
IGNORED

MaxFlash Studio XEX incompatibilities.


Wilheim
 Share

Recommended Posts

Hi, all!

 

I was trying to make a cartridge image with MaxFlash Studio, and I found that some XEX doesn't load fine. Most notably:

 

Solo Flight

F-15 Strike Eagle

 

I tried with different loader configurations and XEX versions, but none of them worked. The strangest thing is that those games load fine with my custom XEX loader. The problem is that I need the MaxFlash Studio loader because I need to add some ATR images on it.

 

Does anyone know what is happening?

 

Cheers!

 

 

Link to comment
Share on other sites

You would have to attach the binary load files here to get any help. First, you can try different .xex of the respective game (atarionline.pl) hosts several different .xex files for the F-15.

Why the loading fails? The .xex files can overwrite memory the loader uses during the binary load process (either a segment overlaps with the binary loader, or a code executed via INIT vector corrupts the loader)

  • Like 1
Link to comment
Share on other sites

Here's the versions I used.

 

As you said, I thought at the beginning that there was an overwriting in the loader routine or in the INITAD. The MaxFlash Studio uses by default $100-$1EE memory addresses in its loader, giving some issues in the loading process in some XEX files. I changed the address to $700-$7EE to fix this. That zone is commonly used by XEX disk loaders (quickmenu, for example).

 

The problem is that the XEX executes, but for some reason it doesn't play. In Solo Flight, it doesn't show the options. And in F-15, it doesn't display the main screen.

 

Any thoughts?

Solo Flight (1983)(MicroProse)(US).xex

F-15 Strike Eagle (198x)(MicroProse).xex

Link to comment
Share on other sites

For F15 Strike Eagle, it appears to be ok to place the binary loader to 3072 ($0C00...)

Placing the loader to addresses 1792-2560 doesn't seem to work. The file is compressed and who knows where the decompression buffer is.

The same address should work for Solo Flight.

Edited by baktra
  • Like 1
Link to comment
Share on other sites

There is another variable in the game - EXE Loader Local Variable Space. Page 0 locations used by the binary loader.

I suggest changing this value to $80. Or to higher values when $80 fails. So $0C00 for the loader, and $80 for the local variable space.

 

As the binary load file is compressed, it is almost sure the decompression routine uses some page 0 memory locations. And if both the binary loader and the decompression routine happen to use the same addresses, bad things happen.

 

IMHO, the cartridge authoring tool has really strange defaults. I believe the best default binary loader location is 2048 as 1792-2047 is typically used for sector buffer or as a temporary space for decompression. But as they state in their documentation, the binary load files can do anything during the loading process.

 

By the way, does the Ridiculous Reality game work with that binary loader?

  • Like 1
Link to comment
Share on other sites

There is another variable in the game - EXE Loader Local Variable Space. Page 0 locations used by the binary loader.

I suggest changing this value to $80. Or to higher values when $80 fails. So $0C00 for the loader, and $80 for the local variable space.

I noticed that the inflater (presumably) runs code at $80 but I don't think this happens until after all disk activity is complete. I didn't notice anything untoward being changed by either title in ZP prior to that. Decompression appears not to happen until the last segment is loaded. In any case, the SIDE loader uses no ZP aside from those locations designated for PBI usage, which might explain why I saw no issues (none with Ridiculous Reality, either).

Edited by flashjazzcat
  • Like 1
Link to comment
Share on other sites

I noticed that the inflater (presumably) runs code at $80 but I don't think this happens until after all disk activity is complete. I didn't notice anything untoward being changed by either title in ZP prior to that. Decompression appears not to happen until the last segment is loaded. In any case, the SIDE loader uses no ZP aside from those locations designated for PBI usage, which might explain why I saw no issues (none with Ridiculous Reality, either).

Quite right, no code executed via the INIT vectors changes ZP. It places some data to the "RAM under ROM", but that shouldn't affect the binary loader either.

Link to comment
Share on other sites

Good point! Solved! The problem is because these Microprose titles need an E: channel opened. That's why it didn't work on MaxFlash Studio, but it worked in my custom loader.

 

Thank you all!!

 

Great, problem solved. I didn't consider this, as I expected E: device opened by default.

Link to comment
Share on other sites

 

Great, problem solved. I didn't consider this, as I expected E: device opened by default.

Neither did I. I didnt realized that those games used it. To figure it out. I added an small routine that closes all channels before starting the game. Then the game started to fail with every loading routine. Bingo! I said, i was able to reproduce the error!

 

Regards!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...