New BASIC command/token in ROM

[JimmyDansbo 66]

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

[desertfish 172]

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?

[JimmyDansbo 66]

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 October 23, 2020 by JimmyDansbo

[desertfish 172]

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 October 23, 2020 by desertfish

[JimmyDansbo 66]

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

[desertfish 172]

I'm intrigued     I hope to find some time this weekend to spend on this issue!

[desertfish 172]

@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 October 23, 2020 by desertfish

[JimmyDansbo 66]

@desertfish That is great, I will look into if it is possible to just jump to the monitor code even though it is in another bank. Thanks

[JimmyDansbo 66]

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.

 

[JimmyDansbo 66]

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 October 24, 2020 by JimmyDansbo

[desertfish 172]

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

 

[JimmyDansbo 66]

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

[desertfish 172]

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

[JimmyDansbo 66]

Yes indeed. How did you figure out that it was necessary to do pla twice before jmp'ing to strlit ?

[desertfish 172]

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

[JimmyDansbo 66]

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

[JimmyDansbo 66]

I managed to free up some space in the BASIC ROM page.

https://github.com/JimmyDansbo/x16-rom/commit/a0470c136811ef56c6f3d5131bc9ffa1d254f9b6

@desertfish do you think we should try and go for handling word values as well as byte values?

Edited October 25, 2020 by JimmyDansbo

[desertfish 172]

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

[JimmyDansbo 66]

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 

[desertfish 172]

For me it's perfectly fine if HEX$(255) -> FF   and HEX$(65535) -> FFFF

 

[Greg King 50]

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 

[JimmyDansbo 66]

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 October 27, 2020 by JimmyDansbo

[Greg King 50]

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.

[desertfish 172]

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)

[JimmyDansbo 66]

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.