FDISK and FORMAT utility for the MEGA65

Preparing SD cards for the MEGA65 can be a bit tricky, as the FAT file system implementation in our Kickstart is rather restrictive.

To make life easier, we are creating an FDISK+FORMAT utility that will be in memory on each first power-on (this is one of the nice things about FPGAs -- RAM contents are not random on power on, but we can put what we like in there).  The idea is that if Kickstart fails to find a valid partition and file system, it will launch this utility to give the option to investigate the problem, and to quickly and easily (re-)partition and format their SD card in a manner that is compatible with the MEGA65.

At the moment the utility is functional, but a bit raw. In particular, if you run it, it WILL completely erase and repartition and reformat your SD card WITHOUT EVEN ASKING.  Consider it a proof-of-concept, rather than a finished product.

Nonetheless, it is nice that we have a simplified combined FDISK+FORMAT utility in less than 9KB.

Screenshot of it running in the MEGA65 emulator where I have been developing it:

Real testing on a MEGA65 will have to wait until I get back from my travels or another of the team has the chance to try it out.  I am not sure if the SD card size detection will work on real hardware or not.

Pulling pieces together for the new PCB: Matrix mode, preliminary cartridge support and updated video mode

Progress is continuing towards the new MEGA65 PCBs, and full support for the various connectors and ports.

First, a general improvement thanks to Tim's hard work: The "Matrix Mode" composited overlay of the serial monitor interface is now very nice to use directly from a USB/PS/2 keyboard.  You can now change turn "Matrix Mode" on and off with ALT-TAB, and select the size and position of the overlay with ALT-1,2 or 3 and the cursor keys.  This makes for a much more convenient debug interface, as you don't need to have a separate computer hon hand.  ALT-TAB actually triggers a hypervisor trap, and there is a little snippet of code there that simply toggles the flag for Matrix Mode in the protected hardware configuration register (only accessible from the Hypervisor).

Some photos to show how this looks in reality. Sorry that they are a bit fuzzy, but it is all I had time to grab before flying out this afternoon.

First, full-screen.  Note that the serial monitor is overlaid with transparency, so you can still more or less see what is happening behind.

Pressing ALT-2 makes it middle size, and you can then move it around.  The smaller image dims the background more strongly, to keep the text clear and readable.

Finally, smallest size:

Then separately, I have been working on cartridge support for the new MEGA65 main boards.  However, I don't yet have one here, so I decided to make a fake cartridge as a means of testing that I had the interface correct, while using only the Nexys4 boards I have here.

To do this, I made a cartridge that has pretend IO at $DExx and $DFxx, and maps an 8KB ROM at $8000-$9FFF.  I then used that as the handle for implementing expansion port memory accesses to that, first simulating with GHDL, and then synthesising with Xilinx ISE.

Once I had it generally working, I then updated the memory mapping on the MEGA65 CPU to actually map the expansion IO at $DE00-$DFFF to the expansion port (except when the SD card sector buffer is mapped there -- I forgot it initially, and then wondered why it couldn't mount the SD card any more ...).  I also updated all the memory mapping for the expansion port ROMs.  Most bank-switching cartridges should work okay.  Ultimax mode is also supported, so even some crazier cartridges might work, but there are limitations to the degree of compatibility we are offering. Nothing that does DMA will work, so REUs are a no go, and I'd be really surprised if any freeze cartridges worked.  We might add support for more devices in the future, but for now, most software and game cartridges and some fast-loaders should work without too much trouble.

In the process of implementing this, I also rationalised all of the expansion memory interfaces, so that it is easier to pick which one is active, as the original Nexys4 board, the Nexys4DDR and MEGA65 main boards all have different types.  This means that we should be able to add back support for the PSRAM on the original Nexys4 boards fairly soon.

For testing on the Nexys4DDR board, I plumbed switch 8 (which is also CAPS LOCK for C65 mode) to the /EXROM line on the fake expansion port.  That is, if CAPS LOCK is on, then the cartridge is present, and if CAPS LOCK is off, then the cartridge is "removed", and doesn't map.

This all works quite nicely, and so after a bit of fiddling, I was able to get this display on boot:

The @'s and MEGA65 boot message are there because as soon as Kickstart hands over to the C65 ROM, the cartridge is started.  The missing bottom border is because I was still fixing problems with the video mode at the time, so can be ignored.

For those not familiar with the workings of boot process of the C65, it first starts up running the C64-mode KERNAL.  As on a normal C64, one of the first thing the KERNAL does is look for a cartridge.  This happens on a C65, as well.  As a result, if the cartridge is enabled, we just get the rainbow border that is the tiny program on the fake cartridge I made.

Finally, for the new main boards, we are switching to 1080p and a 150MHz dotclock (down from 192MHz).  A side effect is that the CPU speeds up slightly to 50MHz, which is not a bad thing.  This means that I have had to refactor the video mode framing in the VIC-IV.  This has been more painful than I would have liked, and it still isn't finished. It is temporarily driving 1280x1024 @ 57Hz, which I didn't think was a real mode, but my monitor displays it okay.  When I get a chance, I will figure out the right mode timing, and deal with any remaining VSYNC/HSYNC generation bugs, and move it across to 1080p, which will be a very significant moment, after which the video mode of the M65 should remain fixed, with only the PAL/NTSC 50/60Hz timing difference remaining, which will be run-time selectable, as on the Amiga.  From there on raster timing should be reasonably fixed.  

I also need to merge in Falk's work on fixing bitplanes, and get it synthesising for the MEGA65 main boards, with the real cartridge port plumbed and test that. 

In short, there is a real feeling of progress at the moment, and already some nice outcomes from that.