Jump to content

Reading Kernal version


Stefan
 Share

Recommended Posts

Hi,

I was struggling a bit with reading the Kernal version number in an assembly program that is to support both R38 and R39.

As is apparent from the PRG, the Kernal version is stored in ROM bank 0/$ff80.

The problem I had was that you are not in ROM bank 0 when starting an assembly program from BASIC. Reading $ff80 in the BASIC ROM bank does not give you the version number.

And to change ROM bank you need to know what version is used. Almost like "catch 22".

I found a solution using the Kernal function FETVEC ($ff74) that is callable from the BASIC ROM bank, getting the version number like this:

lda #$80
sta $22
lda #$ff
sta $23
ldx #$00
lda #$22
jsr $ff74

And then you have the version number in A.

Edited by Stefan
  • Like 2
Link to comment
Share on other sites

4 minutes ago, Lorin Millsap said:

There is no reason to support R38 as R38 doesn’t reflect the real hardware. You should shift your code to R39 or have separate binaries as R39 doesn’t have an official release yet.

I'm sure there are lots of behind-the-scenes reasons why this hasn't happened, but would it be possible to get someone to push the "R39 = official" button on the Github repo? My R39 workarounds include doing some manual things because cc65 gets broken on R39, and there are other tool chain projects like Prog8 etc which are also in limbo until this major revision gets officially blessed. I'm intentionally keeping my tools frozen as long as R38 is the official version, and I've read posts here and elsewhere by those who are ready to merge updates into cc65, etc.

  • Like 1
Link to comment
Share on other sites

I'm sure there are lots of behind-the-scenes reasons why this hasn't happened, but would it be possible to get someone to push the "R39 = official" button on the Github repo? My R39 workarounds include doing some manual things because cc65 gets broken on R39, and there are other tool chain projects like Prog8 etc which are also in limbo until this major revision gets officially blessed. I'm intentionally keeping my tools frozen as long as R38 is the official version, and I've read posts here and elsewhere by those who are ready to merge updates into cc65, etc.

The reason it hasn’t been pushed is there are some hardware things having to do with keyboard and mouse handling which haven’t been tested on real hardware yet. However the R39 is there and can be compiled, and so long as you are using Kernal routines it should work. 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.


Sent from my iPhone using Tapatalk
  • Like 7
Link to comment
Share on other sites

21 minutes ago, Lorin Millsap said:


The reason it hasn’t been pushed is there are some hardware things having to do with keyboard and mouse handling which haven’t been tested on real hardware yet. However the R39 is there and can be compiled, and so long as you are using Kernal routines it should work. 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.

Thank you.

The change to the bank registers alone is more than enough reason to publish R39. We all know and accept that the hardware will not perfectly match the emulator, but I think it's still important to stay up to date with the latest ROM changes and hardware changes we do know about. Combined with the other changes, it's more important at this point to have the latest code than the "best" code, IMO. 

 

Edited by TomXP411
  • Like 3
Link to comment
Share on other sites

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.   

 

  • Like 2
Link to comment
Share on other sites

Posted (edited)
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.
Edited by Stefan
Link to comment
Share on other sites

10 hours ago, SlithyMatt said:

image.png.1ef2cbf9e3ea33620cf8c60b4b687eae.png

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. 

Edited by TomXP411
Link to comment
Share on other sites

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.

  • Like 4
Link to comment
Share on other sites

Posted (edited)
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...

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

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.

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

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.

Edited by Snickers11001001
  • Thanks 1
Link to comment
Share on other sites

6 minutes ago, John Chow Seymour said:

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

I'm assuming it is related to Michael Steil (aka mist) who is working on the kernal. There is a four byte signature in the source code, though I don't find it at $FFF8.

 

  • Thanks 1
Link to comment
Share on other sites

 

39 minutes ago, Scott Robison said:

I'm assuming it is related to Michael Steil (aka mist) who is working on the kernal. There is a four byte signature in the source code, though I don't find it at $FFF8.

 

Run the emulator.  Use BASIC's MON command to start the monitor.  Give the command "m fff0 ffff".  You'll see it.

Link to comment
Share on other sites

Just now, Scott Robison said:

I looked at the rom.bin image and didn't see the signature at that offset.

DOH! I didn't think about the rom being 16K pages. I was looking for the bytes at the byte offset, which would have put it in bank 3.

Though: It still doesn't start at $FFF8, hence part of my confusion. But the bigger issue was my duh me moment expecting to see file offsets as addresses.

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