Build of MCUHacker01's ESP8266 PCXT Emulator

I wound up using the hardware that I built for this for my 8008 emulator, and I really didn't give this project any more thought.  It seemed that the disk would fail randomly after loading a random number of sectors from MS-DOS.

In the meantime, I bought an ESP32-CAM with a bad camera (actually, I discovered that one of the camera voltages was missing). So, I ordered a few more ESP32-CAM's and chalked it up to experience. But, the CAM board has a nifty SPI pseudo-static RAM component  (this version of the ESP32 has a 3.3 volt 8 meg PS-RAM). I wondered if it would be possible to connect it to the ESP8266 and use that for the 1 meg of storage needed for this project instead of the flash cache system, which is quite amazing, but still slow and brutal on the flash.  I built another version of the hardware, removed the PS-RAM from the ESP-32 and connected it up to the SPI on the ESP8266 board. After some datasheet and ESP8266 SPI mystery solving, I got this working.

I'm testing the RAM now. The next steps, which might not happen for a while, would be to modify the original author's cache system to use PS-RAM and not the flash area of the ESP8266. it would be best to use it in "burst" mode, but, one step at a time!

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!