YesAfter loading the start address into vLR, can't you just RET?
Code: Select all
0x5b, 0x86, 0x06, // Patch segment, 6 bytes at $5b86 0x11, 0x00, 0x02, // LDWI $0200 0x2b, 0x1a, // STW vLR 0xff, // RET 0x00, 0x5b, 0x86, // Execute: run patch first
I don't believe that would work. Loader is a vCPU application, so it uses vPC. Only two small critical parts are native code. Also, any zero-page segment has to be the first in the file. A workaround is then to write 4 bytes into page $80 with the last segment, but that breaks on 64K systems. But maybe I overlook something again.What if the loader writes the start address minus 2 and the start address minus nothing to the vPC and vLR in page 0, and not send the start command. Wouldn't the return from the sys call jump to the start address?
If it works it is entirely accidental, but possibly reliable. The video loop is continuously modifying the sound channel variables at the end of page 1-4, so there is a potential race condition. And letting the vCPU jump to offset 0 in its page will almost certainly cause a small timing glitch on the /HS video signal. Not all VGA monitors will keep sync. The newer ones are quite unforgiving.I worked around this by padding all pages out with zeros, so I guess it would consistently execute harmless code - for me, this gives consistent behaviour on hardware and emulators, but could issues still arise doing this? I've not seen any bad loads doing this yet.
It is in a useless RAM area so it doesn't eat from your real program. I tucked it away behind the load buffer. The entire Loader is running within screen area. The 3 lines below the "Ready to load" text are:The patching method is a bit of a shame as memory is already very limited, but I guess it's just a few bytes
- Activity indicator (red for mismatched checksum, green for good checksum, white as some kind of cursor)
- vCPU code for the Loader's inner loop
- 60 byte buffer