MaxFlash Studio XEX incompatibilities.

[Wilheim]

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!

 

 

[baktra]

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)

[Wilheim]

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

[flashjazzcat]

Just tested these in the latest U1MB SIDE loader whose XEX loader resides at $700-$Axx and both ran successfully, so they're not doing anything too out of the ordinary. I wonder if the loader uses some other RAM or fails to initialise something these binaries expect to see?

[baktra]

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 December 8, 2017 by baktra

[Wilheim]

Nope, didn't work neither on $0C00.

 

What can it be? I'm intrigued.

[baktra]

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?

[flashjazzcat]

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 December 8, 2017 by flashjazzcat

[baktra]

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.

[Wilheim]

Ridicoulus Reality works fine using the loader at $700

[FULS]

Try this.

F-15 SoloFlight.zip

These seem to work when the "OPEN E: DEVICE BEFORE STARTING PROGRAM LOAD" option is checked.

[Wilheim]

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!!

[baktra]

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.

[Wilheim]

 

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!

[flashjazzcat]

Aha... good conclusion. I used to offer "Open screen editor" as an option, but now I just open it 100 per cent of the time before loading an XEX.