MEGAFLASH Testing
This tutorial explains how you can test development versions of MEGAFLASH.
Testing the flasher will involve… flashing the QSPI flash, and especially flashing slot 0 can result in a broken system! Also software errors in the flasher could break your slot 0!
Then only a JTAG Interface can resurrect your system.
MEGAFLASH is the initial Flash Menu, which you can conjure up during power on, by holding down NO-SCROLL
before switching the device on. You can read about the system startup here.
Test Target
The 782-mflash-lowlevel branch support all official current MEGA65 Platforms (all MEGA65 PCBs and Nexys4DDR). As this was not the case with the Release 0.96 Core (here MEGAFLASH only worked for mega65r3+ PCBs), now we need also tests on the older platforms!
This branch is up to date with the development branch, so it will also work with the latest ROMs. But it is not the goal to test the core yet.
Test Setup
Get your core from MEGA65 Builders 782-mflash-lowlevel page.
There are no significant changes in the SD card files, so if you have release 0.96 or a later development build on your sd card, you don’t need to update them.
Flash the core file included in the archive into a slot of your choice
How to start MEGAFLASH from Slot != 0
Use the startup trick to call up MEGAFLASH from this slot:
enter the initial flash menu (by holding NO-SCROLL)
press the number of the slot where the test core was installed and immediately hold down
NO-SCROLL
! This is also explained in step 4 of the Visual Guide to Flashing Slot 0.you should now see the new MEGAFLASH (
HELP
will show you the version to verify)
How to test using standalone mflash.prg
In the flasher/
subdirectory of the core archive you can also find mflash.prg
. You can test this by sending it to your MEGA65. But only if you have enabled QSPI access.
This is done by switching on dip switch #3. Start your MEGA65 with release 0.96 or later (for example with the core or bitstream in the archive). During startup you will see this screen:
It is an extra precaution so that you don’t leave DIP #3 on forever, as this allows MEGA65 software to access the QSPI Flash. But for testing we want to do that! So press RUN/STOP
to confirm. Afterwards the ROM will drop you into the MONITOR, as the keypress also does that, just exit it by typing X
and pressing RETURN
.
Now either start ethernet mode with SHIFT
+ £
or use your UART/JTAG interface to push mflash.prg
to your system:
m65 -4 -r mega65r6-782mfl-24-fb7e8f0/flasher/mflash.prg
etherload -r -t mega65r6-782mfl-24-fb7e8f0/flasher/mflash.prg
If you also want the “fancy” startup charset (which is different from the normal PETSCII charset), you can grab the OpenROM charset from the core repo and install it using the FREEZERs ROMLOAD function (ROMLOAD can also load alternate charsets), before pushing MEGAFLASH.
Extra stuff new mflash.prg can do
The standalone debug version of MEGAFLASH (mflash.prg
) can do some more things than the integrated flasher can. This is partially because of size restraints, but also to make the integrated version focused on what it should provide to the user.
Items of note:
mflash.prg
includes all flasher low level interfaces and selects them automatically, while the CORE integrated flasher only works on the platform the CORE is intended for. This means you can use anymflash.prg
on any of the platforms, it does not need to come from the correct core archive.when editing a slot, you have extra switches at the top:
MEGA-A will toggle the use of ATTIC RAM (if available it is on by default). Disabling this will make flashing slower, but will not use ATTIC RAM (useful if the CORE has problems with it).
MEGA-B will disabled the hardware acceleration and talk to the QSPI flash via bit bashing. This also is extra slow. The hardware acceleration is done within the CORE, again this can be helpful if the specific CORE does act up in some way.
On startup it will show some debugging information.
What to test?
We don’t want to limit you here! Please test everything that comes to your mind. If we would give you specifics you would just follow our path and sometimes things happen if people do different things than those the developers intend them to do. We are interested in finding those, too!
Obvious things would be looking at core information, flashing cores, and perhaps starting cores.
Reporting
You probably came here from a Discord thread in the platform-testing forum. Please report your results there! Try to film your screen to show us specific problems and also write down the steps that resulted in this. Reproducibility is the key here, as we can’t fix something we can’t reproduce!