Launching FDISK+FORMAT direct from boot sequence

Another little job done tonight: Fixing running the FDISK/FORMAT utility from the Hypervisor.  This has been almost working for quite some time, but not quite.

 The first step has been working for some time, which is to watch for the user pressing the SPACE bar repeatedly during boot.  This interrupts the normal boot sequence and displays the list of utilities compiled into the bitstream.  These utilities hide in the top 30KB of colour RAM, where no C64 or C65 program knows how to touch, and are pre-initialised in the FPGA bitstream, so that the RAM in this location "just happens" to have these programs there.

 

 

What was not working was actually running the FDISK program. This was because I had written it using CC65, which does a JSR $FFD2 to set lower-case character set in its entry routine. However, when running in the Hypervisor, there is no ROM present. To solve this, the boot ROM now writes an RTS instruction at $2FFD2, so that a JSR to $FFD2 will safely do nothing and return.

That got the FDISK utility running, and after a bit of mucking about with character sets (there is only the partial Hypervisor character set available), and various other little fixes, the FDISK utility now happily starts, and tries to probe your SD card:

 Note the friendly warning message: This is an improvement from before, when it would just go right ahead and repartition and reformat your SD card without asking, on the assumption that if you ran FDISK on the MEGA65, it was to get your SD card working, not for any other purpose. It now politely asks you to type the two words DELETE EVERYTHING in capitals before it will proceed.  If you get it wrong, for example, type it in lower case, then it tells you to try again:

 If you get it correct, then it does as promised, completely reformat and repartition your SD card:

This process is quite fast, taking only a few seconds to zero out the important parts of the disk and put the half-dozen or so correct sectors in.

What is not immediately obvious here, is that the keyboard input is using the new hardware-accelerated keyboard input: Reading ASCII decoded keys, including all modifier key effects, is as simple as reading $D610 to peek at the next character, and then writing anything back to $D610 to pop the key from the queue.