BIT2CORE: bit2core's conversion differs slightly from M65Connect's conversion about mega65-tools

[gurcei]

Oh, one observation of interest on "megaflash.c" is that there are two copies of it:

1. mega65-core:src/utilities/megaflash.c

• This version has more git history in it (ranging from 26/01/2020 to 09/08/2020)
• it also has the 8MB slot logic in it

2. mega65-tools:src/utilities/megaflash.c

• only has a single commit on it (16/05/2020 - 'import lots of other utilities and programmes')
• this just has the older 4MB-only logic in it

Ah ok, so it looks like how this came about might be:

• Around 16/05/2020, there was an intent to bulk-move the home of various tools from mega65-core into mega65-tools
• Perhaps megaflash.c ended up being an item that actually needed to stay within the mega65-core repo though

So as the true home seems to be in mega65-core, I'm figuring it's ok to delete the older copy in mega65-tools.

[gurcei]

Some other obs from this Discord thread:

• https://discord.com/channels/719326990221574164/782757495180361778/804580052779925514

• In the initial commit of mega65-core:src/utilities/megaflash.c, the commit message hints that the tool was a fork of mega65-core:src/utilities/qspitest.c, so there could be some clues in there.

• Inside megaflash.c - program_page(), I found perhaps a historical reason that those 120 bytes were skipped.

https://media.discordapp.net/attachments/782757495180361778/804580052313309224/unknown.png

So:

• 0x0000 to 0x0FFF = core header
• 0x1000 to 0x1077 = 120-byte bitstream header (non-0xff content)
• 0x1078 to 0x1197 = bitstream header padding? (0xff content)
• 0x1198 and onwards = bitstream data
  So this 120-byte skip conveniently skips over the non-0xff content of the bitstream header.

Then, looking inside megaflash.c - program_page(), I notice this historic code:

https://media.discordapp.net/attachments/782757495180361778/804581624117067786/unknown.png

This code has been switched off thanks to the #if 0, but I can see it was an early attempt to skip over the 0xff padding after the bitstream header.
So it's possible that the earlier bit2core implementation skipped those 120 bytes in order for this 0xff-padding-skipping logic within megaflash.c to take place.
So since the #if 0 is in-place, maybe it's a sign that this technique was put aside and the 120-byte skipping is not necessary anymore, and perhaps the M65Connect way of converting to .cor (including those 120 bytes) is the 'latest' way to do it.

[gurcei]

Just some final obs I shared on Discord this evening:

So for tonight then, I'll try just simply flash both styles onto my devkit, and get a solid confirmation if both styles work, or just one.
GurceToday at 22:01
Well, interestingly, erm, both work :slight_smile:
So, I'll probably leave the investigation at that then, don't think it's worth hunting it down any deeper for now. I'll just settle to change bit2core to behave in the same manner as M65Connect, and keep those 120 bytes (and not skip them).
rdpeakeToday at 22:05
with that - i suspect the fpga is capable of ignoring the heading and looks for some sort of 'marker' to actually start reading from
GurceToday at 22:05
Yep, that sounds like a reasonable assumption, I personally don't want to burn the energy to confirm it though, happy for others to, if they're keen :slight_smile:
rdpeakeToday at 22:06
yeah, if both work - i don't see a need to burn that energy either (as its also probably documented somewhere anyway) and leave it until an error shows up if it ever does
GurceToday at 22:07
Yeah, who knows, perhaps if the fpga core gets close to full one day and those shaved 120 bytes make all the difference between something working and not working, we can come back and take a closer look :slight_smile:

[gurcei]

So, for final actions on this card:

• Remove the old copy of "megaflash.c" from mega65-tools
• Remove the 120-byte skip logic inside "bit2core.c"