Jump to content

Proto #2 support in GitHub ROM, Emulator & Documentation


Recommended Posts

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.

Edited by pzembrod
  • Like 1
Link to comment
Share on other sites

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.

Edited by Scott Robison
  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
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. 🙂

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...
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. 

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Posted (edited)
1 hour ago, Elektron72 said:

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.

The problem with that is that you no longer have the ability to load files with headers to arbitrary addresses. Using the flag we already have for LOAD (like @ZeroByte said) would break fewer things and be more in line with how the original CBM Kernal works.

Edited by SlithyMatt
Link to comment
Share on other sites

Using the SA could work too (depending on what else that field does under the hood).... if values 2 & 3 don't have any defined meaning, then essentially bit1 of the value becomes "0=file contains PRG header, 1=headerless file"

I'm gonna go rifling through the Kernal sources now. (can you tell we're dorks when we do that for fun - lol)

  • Like 1
Link to comment
Share on other sites

Hey folks, dumb question here: 

I was not around for prior Emulator / ROM release updates.    Is there an official place to download r39 to play around with it 

-or- 

a) am I early/premature to be asking in terms of the release cycle?

-or-

b) is the official release source only and one needs to compile everything up?

Hope this is not an "improper question" I just keep seeing posts about people using R39 and I was feeling left out! 

Link to comment
Share on other sites

Posted (edited)

I've been reading the kernal sources, and it looks like it might make more sense to use @Elektron72's suggestion of extending the SA from setlfs.

The first thing the LOAD routine does is take the first two bytes of the file and store them at a location EAL,EAH. Then it checks the SA. If (SA==0) then use the file header address, else overwrite EAL,EAH with the ADDRESS specified as an argument to LOAD.

This seems to be the ideal spot to insert the "headerless file" logic. Maybe it should check SA first:

  • SA=0: load 2 bytes and store as EAL - JMP to main load routine
  • ELSE
    • set EAL from LOAD argument
    • SA < 0 JMP to main load routine
    • load and discard 2 bytes
  • main load routine
  • <stuff>

Edit: Hmmm - not quite perfect, because the current code also does the "file not found" checking when grabbing the header bytes, so if SA<0 means "headerless file load", then just jumps straight to the main load loop, the "file not found" condition would never be checked.

There's really not just a perfect spot to make one simple change to add this w/o duplicating code (or at least my intermediate-level programming skill doesn't come up with a solution yet)

Edited by ZeroByte
Link to comment
Share on other sites

10 minutes ago, Snickers11001001 said:

Is there an official place to download r39 to play around with it

No. R38 is the official version right now. What the community currently refers to as R39 is more accurately described as "the current GitHub snapshot"

So yes, if you want to play with R39, the only way to do that is to download and build it yourself. Once it's officially released, there will be a package for your OS on both the GitHub releases page, and here on the website's downloads page (official software section)

  • Like 1
Link to comment
Share on other sites

Posted (edited)

@ZeroByte One idea I came up with when I was last looking at this issue was to load the header bytes regardless of the secondary address (similar to the current implementation), and if bit 1 of the secondary address is 1, to write them into memory. This would also allow us to have a mode where the header bytes are both a load address and data (not very useful, but it would provide completeness if we are interpreting the SA as a set of binary flags). However, this approach has issues. The first two bytes of the file would need to be stored somewhere independent of the file's load address. Additionally, it would make the part of the routine responsible for copying data into memory more complicated. It is possible that this idea could be useful, but it is likely that someone will come up with a better approach.

EDIT: We might be able to use the stack as temporary storage for the first two bytes of the file, which would resolve one of the major problems with this approach.

Edited by Elektron72
Link to comment
Share on other sites

Posted (edited)
39 minutes ago, Elektron72 said:

The first two bytes of the file would need to be stored somewhere independent of the file's load address

It doesn't appear so to me - one possibility is at the beginning of the main load routine to look back at the SA and if <0, first copy the EAL/EAH bytes to (EAL) 🙂

LDX #0
LDA eal
STA (eal),X

LDA eah
STA (eal),X

The real issue isn't patching the Kernal. It's getting a pull request through. 🙂

Edited by ZeroByte
Link to comment
Share on other sites

7 hours ago, Elektron72 said:

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.

If you test bit2 of that flag, save the result, then clear it, you get headerless load, headerless verify, headerless VRAM bank 1, headerless VRAM bank 2. It's four additional flags from the user side but only one test and one action on the Kernel side.

Though I've forgotten ... what is used to send the RAM bank to load to?

Link to comment
Share on other sites

Posted (edited)

I think it loads to current bank and if it reaches C000, it wraps to A000 and INCs the ram bank.

in other words, you set the desired first bank prior to calling load.

Edited by ZeroByte
Link to comment
Share on other sites

On 5/25/2021 at 2:50 PM, Elektron72 said:

@Snickers11001001 Decided to try cross-compiling R39 for Windows; tell me if this executable works properly.

x16emu.zip 884.29 kB · 4 downloads

I tried it with my "twisted transcendentals" basic demo and it seems to work fine.   Thanks!    That said, seems like its best to hold off on developing specifically for R39 since the repo hasn't been version-frozen yet and an official release may be some time off.   If I were 'inside' the project and official hardware were going to beta-testers soon, I'd delay R39 until the betas were out; and even then, I might call it R39beta or even hold off on another emulator release until after the beta so that feedback from the hardware beta testers could be rolled into the official emulator release.    Any official new release prior to that would generate a flurry of new software development (which means if further tweaks to kernal, etc., were needed due to issues ascertained in beta, then those software writers would be on shifting sand).  It would be entirely reasonable to forestall that in the context of an 'soon' finalization of hardware until the 'official' crowdfund is on with official hardware at which point there could be an emulator release that IS the official hardware, in its 'release' config, or as close as reasonably possible. 

I think its best we all continue to be patient.     

Link to comment
Share on other sites

On 5/25/2021 at 2:48 PM, ZeroByte said:

LDX #0
LDA eal
STA (eal),X

LDA eah
STA (eal),X

1. (zp),X isn't a valid addressing mode. You have (zp),Y and (zp) without indexing on 65C02.
2. You never INX (or really, INY) between each STA instruction, resulting in (eal)+0 to be written with eah instead of eal, and (eal)+1 won't be written at all.

Here's my version (compatible with all 65xx systems):

LDY #0
LDA eal
STA (eal),Y
INY

LDA eah
STA (eal),Y

  • Like 1
Link to comment
Share on other sites

11 hours ago, StinkerB06 said:

1. (zp),X isn't a valid addressing mode. You have (zp),Y and (zp) without indexing on 65C02.
2. You never INX (or really, INY) between each STA instruction, resulting in (eal)+0 to be written with eah instead of eal, and (eal)+1 won't be written at all.

Here's my version (compatible with all 65xx systems):

LDY #0
LDA eal
STA (eal),Y
INY

LDA eah
STA (eal),Y

The fastest 65C02 version of store pointer value to pointer location is only two clocks faster and one byte shorter:

+ LDA eal : STA (eal) : LDA eah : LDY #1 : STA (eal),Y

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use