Jump to content
JimmyDansbo

New BASIC command/token in ROM

Recommended Posts

I have been trying to help the KERNAL development by creating the HEX$ and BIN$ BASIC commands/tokens, but I do not understand enough of the KERNAL source to actually figure out how to create a new command/token.

Kan anyone point me in the right direction as to what I am missing?

See my note on the issue here:

https://github.com/commanderx16/x16-rom/issues/49#issuecomment-714964134

Thanks in advance

Share this post


Link to post
Share on other sites

Hey I was wondering about the lack of HEX$ and BIN$ myself as well so this is an iteresting topic to me! I would like to see if I can perhaps help you with this but  I have zero experience with building a custom rom though right now.   I don't know if that is difficult to  set up?

Share this post


Link to post
Share on other sites

It is not too bad to setup the environment to build a custom rom, if you have a look at https://github.com/commanderx16/x16-rom the README.md tells you how to do it.

I have actually managed to create the HEX$ keyword in ROM, now I just need to figure out how to return a string. Aparently I can not return a multi-byte string the same way as CHR$ returns a single-byte string 😞

You can follow my progress here: https://github.com/JimmyDansbo/x16-rom

Edited by JimmyDansbo

Share this post


Link to post
Share on other sites

first reaction is: look at how left$  is returning a string?    (disclaimer: i have no idea at all how to look into the BASIC rom for how it executes certain tokens....)

Edited by desertfish

Share this post


Link to post
Share on other sites
2 minutes ago, desertfish said:

first reaction is: look at how left$  is returning a string?

Yeah, I have been looking at CHR$, STR$, LEFT$, RIGHT$ and MID$ I still can not get my head around how a string gets allocated, populated and returned correctly.

The way it is done in CHR$ seems fairly simple, but when I try to allocate space for more than 1 byte, I get a type mismatch 😞

Share this post


Link to post
Share on other sites

@JimmyDansbo I made a pull request on GitHub to your repository, with what I think should be a working HEX$  including the ability to accept numbers up to 65535

