So, I continued pounding on this problem, walking away from the imperfect but usable keyboard implementation and going on to the disk. It turned out that the flash wasn't really reading anything. The reason for this was my own ignorance. It is critical that you select an ESP-12E in the Arduino environment when working with a 4MB part (not the general ESP8266); the memory map is quite different. I've done projects with SPIFFS where apparently this problem was taken care of for me in the scripts that drive code building from the ESP8266 Arduino IDE.

Another problem turned up involving me slapping myself on the back over putting the character generator ROM (with graphics) in flash. You cannot do this if you expect to read or write from the onboard user flash area at the same time. Now that the disk flash read actually worked, the screen flashed wildly with each flash read access.

The ESP8266 actually reads instructions (and your stored constant values, strings, and so on) as needed into a ram cache. You can't do any of this in an interrupt that is not already in the ram cache. The nointerrupts () and interrupts() functions don't affect the i2s in the Arduino implementation of the ESP8266 (and even if it did, it would make the screen jumpy and unusable).  There are decorations for functions and variables that guide where the linker puts the components of the program.  I am barely familiar with these. So, I lost the graphics font for now, and so that the screen doesn't get messy, I put a check into the write into video that sets any >0x7F character to a space. The reason that I wanted to do the  above was the RAM situation. As the author released it, the RAM was 75% used. My cobbled together and mysteriously bloated keyboard code, which reads the PS/2 keyboard and converts it into XT code, added about 13-14% to that. This is pushing one's luck on stack/heap crashes, which apparently I've run into. I can get MS-DOS to boot, but it crashes before it hits the A:> prompt.

Areas where I need to look for RAM:

1. The PS/2 code (the "low hanging fruit" parts of this like the lookup tables may already be done)
2 General code cleanup.
3. Do I really need 4K for character video. Every other byte is for color/attributes(?). I have no need for it. But getting that 2k might require some changes to very tricky video code.

I need more RAM for another reason; the original author didn't really finish the "disk write' part of the code. The tricky part here is that we are working with 512 byte sectors in DOS and the flash writes on the ESP8266 are in 4K blocks. So, if you want to write a 512 byte sector, you need to:

1. Grab the appropriate 4K sector that contains the 512 byte PC disk sector in question from flash
and put it in a buffer;
2. Put the new 512 bytes into the appropriate 512K block of the 4K buffer
3. Erase the flash sector
4. Write to the appropriate 4K flash sector with the contents of the 4K modified buffer

So, no matter what, this is taking 4K of RAM minus the 512 sector buffer that the code originally had.

Even if the above worked, this will put a lot of wear and tear on the flash. A lot of writes are likely to be sequential, so I was thinking about a 'flash write cache" and a "disk activity" LED showing me when it is safe to remove the disk.  Basically, any writes to the 4096-byte area would be cached until either a few seconds went by or a write was needed outside of that area. That also will take code, and possibly, a little RAM.

So, this is where it stands. I THINK that this can be done, but just barely, and really just barely by me!