Proto #2 support in GitHub ROM, Emulator & Documentation

[SlithyMatt]

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.

[ZeroByte]

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)

[Ed Minchau]

1 hour ago, ZeroByte said:

(can you tell we're dorks when we do that for fun - lol)

My mom says I'm cool.

[Snickers11001001]

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! 

[ZeroByte]

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)

[ZeroByte]

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)

[Elektron72]

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


x16emu.zip

[Elektron72]

@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.

[ZeroByte]

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. ?

[ZeroByte]

Ironically, not only would the Kernal need to be patched, but so would the emulator to mimic the new functionality in its warp load routines.