SofaRun v2.0 bug report thread

Champion (398)

03-01-2016, 14:41

I have an issue with running Illusion City from Sofarun. When I run it from Sofarun I get the menu where I can choose MIDI or FM MUSIC. When I choose FM Music all is fine and the opening starts to play with FM Music. When I choose MIDI however the system hangs and I see a line with some colors in the screen. The CAPS keeps burning and the system hangs. But: When I load the disk through the megaflashrom method of using NEXT_DSK.DAT, suddenly everything works ok.

So the issue is specifically with choosing MIDI in combination with using Sofarun.

Any insights on what goes wrong here?

Por mfeingol

Champion (294)

03-01-2016, 21:43

Louthrax:

Thanks very much for your reply.

Louthrax wrote:

turboR machines are using the internal RAM as "main RAM" by default (as opposed to other MSXs which are using the biggest RAM slot).

Ah, that makes sense, thanks. Interesting that this is a scenario where 256kB of RAM isn't quite enough! But I found two workarounds for that: (1) use the "4" key to choose the external mapper, as you mentioned, and (2) run the romturbo tool just after booting, which switches to R800 ROM mode and leaves 144kB free. The former appears to be incompatible with map2.com (which is in my autoexec.bat) so the latter is what I'll use.

I wonder if that's something SofaRun might be able to do? Conceivably it could detect the "ST scenario" where the user wants GM2 with 256kB and DRAM mode, and then it could switch to R800 ROM mode and prevent the user from selecting DRAM mode in the game menu. It might not be entirely worth the effort, but it would help ST users and it might reduce your support load. :-)

Quote:

About the 1st issue, I have not been able to reproduce that here on turboR with 256KB RAM. This one is related to the "total TPA memory" available. How much do you have with your configuration (typing "memory" from Nextor command line)? It should work if you have 54790 bytes. Are you launching SofaRun directly from command line or from another program ? Do you have any "resident" program ?
If you have 54790 bytes free, I might be interested by the ZIP file you're using.

I have 54790 total TPA memory. I'm running sr.com from the command line. My autoexec.bat is fairly straightforward; it runs mapdrv, ralloc and map2. And the issue reproduces without map2.

Here are some sample files:

http://1drv.ms/1R9iF9p

The three zip files contain the same ROM, and were generated by 7zip, the TOSEC archive and Windows Explorer, respectively. All three fail to inflate with the same out of memory error.

Por Louthrax

Prophet (2491)

04-01-2016, 01:09

Quote:

I have 54790 total TPA memory. I'm running sr.com from the command line. My autoexec.bat is fairly straightforward; it runs mapdrv, ralloc and map2. And the issue reproduces without map2.

Your sample ZIP files are all working well here, that beats me for now...

If you want, could you try the following steps:

Comment everything in your AUTOEXEC.BAT file (even SET PATH, etc... everything !).
Re-extract SofaRun 2.4 in a new and empty directory named SR24 at the root of your SD card.
Copy your 3 "City?.zip" files in the SR24 directory.
Remove any cartridge from your MSX except the MFRSCC+ SD.
Reboot
cd SR24
SR
Try to launch City Connection from any City?.zip file.

If that works, you could then re-enable things step by step (uncommenting AUTOEXEC.BAT lines, inserting other cartridges again, etc...), until you get the memory error again, and let me know which step did not work.

I'm mentionning "root of sdcard" above because it might be that a too long file path causes the memory failure (would really be a matter of 20-30 bytes then !).

If nothing of this works, could you try to extract files from you "faulty" ZIP files manually, using SUZ.COM provided with SofaRun 2.4 ? (suz e file.zip *.*)

Por mfeingol

Champion (294)

04-01-2016, 03:39

@louthrax:

I'm happy to say that shortening my path variable (basically by moving my tools directory to the root instead of storing it in a:\dos\tools) seems to have got rid of the unzip errors.

Por mfeingol

Champion (294)

04-01-2016, 06:10

Incidentally, what is the "default" CPU mode in SofaRun?

Por Louthrax

Prophet (2491)

04-01-2016, 09:04

mfeingol wrote:

@louthrax:
I'm happy to say that shortening my path variable (basically by moving my tools directory to the root instead of storing it in a:\dos\tools) seems to have got rid of the unzip errors.

Ah, good news, I'll try to reproduce it here. And this really needs to be fixed, need to free some memory in SUZ.COM. Still not completely understanding why the TPA memory is the same

Por Louthrax

Prophet (2491)

04-01-2016, 08:48

mfeingol wrote:

Incidentally, what is the "default" CPU mode in SofaRun?

That's the "current" CPU mode when SofaRun is launched, would make sense to rename this.

Por Grauw

Ascended (10818)

04-01-2016, 10:17

Louthrax: In VGMPlay, using memory up to 0D180H, it runs out of TPA memory if I launch it from Multi Mente with more than 40 files. Iirc, when I was using memory up to 0D000H earlier it was able to launch with 45 or so files? I think the batch file that MM creates eats away from the top of the TPA. Still, those are still quite a lot of files it can launch with. Does SUZ use a lot more TPA space than that?

Por Louthrax

Prophet (2491)

04-01-2016, 10:56

Hi Grauw,

I don't know exactly how much is allocated totally by SUZ.COM, but it's definitively tight in TPA. It looks like in VGMPlay the extra parameters are stored or copied on stack instead of 080h / 05Ch. Maybe DOS2 does that only if the parameters do not fit in 80h (128 bytes) ? I'll check the way parameters are passed from SofaRun to SUZ.COM (but they should not be so big). I have not observed a change in TPA memory available at SR.COM start depending on the PATH or other environment variables change.

I just noticed something strange: if you add a "memory.com" line in autoexec.bat, it reports 55046 bytes availabe. All further memory.com invocations will report 54790 bytes (256 bytes less).

EDIT: OK, the parameters passed to a .COM file are always copied on stack, so that is reducing the TPA, but the path of the invoked .COM file has no influence (a:\foo\bar\sr.com and a:\sr.com result in same memory available).

Por Grauw

Ascended (10818)

04-01-2016, 13:01

Louthrax: This was in Multi Mente $T mode, so it creates a batch file VGMPLAY FILE1.VGM \r\n VGMPLAY FILE2.VGM etc. to execute VGMPlay several times for a multi-selection. The size of this batch file seems to influence the amount of TPA available.

On the command line I only accept one file at a time, the PARAMETERS environment variable is limited to 255 characters so it would not be able to fit more than 20 or so files. Anyway I didn’t think that affected TPA... seems I was wrong there, as per your observations.

If memory.com is called from a batch file I guess it runs in a slightly different environment than straight from the command line? For one, the batch file needs to be preserved which I guess it does at the top of the TPA as I observed earlier.

DOS2 switches to its own stack when called (also on the ISR btw, slowing it down quite significantly compared to the Basic environment). Maybe COMMAND2.COM sets one of its own as well, accounting for the 256 byte difference?