Hey Matthew, I am just curious how one would address that 600k... Is it immediately addressable or would it require further FPGA work? Forgive my ignorance here. I am not very familiar with FPGA.
I'm not sure what you are asking when you say "FPGA work". An FPGA is a Field Programmable Gate Array, which is *basically* a chip packed full of hardware logic gates and other digital building-blocks that can be configured via a "bit stream", when power is applied, that describes how to inter-connect the various gates and blocks. This allows the FPGA to "become" whatever hardware circuit is described by the bit-stream.
Typically the FPGA's configuration is SRAM-based, so when you power off the FPGA is loses its configuration. That is why the FPGA needs a flash-EEPROM device to load its bit stream from when it powers up. This is also what makes them "Field Programmable".
The F18A uses an FPGA as the main logic chip since it allowed me to describe the original functionality of the 9918A VDP, plus add the enhancements. This is where the "F", as in FPGA, in F18A comes from. The "18A" is from the 9918A VDP.
So, from the standpoint of needing to do something with the FPGA or its bit stream to support accessing the 600K, nothing needs to be done, the hardware part is ready to go.
From a software standpoint, some routines need to be written. I'd be willing to do the F18A specific parts, but I'm not going to go off and invent the software interface between the 99/4A and F18A. I'd like to get input from people who have much more extensive disk experience on the 99/4A to make some suggestions.
The F18A flash ROM is 1MB (M25P80 for those who want to dig up the datasheet), and the current bit stream and ROM "extras" take up about half of that (or a little less). Technically there is over 600K available, comfortably 500K. The flash is rated at "more than 100,000 program/erase cycles per sector" and "more than 20 years' data retention".
I'm not sure if some sort of FAT-file-system would be necessary, but being able to grow and shrink file sizes without being wasteful seems like it would be a good thing to do.
Maybe the PAB system could be used? But maybe it is too much a pain in the ass though. To me, simple is better. A "name based" system seems best, with a minimal set of functions: open, close, read, write, seek, delete. You can't seek past the end of the file, and reading/writing always happens at the current offset. You would get either "success" or "disk full" as return values. I'm not sure if directories would be necessary, and I have not thought about how you would get a list of files.
Anyway, that's my hasty take on it. Comments? Suggestions?