Proto #2 support in GitHub ROM, Emulator & Documentation

[pzembrod]

4 hours ago, Scott Robison said:

Or you use two bytes for the time being. Read $00 & $9F61, store them in temporaries, set them both to the desired bank so that it works on either version, then restore both.

That's exactly what I'm doing: I'm treating each assumed bank registers separately, storing and restoring each independently of the other one, and setting them both to a desired bank when I want to access that bank. Half of that code is, of course, an elaborate noop, but one of the two halves should get the job done, and the two halves shouldn't get into each others' way.

[Scott Robison]

3 hours ago, pzembrod said:

That's exactly what I'm doing: I'm treating each assumed bank registers separately, storing and restoring each independently of the other one, and setting them both to a desired bank when I want to access that bank. Half of that code is, of course, an elaborate noop, but one of the two halves should get the job done, and the two halves shouldn't get into each others' way.

Good. Sorry if I came off as a know it all or something, I just wanted to be sure you considered the option.

Edited to observe that I lost track of who I originally replied to. pzembrod is agreeing with me. Regardless, I still hope I didn't come off as a know it all, just offering a suggestion to tide people over to support both emulator versions until it is no longer necessary.

[pzembrod]

6 hours ago, Scott Robison said:

Good. Sorry if I came off as a know it all or something, I just wanted to be sure you considered the option.

Hi  Scott, I'm sorry myself if I came across as miffed or something. ?

You had described so precisely the approach I had taken to avoid the pitfall that @ZeroByte correctly pointed out that "That's exactly what I'm doing" jumped into my mind and keyboard. Rereading it, I realize that it has a ring to it that I hadn't intended.

Thanks again to both of you, this was very helpful input.

[pzembrod]

Update: I've uploaded version 3.9.3 of VolkfsForth that applies the above and should work in R39 and proto2 just as well as in R38 and proto1.

An updated version of cc64 will follow soon.

[Scott Robison]

On 4/13/2021 at 1:38 AM, pzembrod said:

Hi  Scott, I'm sorry myself if I came across as miffed or something. ?



You had described so precisely the approach I had taken to avoid the pitfall that @ZeroByte correctly pointed out that "That's exactly what I'm doing" jumped into my mind and keyboard. Rereading it, I realize that it has a ring to it that I hadn't intended.



Thanks again to both of you, this was very helpful input.

I didn't think anything bad, I just felt my comment was so "obvious" that I didn't want anyone to think I was talking down to them. I'm glad we both understood the other. ?

[pzembrod]

Update: I've uploaded version v0.9 of cc64 that is based on VolkfsForth 3.9.3 and should work in R39 and proto2 just as well as in R38 and proto1.

[svenvandevelde]

On 3/27/2021 at 7:16 PM, ZeroByte said:

This is not a feature request or a complaint about functionality - I would just like to know so that I can plan accordingly in my projects - is there any intention for the functionality of the Kernal LOAD/SAVE routines to have a mode where the first 2 bytes of a file are not skipped when loading into RAM/VERA/HIRAM? I'm not speaking to the emulator's intercepts of these functions but the actual Kernal ones. If this has been asked/answered already, then I apologize, but there are a few threads here going over the various behaviors of kernal LOAD vs Emu LOAD etc. The reason I ask is that a couple of my projects are intended to work with files that aren't necessarily crafted for the X16, so if the Kernal load will always either use the first two bytes of a file as the load address, or skip them when using a user-supplied load address, that means I should definitely be crafting my own load routines such that I keep them handy for reuse.



Thanks, and keep up the amazing work, everyone!

Actually, why isn't there a load routine that doesn't need these 2 bytes at all. It would be useful to have a load routine that loads files without 2 header bytes. 

[Elektron72]

1 hour ago, svenvandevelde said:

Actually, why isn't there a load routine that doesn't need these 2 bytes at all. It would be useful to have a load routine that loads files without 2 header bytes. 

I completely agree. It's especially important because the kernal load routine can, in many cases, be much faster than a user-written routine. This is because LOAD does not usually use CHRIN; it instead uses a much faster block-loading routine. I submitted an issue about this in the x16-rom repo two weeks ago; hopefully when development resumes on the ROM, this feature will be added.

[ZeroByte]

1 hour ago, Elektron72 said:

 I submitted an issue about this in the x16-rom repo two weeks ago; hopefully when development resumes on the ROM, this feature will be added.

It seems to me that the easiest way to support this is to extend the current feature used to distinguish between regular load and vload.

When you call the LOAD routine, you normally send it a flag (0 = load, 1 = verify, 2,3 = vload into bank0/bank1). Why not make it where flag value 4 = load, and treat the first 2 bytes as file data, not PRG header info.

[Elektron72]

35 minutes ago, ZeroByte said:

It seems to me that the easiest way to support this is to extend the current feature used to distinguish between regular load and vload.



When you call the LOAD routine, you normally send it a flag (0 = load, 1 = verify, 2,3 = vload into bank0/bank1). Why not make it where flag value 4 = load, and treat the first 2 bytes as file data, not PRG header info.

Personally, I think it would make more sense to do this using the secondary address, which is already used to tell the load routine whether to ignore the header (SA = 0) or to load to the location it specifies (SA = 1). This would allow a headerless file to be loaded to VRAM without having to add additional flags.