@Rayman said:
Said flash loader could also attempt to load from uSD, if desired, right?
Could be useful if uSD is on different pins and/or has a power switch.
Only if you can figure out how to hot-patch the SD boot code to do that - a full SD driver is probably too heavy for the 1024 bytes of bootloader space - just use the stock flash bootloader and then make the SD loader be the payload of that.
@Rayman said:
4-pin uSD booting should be faster. Wonder if that'd make a difference...
You can make the SD boot A LOT faster as-is by making _BOOT_P2.BIX a tiny stub that sets the clock, patches some stuff in the ROM code and then pivots into a different boot file. I had one like that:
CON _CLKFREQ = 300_000_000
DAT
org 0
asmclk
'' Patch pullup check
wrlong #0,##$fc5b4 ' not sure why it fails but ok
'' Move filename into place
mov $1DC,name+0
mov $1DD,name+1
mov $1DE,name+2
drvh #38 ' Set LED
call #$fc578
drvl #38 ' Clear LED if fail
jmp #$
name byte "LOADTEST","BIX",0
(as seen, this tries to load LOADTEST.BIX - also note the Pin 38 LED, change or remove that if necessary)
Booting a large ~400K executable is a lot faster like that.
You can also compress the executable you're booting. Flexspin and SpinTools have this option built-in, I also made a standalone version
Chip,
I just bumped into something that has changed in recent releases of Pnut. I don't know if this is an explicit change you intended or not. The following compiled and ran when I was compiling with Pnut v46:
Comments
Said flash loader could also attempt to load from uSD, if desired, right?
Could be useful if uSD is on different pins and/or has a power switch.
Also, could maybe do something fancy like look for a backup boot file if the first one is missing...
Also, guess this could allow for long file names and directories...
4-pin uSD booting should be faster. Wonder if that'd make a difference...
Only if you can figure out how to hot-patch the SD boot code to do that - a full SD driver is probably too heavy for the 1024 bytes of bootloader space - just use the stock flash bootloader and then make the SD loader be the payload of that.
You can make the SD boot A LOT faster as-is by making _BOOT_P2.BIX a tiny stub that sets the clock, patches some stuff in the ROM code and then pivots into a different boot file. I had one like that:
CON _CLKFREQ = 300_000_000 DAT org 0 asmclk '' Patch pullup check wrlong #0,##$fc5b4 ' not sure why it fails but ok '' Move filename into place mov $1DC,name+0 mov $1DD,name+1 mov $1DE,name+2 drvh #38 ' Set LED call #$fc578 drvl #38 ' Clear LED if fail jmp #$ name byte "LOADTEST","BIX",0(as seen, this tries to load LOADTEST.BIX - also note the Pin 38 LED, change or remove that if necessary)
Booting a large ~400K executable is a lot faster like that.
You can also compress the executable you're booting. Flexspin and SpinTools have this option built-in, I also made a standalone version
I can confirm this is a "me" problem. I am unsure why it does not boot properly, but I will figure it out. A simple program booted correctly from SD.
Well, it's working as it should now. Maybe the card was flakey, but all is well now.
The good news: No code changes for my code to work with PNUT v51a!
Chip,
I just bumped into something that has changed in recent releases of Pnut. I don't know if this is an explicit change you intended or not. The following compiled and ran when I was compiling with Pnut v46:
But now, with Pnut v51a, I need to add an extra set of brackets as per the following:
Otherwise I basically get a syntax error. Pnut v51a reports a missing comma or closing bracket without the edit.
There is a new version (v52) of PNut.exe at the top of this thread.
v52 - 2025.10.08
New MOVBYTS(), ENDIANL(), ENDIANW() methods.
NEXT/QUIT now allowed to select nesting level of operation.
DEBUG(DEBUG_END_SESSION) now ends DEBUG session and exits PNut if -rd was used on command line.
New DEBUG Display TERM color commands for added simplicity.