Closed ZeroByteOrg closed 2 years ago
I personally prefer a new BLOAD command reather than obfuscating the existing LOAD command more. Then we can leave out the 'sa' parameter altogether as well.
either/or - I think BLOAD makes sense as it implies headerless and doesn't require the user to know about bits and masks and such. If implemented, I wonder how hard it would be to make legacy LOAD mask off the headerless bit to further enforce the feature, save users from themselves....
I think a better name might be LOADBIN or BINLOAD as those names are a tad more descriptive than BLOAD. Thinking of a way to hook the existing LOAD routine from such an "auxilliary call" such that the "headerless bit" is preserved in all cases...
I decided to just go ahead and make the commands be B+[command] for consistency. I have provided BASIC commands BLOAD, BVLOAD, and BVERIFY See the comments on PR #312 for a couple of bugs in headerless load that I found while testing this PR.
Currently, LOAD command does not properly expose the new "headerless load" functionality. Currently, the command takes two forms: LOAD "FILE",device[,sa] LOAD "FILE",device,bank,address
The first form behaves as: if (sa & 1) then "use PRG header as load-to address" else "load to $801" If the user specifies an SA with bit 1 set, headerless mode is engaged. If sa & 3 is true, then the expected-but-strange behavior is to interpret the first two bytes as a PRG header and load the file to that address, but retain the first 2 bytes. This should probably be an ILLEGAL QUANTITY ERROR instead? (load with SA=2 seems useful if not often - so that should just work as-is)
I propose that the second form above should also get the optional [,sa] argument supported: LOAD "FILE",device,bank,address[,sa] to give access to headerless load into specified address, which makes much more sense.