I think it should use the existing routines from the Monitor, but that gave me a 'symbol undefined' error during building of the rom...   I dunno how to access it.  Also I am not sure if this is even possible because it is in a different memory bank perhaps??? (I'm a bit unfamiliar with how that works still)

So for now I simply copied the byte_to_hex_ascii routine from monitor.s almost verbatim into here

Edited by desertfish

Share this post


Link to post
Share on other sites
6 hours ago, desertfish said:

I think it should use the existing routines from the Monitor, but that gave me a 'symbol undefined' error during building of the rom...   I dunno how to access it.  Also I am not sure if this is even possible because it is in a different memory bank perhaps??? (I'm a bit unfamiliar with how that works still)

If you look close to the top of the x16additions.s file

https://github.com/JimmyDansbo/x16-rom/blob/1ab984f18aa5068af6be5368a997810fa1a4e666/basic/x16additions.s#L53

You can see how it goes about calling the monitor from BASIC.

When the ROM is compiled, the monitor.sym file tells us that the byte_to_hex_ascii function has address $C829 so what we can do is this:

Quote

jsr bjsrfar

.word $C829

.byte BANK_MONITOR

I have tested it and it does work, however I think it adds a lot of overhead and if the code in monitor is changed, our $C829 constant needs to be changed.

 

Share this post


Link to post
Share on other sites

I have now implemented both HEX$ and BIN$ and there is NO more room in the 16KB BASIC ROM page.

I have had to change the functions to only accept a single byte and I have removed any preceding characters ('$' and '%').

Also it was necessary to to actually use the byte_to_hex_ascii function from the MONITOR code to make the functions fit in BASIC ROM.

Please have a look and let me know if there is anything that should be changed or improved. Otherwise I will do a pull request against the official branch.

Edited by JimmyDansbo

Share this post


Link to post
Share on other sites

Hmm, was it because of the ROM size limitation that the 16-bit support had to be dropped? Very unfortunate....

Also I would have expected that using ".import byte_to_hex_ascii "  would enable you to use the symbol rather than the absolute address but that doesn't work.   I'm not familiar enough with the tool chain to come up with a possible solution for this.  Is there someone else that can?    I think referring to the absolute address of the function is quite brittle

 

Share this post


Link to post
Share on other sites
2 minutes ago, desertfish said:

Hmm, was it because of the ROM size limitation that the 16-bit support had to be dropped?

Yes, I think there might be a single byte available after these functions have been added as they are now.

Also, I think that the functions will mostly be used to show output of peeks and vpeeks which are only a single byte anyway ?

3 minutes ago, desertfish said:

I think referring to the absolute address of the function is quite brittle

I totally agree, but I don't know how to be able to use the name either. I am thinking that ROM maintainer will let us know if I do a pull request 😉

Share this post


Link to post
Share on other sites

I hope so, may be wise to mention this issue in the PR 🙂     Anyway it's great we got something working  🙂

Share this post


Link to post
Share on other sites

I looked at the disassembly for several other tokens and kinda played with it,  i started by just copying the code from STR$ and went from there I believe.   I don't understand basic's execution loop and things I just copied stuff from elsewhere until it worked...

  • Thanks 1

Share this post


Link to post
Share on other sites

Argh, I just tried compiling the new ROM with the PRERELEASE_VERSION set and then it is too large to fit in the 16KB ROM page 😞

Share this post


Link to post
Share on other sites

I would like to see support for word values, to mirror the ability of the '$' and '%' prefixes to deal with words.  However your argument about the actual real world usage of HEX$ and BIN$ are relevant too.   I mostly need the full 16 bits when in an assembly environment, and we have the monitor for that.....

Share this post


Link to post
Share on other sites

Now that space is freed in the BASIC ROM page, I think it will actually be possible have the functions handle word values as well.

Do you think it would be sufficient that HEX$ outputs a 4 byte string if the value is larger than 255 otherwise a 2 byte string?

Or should it be something that you specify when calling i.e. something like HEX$(42, 1) returns 2A and HEX$(42, 2) returns 002A 

Share this post


Link to post
Share on other sites
On 10/24/2020 at 6:48 AM, desertfish said:

Also, I would have expected that using ".import byte_to_hex_ascii "  would enable you to use the symbol rather than the absolute address; but, that doesn't work.   I'm not familiar enough with the tool chain to come up with a possible solution for that.  Is there someone else that can?  I think that referring to the absolute address of the function is quite brittle.

Every ".import name" must be matched by a ".export name".  In this case, "monitor.s" should contain

.export byte_to_hex_ascii 

Share this post


Link to post
Share on other sites

I believe I tried that without luck...

... Just tried it again, still no luck.

in monitor.s: .export byte_to_hex_ascii

in x16additions.s: .import byte_to_hex_ascii

... Still it does not recognize the name.

Edited by JimmyDansbo

Share this post


Link to post
Share on other sites

I looked at the makefile.  Unfortunately, the ROM banks are built separately, nowadays.  They can't know about each other's labels.

Jump-tables in unchangable locations would need to be used to share subroutines, reliably, from other functional modules.

Share this post


Link to post
Share on other sites

Sounds to me as if copy-pasting that particular routine from the monitor is the way to go....    (personally I would prefer that over a suddenly crashing ROM because the monitor was modified and the routine is no longer on the hardcoded address)

Share this post


Link to post
Share on other sites
7 hours ago, desertfish said:

Sounds to me as if copy-pasting that particular routine from the monitor is the way to go....

I agree. Now that some space has been freed, I will look into getting the byte_to_hex_ascii function back into the BASIC rom and I will tidy up the HEX$ and BIN$ functions as I had to jump through quite a lot of hoops to make the fit before.

  • Thanks 1

Share this post


Link to post
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.


×
×
  • Create New...

Important Information

Please review our Terms of Use