Reading Kernal version

[StephenHorn]

30 minutes ago, Lorin Millsap said:

Personally I think R39 should be pushed and if it turns out we need to make some hardware changes we can push out an R40 release.

[Snickers11001001]

2 hours ago, Lorin Millsap said:

Personally I think R39 should be pushed and if it turns out we need to make some hardware changes we can push out an R40 release.

Your mindset seems really sensible.  Even if further tweaks are necessary, a release would take the community off 'pause' (avoiding any potential fall off of enthusiasm), and also acknowledge the value/importance of the work by the team members who have put so much time into the updates from r38 to r39.   

 

[Stefan]

8 hours ago, ZeroByte said:

Isn't there an IO address to ask the emu what version it is?



Another idea might be to do something like

stz $00

stz $bfff

lda #1

sta $00

sta $bfff

stz $00

cmp $bfff

beq R39

.R38:

 

The Kernal version is stored in bank 0/$ff80.

The problem is how to change to bank 0 before you know what version is running.

There are several ways to handle this, I'm sure:

• 
  Your solution might work. One possible problem is that there is a risk you are overwriting values used by the Kernal. Even if you could determine that $bfff is not used today it might be in the future.
  


• 
  Another solution I've read about some time ago is to write a 0 both to $01 and to $9f60. This seems to work, but I'm not really a fan of doing this, as $9f60 is connected to VIA1 in R39 according to the PRG.
  


• 
  Using the FETVEC function has the advantage that you are using a public Kernal function that should be stable between versions.
  

[Ed Minchau]

Using FETVEC is probably the way to go. Like @ZeroByte, I have kept my development at R38 until an official release of R39 comes out. I prefer to use only the official release version, even though a preliminary release is available. 

[TomXP411]

10 hours ago, SlithyMatt said:

It's not just a matter of pressing a button on GitHub. He has to separately compile and package the release for each platform... not that it should be that hard to do, assuming the hard work is already scripted.

Having said that... I've compiled it on several platforms, and it only takes a few minutes, once you've got the environment set up. 

Here is the Windows version:

https://www.commanderx16.com/forum/applications/core/interface/file/attachment.php?id=1154

If you're on Mac or Linux, it should compile pretty much directly from the Github master. Windows is the only one that's difficult; I had to cross-compile it on Linux to make it work. 

[BruceMcF]

3 hours ago, Stefan said:

• 
  Your solution might work. One possible problem is that there is a risk you are overwriting values used by the Kernal. Even if you could determine that $bfff is not used today it might be in the future.
  


• 
  Another solution I've read about some time ago is to write a 0 both to $01 and to $9f60. This seems to work, but I'm not really a fan of doing this, as $9f60 is connected to VIA1 in R39 according to the PRG.
  


• 
  Using the FETVEC function has the advantage that you are using a public Kernal function that should be stable between versions.
  

Though it doesn't have to be future proof ... it's only a bridge until R39 becomes the baseline release.

That's the part that has me in suspended animation ... I am not interested in putting code into a version test that I am going to want to strip out again once R39 is the public release.

[Stefan]

5 hours ago, BruceMcF said:

Though it doesn't have to be future proof ... it's only a bridge until R39 becomes the baseline release.



That's the part that has me in suspended animation ... I am not interested in putting code into a version test that I am going to want to strip out again once R39 is the public release.

That is understandable.

I did the following to make a coming clean-up easy:

• 
  The Kernal version is read at program startup. The control addresses for RAM and ROM select used by the detected Kernal version are stored in two zero page words
  


• 
  In the rest of the program I read and store bank selections using these zero page words, like "STA (RAM_SEL)"
  


• 
  When R39 is official, it's easy to do a project wide search and replace "(RAM_SEL)" with "RAM_SEL". RAM_SEL would then just be a definition pointing to the control address.
  

But just a few minutes ago @Kevin Williams announced that prototype #3 is working more or less. Maybe R39 is not too long away...

[Greg King]

This thread actually is about the mainboard version, not the Kernal version.  This is the easiest way to test it, and switch to the Kernal bank:

; Assume BASIC ROM bank 4 at this point.
    stz $01
    lda $FFF8  ; BASIC has zero, Kernal has nonzero
    bne mb2
    stz $9F60
mb2:

"stz $01" changes that location, but does nothing else, on mainboard #1.  It changes to Kernal's bank on other mainboard versions.  $FFF8 is a part of Kernal's "mist" signature.  But, it's zeroes in the BASIC bank.

[John Chow Seymour]

1 hour ago, Greg King said:

$FFF8 is a part of Kernal's "mist" signature.

Pardon my ignorance, what's a "mist signature"?

[Snickers11001001]

14 minutes ago, John Chow Seymour said:

Pardon my ignorance, what's a "mist signature"?

Michael Steil, user name 'mist64' GITHUB.     The ROCK-STAR coder who has deep deep understanding of C64 and C128 kernal code (his web page has a great commented disassembly of the C64 roms) and who did a ton of work making the X16 basic and kernal roms come to fruition.   

The rom has 'MIST' in there as his signature.