Sunday, July 30, 2017

Revamping Hypervisor boot display, and SPACE to enter utility menu

Now that I have a much easier way to develop the boot ROM for the MEGA65 via the monitor_load command (which I have now pushed up from 230,400bps to 2,000,000bps as I previously discussed), I got inspired to fix the boot display of the MEGA65.

Basically in the past we had a 64x64 area for a 256-colour logo.  This predated the renaming to the MEGA65, and the creation of the wide MEGA65 banner.  As a result the banner was all squished into a tiny space and was almost unreadable and quite ugly.

I'd been meaning for a while to rework the boot ROM  to support a 320 pixel wide banner instead, so that the MEGA65 logo could be properly displayed.   So this is what I have done. I have also gone a step further, and included the MEGA65 logo as preinitialised data in RAM, so that it still shows up, even if you don't have an SD card inserted. 

In the process, because it is now so quick and easy to test new versions of the boot ROM, I also added the option to hold SPACE to enter the utility menu, which serves a similar role to the BIOS menu on old PCs, but will have different utilities.  The main utility planned for now is a combined FDISK+FORMAT utility, to make it easier to setup a new SD card for use in the MEGA65.  The utilities are also stored in pre-initialised memory (in this case the upper 30KB of the 32KB colour RAM), so that you don't need an SD card or anything else for them to be there. 

We have the bulk of the FDISK+FORMAT  utility already written, but need to work out how to get CC65 compiled programs to run on the MEGA65 when there is no C64 ROM yet loaded.

But for now, here is a screen shot of the revamped boot display, looking, I think, much nicer:


Hope you enjoy it.

Wednesday, July 26, 2017

Fast-loading via serial monitor for development (part 2)

I woke up in the middle of the night, so decided to finish the serial monitor fast loader for supporting development.

After a bit of fiddling, it is now possible to compile and use the monitor_load program to:

1. Load a fresh bitstream and completely reset the MEGA65, thus allowing reloading a program regardless of the state of the machine.

2. Wait until the M65 boots to C65 mode.

3. Switch to C64 mode via GO64

4. As soon as it is in C64 mode, load the program you provide on the command line.

Example command line:

tools/monitor_load /dev/ttyUSB1 something.prg nexys4ddr.bit

As the serial monitor interface runs at 230Kbps, this gives a maximum load speed of around 20KB/sec.  At the moment it is probably around 15KB/sec, so quite acceptable.

From typing the command to having the program completely loaded takes about 10.5 seconds, for a 16KB program. That is, about 9.5 seconds is spent loading the bitstream, and waiting for Kickstart to prepare the SD card, load the C65 ROM etc, and get to the C65 prompt.

Monday, July 24, 2017

Fast-loading via serial monitor for development (part 1)

Ages back I started working on a mechanism to allow fast loading of programs via the serial monitor interface, but never finished it.

The idea was to add a command to the serial monitor interface that allowed bulk up-loading of data into memory, and trapping the LOAD vector so that it triggered this mechanism. Funnily enough, trapping LOAD from the serial monitor, working out which program to load, and loading it was the easy part.  This has been in monitor_load.c for some time now.

The hard part was working out why what should have been a very simple memory upload command wasn't working.

Well, I finally figured out the problem with this command last night, and fixed it. The problem, as is so often the case, turned out to be quite simple: There was a safety catch that reset the UART monitor to CPU request strobe whenever a character was received via the UART interface.  This is normally fine, but in bulk upload, this was cancelling the request to write the byte to memory each and every time it was made, resulting in timeout errors in the UART monitor, and a complete lack of loading of the data.

So I fixed this problem, and now I can easily write ranges of memory with arbitrary via the UART interface, at approximately 20KB/sec, since I am running the serial interface at 230,400bps.

The nice thing is that I also worked out how to jtag program the FPGA via the USB lead which also carries the serial monitor interface.  This means that I can write a small shell script that pushes a bitstream into the FPGA and resets the machine, and then waits for someone to try to LOAD something, and then loads what you want at 20KB/sec.  This is a really nice advance for writing software for the MEGA65, as from a cross-compiler you will be able to start the program automatically on a clean machine in just a few seconds. If nothing else, it means that you won't have to fiddle about pulling microSD cards out any more.

You might have noticed I used the future-tense there.  This is because while I now have all the pieces mostly ready, I haven't finished pulling them together.  I hope to do this over the next few evenings, time and energy permitting.

What I have managed to do, however, is to make the serial interface speed run-time selectable from the serial monitor itself.  This means that we don't have to be limited to 20KB/sec, which while nice, would still take a few seconds to load 64KB, and a rather annoying dozen seconds to load 256KB (128KB normal RAM, plus 128KB of "ROM" RAM), when testing larger programs.

There isn't too much to see at the moment, except if you were to try my new bitstream and issue the command:

+32

from the UART monitor interface.  At that point you would see rubbish, until you set your terminal program to 1,000,000bps, i.e., a little better than four times the current speed, and thus allowing something like 80KB - 100KB/sec, which should allow for nice fast loading of all of memory.

So then I tried:

+18

to set it to 2,000,000bps. That seems to work, too, and should allow ~160KB - 200KB/seconds. Even nicer. Sadly +10 didn't work for trying to set it to 3,000,000bps.

Oh well.

Anyway, hopefully I will have an update in a few days showing the ability to fast-load close to 200KB/sec in a development environment, to make writing MEGA65 software more pleasant to do.