Let me start at the beginning and try to fill in the context!
The NEC PC-6001 has BASIC as its OS with a built-in ROM at 0x0000-0x3fff. This BASIC (non-extended) doesn't know anything about floppy disks as it is intended for cassette use. The system uses an interesting, but odd set of graphics modes where you can specify the number of pages you want at startup. Standard 16K RAM is at 0xc000-0xffff. Page 1 is only a screen that only supports text mode typically at 0xc000-0xc3ff. Page 2 is a much more capable screen that supports text and graphics so its range is larger between 0xe000-0xf9ff. The area at 0xfa00-0xffff is used for internal storage of BASIC's state. It just happens that the graphics do not use the full range of 0xe000-0xffff so in this case there is 0x600 bytes available for basic at the end of it. The system does support more modes with more ram that carve out an entire 8K range for pages 3 and 4 with 0x600 bytes wasted at the top of each one.
Adding 16K more RAM goes into the 0x8000-0xbfff range and moves page 1 from 0xc000-0xc3ff to 0x8000-0x83ff. Page 2 stays where it is, and now pages 3 and 4 which are full graphics pages can be used as well. I am thinking they expected programs to draw a screen in the background while the user is viewing another in the foreground.
The extra memory doesn't really move that much, so the game from the demo, Sub strike, will still load and work from cassette. It is unusual in that is has two tape sections. The first is a basic program that shows instructions, plays a song, and then has a machine language loader it pokes into memory and executes. The machine language loader is short and likely calls a basic function to load data from tape as the tape drive is enabled and it then loads the second tape section into the memory area c400-dfff and executes it. This memory is available in the 16K version (its intended configuration) and it is also available in the 32K version where the game will load and run fine there as well. I have to assume that the game makes calls to the basic rom area (0x0000-0x3fff) because some of the things it does such as displaying text look exactly the same when you do them in basic, so while it is a machine language program, it makes calls to basic functions or parts of basic rom to do things it needs.
I want to load the game from disk. So I've replaced the game's loader with a BLOAD command and at the front of what is BLOADED is the loader which copies it into the correct regions after we no longer need basic to BLOAD anything.
Here is where the complication comes in. Adding the extended BASIC cartridge at 0x4000-0x7fff extends BASIC with many more commands. 95% of them are disk related, so I think of it more as disk basic than extended basic. One of the things it does however now at start up is ask how many files in addition to the how many pages question. Depending on what you answer, it allocates more room for open files. You can answer 0 to this and still load files from disk, so I am thinking this means open files in basic, but not the files you might want to load with basic commands. The issue here is that they decided to use RAM at the end of the user section, which if you select page=2 will be the area below 0xe000. It uses around 400-600 bytes even with 0 files selected and adds another 291 bytes for each file you specify. This is the real issue that extended basic now uses this area which the game also wants to use. My thinking was that the game itself only knows about non-extended basic and should only make calls to it, but likely something else causes regular basic to now also think it needs to use this area. Maybe they set a pointer up in the 0xfa00-0xffff range that even if one calls non-extended basic, it somehow ends up in extended basic code. This is the mystery.
If I specify 0 files, it works. if I specify 2 files, some of the ships graphics are corrupted, which makes sense as I think that area is the ships graphics. If I specify more files like 10, it seems to also work, but I suspect something is still being overwritten and it might fail if played long enough.
The goal was, even if the user specifies 2 files, can I undo or override that? What I've tried to do is copy a section into 0xfa00-0xffff from a "0 files extended configuration" or even a non extended 16K configuration. The way I did that was, copy the game into 0xc400-0xdfff, copy the basic memory into 0xfa00-0xffff, execute the game at 0xc400. The loader does not return to basic at all, just copy the two sections and execute. The game may make basic calls, but they should be non-extended ones and the basic config at 0xfa00 shouldn't know anything about files at 0xdfxx. The result is that when I copy the basic section in, it just restarts asking the how many files question, so basic doesn't like having its memory area copied in!
I am baffled as to why that question "how many files" seems to make a change outside of memory where I can't undo it.