Coding a bootblock that still uses the OS

[earok]

I'm not quite ready to ditch the OS yet - I'm still reliant on some libraries that use graphics library and cia resource - but I've rewritten everything in my project to optionally to use trackdisk.device rather than opening DOS. I've managed to get it running from a custom NDOS disk with a custom boot sector, but -

One issue I'm having is the instructions I've seen for writing boot blocks (http://amigadev.elowar.com/read/ADCD.../node015A.html) say to put the destination in A0 and return - that seems to work fine on A1200, but if I try it on A500 it immediately gurus.

If I don't return from there and just directly jump to the game, I'm assuming it's not freeing as much memory as it could (that documentation mentions that returning from the boot sector cleans up the boot graphic etc).

I'm not quite sure what I'm missing, but until I'm ready to completely ditch the OS, I'd definitely love to be able to recover as much memory as possible.

Edit:
I read https://eab.abime.net/showthread.php?t=110841 and it pointed out that registers need to be preserved, so I preserved everything except the stack, D0 and A0, and it does seem to be booting under A500 settings now. I *think* I can take it from here.

[earok]

https://github.com/earok/scorpion-ed...bootsector.asm

This is my bootsector for the current experimental version of Scorpion.

In essence - it uses trackdisk.device to load a ZX0 crunched executable into chipram (along with uncrunched redirects), it uncrunches to slowram, it patches the executable with the redirects, it frees the chipram, and then it returns to the bootstrap with the start of the Blitz program in A0.

There's a few variables near the start of the bootsector that are meant to be useful both for the boot program itself as well as to be used in the Scorpion Engine, such as a pointer to the "file system" structure.

Any suggestions for improvement (short of killing the OS - I do hope to do that in future but there's some complications I need to work around) would honestly be much appreciated.

[Muzza]

I flush the CPU caches before jumping into the code that was just loaded from disk.
Maybe unnecessary, but I'd read somewhere it was the safe thing to do to avoid problems with certain CPUs.

[admiral]

Reading along, I noticed confusing comments and other minor annoyances.

89 --> target is not necessarily slow; you requested any ram; exec will use by priority, typically fast32, fast, slow, chip.

116 --> chipram? you just freed some chipram... your remaining allocation is said ANY ram.

You have a GetVBR routine that seems to be dead code.

And sometimes your registers are in lowercase (a0, d0...), sometimes in uppercase (A0, D0...), which breaks editor search/highlight.