r39 patched Kernal to fix LOAD into HiRAM functionality

[ZeroByte]

@desertfish found another bug where a full-page copy would misdirect byte 0 when destination address is not page aligned and bank wrap occurs. His test bed caught this on loads to $A002, but it would have happened on any non-page-aligned block copy of 256 bytes. Fortunately I was able to save some other bytes and this patch only added a few more net bytes in size.

I’ve patched this and will update the attached image shortly.

@Edmond D I do want to make code that behaves as advertised. A LOAD that allows you to bulldoze the stack is one thing, but a low-level routine that just glitches in certain cases is much less acceptable. In the former case, you can at least look at the file size beforehand and throw an error before calling LOAD. But the latter is something you'd have no control over from the outside.

And as @Scott Robison points out, there's no way to pre-check down to the last byte whether a read into $9E01 or not, but there is a possible way to do it. The macptr routine accepts .A=num_bytes. If .A=0 then the device decides how many. fat32_read limits to 256 bytes. I would have to go re-read the code with a non-zero amount in mind to see what would happen if an arbitrary amount reached fat32_read, but in theory, LOAD could see that it's in page 9E and then request only enough bytes to fill the page. If the return value is "still loading" then throw error.

I agree that this might make more sense with a "safe load" frontend than to encumber the primary load function with this extra overhead.

The changes to fat32.s were necessary for bank ram loading, even if I'd implemented a different HLOAD command analogous to VLOAD, but for HI-RAM loading.... the block copy was borked and needs to work that way regardless of the front-end packaging.

[Edmond D]

On 12/5/2021 at 12:26 PM, ZeroByte said:

@Edmond D I do want to make code that behaves as advertised. A LOAD that allows you to bulldoze the stack is one thing, but a low-level routine that just glitches in certain cases is much less acceptable. In the former case, you can at least look at the file size beforehand and throw an error before calling LOAD. But the latter is something you'd have no control over from the outside.

I appreciate that you're improving the system by dealing with the issues that are controllable. Having hidden issues that only occur in certain cases can be problematic. Your later case is certainly understandable and not preventable. 



While not ideal, the documentation around using this load should explain the potential risk that might be encountered in using the command. You've mentioned the documentation is out of date, so if the pull goes through hopefully updating the documentation does as well. That suggest to me that you're doing a complete job in terms of code and documentation, something that I (and hopefully others) fully appreciate. Thanks!

On a side note, I do fully understand the X16 is not an industrial control system platform. Industrial and embedded control space does require certain knowledge, understanding and experience which most people in hobby world don't have. I feel that the PI/Ardunio platforms make real world control systems more accessible, but with more risk due to the lack of the user working in that space. I'd hate to hear of someone hurting themselves (or an X16) because of that gap. Lack of shipping hardware prevents incidents at this time. 

Finally, I'm still on R38. I do hope that R39 (or better) comes out while the team works on the hardware issues. I'm not blocked from enjoying what is available, but I believe that a updated version would serve the community.