VBCC Optimizing C-compiler now supports NES

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

vbc
Posts: 40
Joined: Sun Jun 21, 2020 5:03 pm

Re: VBCC Optimizing C-compiler now supports NES

Post by vbc » Thu Jul 23, 2020 8:14 am

Banshaku wrote:
Thu Jul 23, 2020 5:45 am
The problem with the nes compared to other console is that there is a multitude of mapper which uses different way to bank-switch so there is no easy way to support all of them in vbcc.
And there are also other 6502 targets using other forms of banking that I want to support. That has always been the design goal for my implementation of banking. For example, I have now created a banking library for a C64 memory expansion. Now I can compile my banking examples also for the C64. I did not change the compiler, only wrote the library code and linker script.

And this memory expansion works quite different from an NES mapper.
To be able to do so, the code that requires the bank-switch for the far pointers needs to be available (and it is now) and either the user develop the code for the mapper he needs to interact with or he uses a few provided by vbcc as examples. That's the only way for now.
Yes, I think this is a perfectly fine solution.
For my own mmc3 project, I may later define the code for far pointers and will check the example provided but for now my current tests do it manually and access the data like if it was in the exact same bank. It is hopefully faster than a far pointer but a little bit more fastidious since you have to do everything by hand.
Yes, there is nothing wrong doing the banking manually.

vbc
Posts: 40
Joined: Sun Jun 21, 2020 5:03 pm

Re: VBCC Optimizing C-compiler now supports NES

Post by vbc » Thu Jul 23, 2020 8:22 am

Banshaku wrote:
Thu Jul 23, 2020 5:52 am
vbc wrote:
Wed Jul 22, 2020 3:38 am
Apparently it was specified like that in GNU ld and vlink tries to be compatible. We added RESERVE to get around the problems it causes.
I see but isn't fill the same idea as reserve somehow? what is the difference?
fill only inserts the space if some data follows. You cannot use it to fill space at the end. And adding an extra byte at the end is a problem if your data is exactly the full size. Otherwise it is pretty similar.
thank you again for answering my questions.
Thank you as well for your comments and feedback. It definitely helps us to improve vbcc.

Btw. Frank has added linker script documentation as well as ORIGIN/LENGTH (the latter was easy, the former did cost some effort :-) ). This will be included in the next update.

User avatar
Banshaku
Posts: 2377
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: VBCC Optimizing C-compiler now supports NES

Post by Banshaku » Thu Jul 23, 2020 7:32 pm

I will answer both post in the same since it easier to follow.

Regarding mapper, understood. I will test the far pointer later since there is one case in my old code that uses a trampoline with a pragma (concept of far pointer in cc65, that's something added recently) so I'm curious how it will make the code simpler in that case than that concept they had ;)
vbc wrote:
Thu Jul 23, 2020 8:22 am
fill only inserts the space if some data follows. You cannot use it to fill space at the end. And adding an extra byte at the end is a problem if your data is exactly the full size. Otherwise it is pretty similar.
Oh, I see. Maybe this is why I saw a few scripts that added an extra byte at the end. From the doc, it's not clear that you cannot fill without adding something. Reserve is more useful in that case then.
vbc wrote:
Thu Jul 23, 2020 8:22 am
Thank you as well for your comments and feedback. It definitely helps us to improve vbcc.
You're welcome. I love C and since I had a few issues with cc65 I'm more than happy to test vbcc and see the improvement I can get from it. Of course porting code is an issue at first and there is less debugging since mesen was made for cc65 in mind but I think if all goes well, it should get a lot of interest for the nes community. What is important is to get some sample going (like lazycow did) to help dev gets started. I can help for that later but I'm more of a makefile oriented guy so if VC has to be used, I need to adapt it. My current file allow to compile C code by just putting files in source folder and it does all the job for you and you don't need to write include path too (something that save time when you refactor code). It's quite convenient for beginners which was the goal at first but now I use that concept in all my project (laugh).

One thing I would suggest is even though the code at first was not public, the startup/banking code should be documented so that if people need to adapt they can do it on their own. I could figure it out (at the least the startup code) since I did once for cc65 but some people may have less experience with that. One example is the code for copying BSS data. Just reading the code I wouldn't have known it was for that since it's specific for vbcc.

quote=vbc post_id=252741 time=1595517772 user_id=16792]
Btw. Frank has added linker script documentation as well as ORIGIN/LENGTH (the latter was easy, the former did cost some effort :-) ). This will be included in the next update.
[/quote]

I see. Since I'm the one that started that request then I will be more than happy to test it.

Time to continue to port code and test rawseg, curious how it will goes (not necessary now since mm3 it's working it's just that I'm a curious guy :lol:).

User avatar
Banshaku
Posts: 2377
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: VBCC Optimizing C-compiler now supports NES

Post by Banshaku » Thu Jul 23, 2020 7:34 pm

Banshaku wrote:
Thu Jul 23, 2020 7:32 pm
I will answer both post in the same since it easier to follow.

Regarding mapper, understood. I will test the far pointer later since there is one case in my old code that uses a trampoline with a pragma (concept of far pointer in cc65, that's something added recently) so I'm curious how it will make the code simpler in that case than that concept they had ;) The far pointer feels more C like and reminds me of the dos days with turbo C.
vbc wrote:
Thu Jul 23, 2020 8:22 am
fill only inserts the space if some data follows. You cannot use it to fill space at the end. And adding an extra byte at the end is a problem if your data is exactly the full size. Otherwise it is pretty similar.
Oh, I see. Maybe this is why I saw a few scripts that added an extra byte at the end. From the doc, it's not clear that you cannot fill without adding something. Reserve is more useful in that case then.
vbc wrote:
Thu Jul 23, 2020 8:22 am
Thank you as well for your comments and feedback. It definitely helps us to improve vbcc.
You're welcome. I love C and since I had a few issues with cc65 I'm more than happy to test vbcc and see the improvement I can get from it. Of course porting code is an issue at first and there is less debugging since mesen was made for cc65 in mind but I think if all goes well, it should get a lot of interest for the nes community. What is important is to get some sample going (like lazycow did) to help dev gets started. I can help for that later but I'm more of a makefile oriented guy so if VC has to be used, I need to adapt it. My current file allow to compile C code by just putting files in source folder and it does all the job for you and you don't need to write include path too (something that save time when you refactor code). It's quite convenient for beginners which was the goal at first but now I use that concept in all my project (laugh).

One thing I would suggest is even though the code at first was not public, the startup/banking code should be documented so that if people need to adapt they can do it on their own. I could figure it out (at the least the startup code) since I did once for cc65 but some people may have less experience with that. One example is the code for copying BSS data. Just reading the code I wouldn't have known it was for that since it's specific for vbcc.

quote=vbc post_id=252741 time=1595517772 user_id=16792]
Btw. Frank has added linker script documentation as well as ORIGIN/LENGTH (the latter was easy, the former did cost some effort :-) ). This will be included in the next update.
I see. Since I'm the one that started that request then I will be more than happy to test it.

Time to continue to port code and test rawseg, curious how it will goes (not necessary now since mm3 it's working it's just that I'm a curious guy :lol:).
[/quote]

User avatar
Banshaku
Posts: 2377
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: VBCC Optimizing C-compiler now supports NES

Post by Banshaku » Thu Jul 23, 2020 7:34 pm

I will answer both post in the same since it easier to follow.

Regarding mapper, understood. I will test the far pointer later since there is one case in my old code that uses a trampoline with a pragma (concept of far pointer in cc65, that's something added recently) so I'm curious how it will make the code simpler in that case than that concept they had ;) The far pointer feels more C like and reminds me of the dos days with turbo C.
vbc wrote:
Thu Jul 23, 2020 8:22 am
fill only inserts the space if some data follows. You cannot use it to fill space at the end. And adding an extra byte at the end is a problem if your data is exactly the full size. Otherwise it is pretty similar.
Oh, I see. Maybe this is why I saw a few scripts that added an extra byte at the end. From the doc, it's not clear that you cannot fill without adding something. Reserve is more useful in that case then.
vbc wrote:
Thu Jul 23, 2020 8:22 am
Thank you as well for your comments and feedback. It definitely helps us to improve vbcc.
You're welcome. I love C and since I had a few issues with cc65 I'm more than happy to test vbcc and see the improvement I can get from it. Of course porting code is an issue at first and there is less debugging since mesen was made for cc65 in mind but I think if all goes well, it should get a lot of interest for the nes community. What is important is to get some sample going (like lazycow did) to help dev gets started. I can help for that later but I'm more of a makefile oriented guy so if VC has to be used, I need to adapt it. My current file allow to compile C code by just putting files in source folder and it does all the job for you and you don't need to write include path too (something that save time when you refactor code). It's quite convenient for beginners which was the goal at first but now I use that concept in all my project (laugh).

One thing I would suggest is even though the code at first was not public, the startup/banking code should be documented so that if people need to adapt they can do it on their own. I could figure it out (at the least the startup code) since I did once for cc65 but some people may have less experience with that. One example is the code for copying BSS data. Just reading the code I wouldn't have known it was for that since it's specific for vbcc.

quote=vbc post_id=252741 time=1595517772 user_id=16792]
Btw. Frank has added linker script documentation as well as ORIGIN/LENGTH (the latter was easy, the former did cost some effort :-) ). This will be included in the next update.
[/quote]

I see. Since I'm the one that started that request then I will be more than happy to test it.

Time to continue to port code and test rawseg, curious how it will goes (not necessary now since mm3 it's working it's just that I'm a curious guy :lol:).

User avatar
Banshaku
Posts: 2377
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: VBCC Optimizing C-compiler now supports NES

Post by Banshaku » Thu Jul 23, 2020 7:36 pm

Banshaku wrote:
Thu Jul 23, 2020 7:34 pm
I will answer both post in the same since it easier to follow.

Regarding mapper, understood. I will test the far pointer later since there is one case in my old code that uses a trampoline with a pragma (concept of far pointer in cc65, that's something added recently) so I'm curious how it will make the code simpler in that case than that concept they had ;) The far pointer feels more C like and reminds me of the dos days with turbo C.
vbc wrote:
Thu Jul 23, 2020 8:22 am
fill only inserts the space if some data follows. You cannot use it to fill space at the end. And adding an extra byte at the end is a problem if your data is exactly the full size. Otherwise it is pretty similar.
Oh, I see. Maybe this is why I saw a few scripts that added an extra byte at the end. From the doc, it's not clear that you cannot fill without adding something. Reserve is more useful in that case then.
vbc wrote:
Thu Jul 23, 2020 8:22 am
Thank you as well for your comments and feedback. It definitely helps us to improve vbcc.
You're welcome. I love C and since I had a few issues with cc65 I'm more than happy to test vbcc and see the improvement I can get from it. Of course porting code is an issue at first and there is less debugging since mesen was made for cc65 in mind but I think if all goes well, it should get a lot of interest for the nes community. What is important is to get some sample going (like lazycow did) to help dev gets started. I can help for that later but I'm more of a makefile oriented guy so if VC has to be used, I need to adapt it. My current file allow to compile C code by just putting files in source folder and it does all the job for you and you don't need to write include path too (something that save time when you refactor code). It's quite convenient for beginners which was the goal at first but now I use that concept in all my project (laugh).

One thing I would suggest is even though the code at first was not public, the startup/banking code should be documented so that if people need to adapt they can do it on their own. I could figure it out (at the least the startup code) since I did once for cc65 but some people may have less experience with that. One example is the code for copying BSS data. Just reading the code I wouldn't have known it was for that since it's specific for vbcc.
vbc wrote:
Thu Jul 23, 2020 8:22 am
Btw. Frank has added linker script documentation as well as ORIGIN/LENGTH (the latter was easy, the former did cost some effort :-) ). This will be included in the next update.
I see. Since I'm the one that started that request then I will be more than happy to test it.

Time to continue to port code and test rawseg, curious how it will goes (not necessary now since mm3 it's working it's just that I'm a curious guy :lol:).

User avatar
Banshaku
Posts: 2377
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: VBCC Optimizing C-compiler now supports NES

Post by Banshaku » Thu Jul 23, 2020 7:36 pm

I will answer both post in the same since it easier to follow.

Regarding mapper, understood. I will test the far pointer later since there is one case in my old code that uses a trampoline with a pragma (concept of far pointer in cc65, that's something added recently) so I'm curious how it will make the code simpler in that case than that concept they had ;) The far pointer feels more C like and reminds me of the dos days with turbo C.
vbc wrote:
Thu Jul 23, 2020 8:22 am
fill only inserts the space if some data follows. You cannot use it to fill space at the end. And adding an extra byte at the end is a problem if your data is exactly the full size. Otherwise it is pretty similar.
Oh, I see. Maybe this is why I saw a few scripts that added an extra byte at the end. From the doc, it's not clear that you cannot fill without adding something. Reserve is more useful in that case then.
vbc wrote:
Thu Jul 23, 2020 8:22 am
Thank you as well for your comments and feedback. It definitely helps us to improve vbcc.
You're welcome. I love C and since I had a few issues with cc65 I'm more than happy to test vbcc and see the improvement I can get from it. Of course porting code is an issue at first and there is less debugging since mesen was made for cc65 in mind but I think if all goes well, it should get a lot of interest for the nes community. What is important is to get some sample going (like lazycow did) to help dev gets started. I can help for that later but I'm more of a makefile oriented guy so if VC has to be used, I need to adapt it. My current file allow to compile C code by just putting files in source folder and it does all the job for you and you don't need to write include path too (something that save time when you refactor code). It's quite convenient for beginners which was the goal at first but now I use that concept in all my project (laugh).

One thing I would suggest is even though the code at first was not public, the startup/banking code should be documented so that if people need to adapt they can do it on their own. I could figure it out (at the least the startup code) since I did once for cc65 but some people may have less experience with that. One example is the code for copying BSS data. Just reading the code I wouldn't have known it was for that since it's specific for vbcc.
vbc wrote:
Thu Jul 23, 2020 8:22 am
Btw. Frank has added linker script documentation as well as ORIGIN/LENGTH (the latter was easy, the former did cost some effort :-) ). This will be included in the next update.
I see. Since I'm the one that started that request then I will be more than happy to test it.

Time to continue to port code and test rawseg, curious how it will goes (not necessary now since mm3 it's working it's just that I'm a curious guy :lol:).

edit:

I have a question regarding vasm and it may come from my lack of experience to uses many assemblers. When using vasm (I guess in old style), except for labels, everything has to be on something else than column 1. Is it for compatibility with older assembler? I liked when I could put section on the first column, but now that's not possible. Not a problem per se, just liked it visually (laugh). Seems macro name can be written on column 1 but I was not able to do it somehow.

For now it's not really an issue, just an habit of writing code a specific way. I will get used soon.

edit2:

I'm porting one library but I used code that was so specific to ca65 that it's a little bit painful to port. I'm not used to old style syntax so I'm not sure how to use a struct.

In ca65, you could define a struct and use it to access offset at a ram address like this:

Code: Select all

	lda myVar+myStruct::myVal
but from reading the doc, I'm not sure if this is possible to do so. It seems possible to define a memory area and access with the symbols inside but not sure if it can be done that way. Is it? I need to test it but if it's possible, I guess it would be doable that way?

Code: Select all

 	lda myWar+myStruct.myVal
 
but there was no example in the doc, thus my confusion.

edit3:

For now my workaround for offset is to just create some symbol that act the same way as the struct I was using and I just map to the target variable and it's working fine. Still need to figure out what is the proper way to use struct in the old syntax. I guess ca65 is not that standard after all.
Last edited by Banshaku on Sat Jul 25, 2020 9:04 am, edited 5 times in total.

User avatar
Memblers
Site Admin
Posts: 3858
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: VBCC Optimizing C-compiler now supports NES

Post by Memblers » Thu Jul 23, 2020 8:14 pm

I don't have any questions yet, just wanted to say thanks for working on this compiler, and the NES support with standard I/O and all that. I've been having some fun with it, grabbing small programs off the internet, and seeing them work as expected, with no changes needed other than accommodating the smaller screen width. I don't expect to use floats much in my own stuff, but since so much code out there does use it, it is neat to just grab some code to render a Mandelbrot set, and zoom in to it with the (stdin) controller, even though it takes like 15 minutes in emulated time to render the screen.
set2.png
Everything that compiled seemed to work fine. The ones that didn't build were mostly because in math.h some functions like floor and log weren't found. I think I saw one of them crash at runtime (at least it doesn't make it to later printf statements), it seemed to be assuming a 32-bit int, so I imagine that caused it.

rox_midge
Posts: 88
Joined: Mon Sep 19, 2005 11:51 am

Re: VBCC Optimizing C-compiler now supports NES

Post by rox_midge » Sat Jul 25, 2020 11:00 am

vbc, the more I play with this, the more I love it. Thanks to the advanced nature of the optimizations present here, I've been able to convert almost all of my project over to pure C, with only some parts left in assembly.

Would it be possible to get two small "creature comfort" options added in somehow? Neither of these are dealbreakers for me, but they'd make things a bit more comfortable to use:
  1. When using the -k option to keep the intermediate files, I'd like to specify a directory where those intermediate files should be written. Right now, the intermediate files (.asm, .o, etc.) get put into the same directory as the corresponding source file. I'd like to be able to have them written to an entirely different directory instead, so that I can examine them without having them clutter up my source directory.
  2. When generating assembly, I'd like some / all integer constants to be rendered in hexadecimal instead of decimal. This would be super helpful when reviewing the output, because although I know that, say, $8000 means the MMC3 bank select register, my eyes glaze over when I see "sta 40960".
Having the original C source included in the assembly would possibly address the second issue, but I couldn't find a way to do that either.

Thanks again for all your great work on this!

User avatar
Banshaku
Posts: 2377
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: VBCC Optimizing C-compiler now supports NES

Post by Banshaku » Sat Jul 25, 2020 4:49 pm

Hi!

Regarding your first point :
rox_midge wrote:
Sat Jul 25, 2020 11:00 am
  1. When using the -k option to keep the intermediate files, I'd like to specify a directory where those intermediate files should be written. Right now, the intermediate files (.asm, .o, etc.) get put into the same directory as the corresponding source file. I'd like to be able to have them written to an entirely different directory instead, so that I can examine them without having them clutter up my source directory.
this has to be done with a setting with the compiler and this is what exactly my makefile do, put in the build folder the object/map/asm and in the same structure as your source. Does VC allows to do it? I do not think directly, you have to modify the config file for the target mapper which contains the parameters for vbcc/vasm etc. So it is possible to make it at the moment if you make your own custom config file (and it is necessary if you use your own linker file, unless mistaken).
rox_midge wrote:
Sat Jul 25, 2020 11:00 am
[*] When generating assembly, I'd like some / all integer constants to be rendered in hexadecimal instead of decimal. This would be super helpful when reviewing the output, because although I know that, say, $8000 means the MMC3 bank select register, my eyes glaze over when I see "sta 40960".
I didn't realize up to know about that point, yes, that's all in decimal. I think Vbc would be better placed to answer that question but I will check myself since I'm curious about that.
rox_midge wrote:
Sat Jul 25, 2020 11:00 am
Having the original C source included in the assembly would possibly address the second issue, but I couldn't find a way to do that either.
I asked about that (for the C code inside asm) and such option doesn't exist unfortunately.

Hope it helps until Vbc is available.

User avatar
Banshaku
Posts: 2377
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: VBCC Optimizing C-compiler now supports NES

Post by Banshaku » Sat Jul 25, 2020 4:50 pm

Banshaku wrote:
Sat Jul 25, 2020 4:49 pm
Hi!

Regarding your first point :
rox_midge wrote:
Sat Jul 25, 2020 11:00 am
  1. When using the -k option to keep the intermediate files, I'd like to specify a directory where those intermediate files should be written. Right now, the intermediate files (.asm, .o, etc.) get put into the same directory as the corresponding source file. I'd like to be able to have them written to an entirely different directory instead, so that I can examine them without having them clutter up my source directory.
this has to be done with a setting with the compiler and this is what exactly my makefile do, put in the build folder the object/map/asm and in the same structure as your source. Does VC allows to do it? I do not think directly, you have to modify the config file for the target mapper which contains the parameters for vbcc/vasm etc. So it is possible to make it at the moment if you make your own custom config file (and it is necessary if you use your own linker file, unless mistaken).
rox_midge wrote:
Sat Jul 25, 2020 11:00 am
[*] When generating assembly, I'd like some / all integer constants to be rendered in hexadecimal instead of decimal. This would be super helpful when reviewing the output, because although I know that, say, $8000 means the MMC3 bank select register, my eyes glaze over when I see "sta 40960".
I didn't realize up to now about that point, yes, that's all in decimal. I think Vbc would be better placed to answer that question but I will check myself since I'm curious about that.
rox_midge wrote:
Sat Jul 25, 2020 11:00 am
Having the original C source included in the assembly would possibly address the second issue, but I couldn't find a way to do that either.
I asked about that (for the C code inside asm) and such option doesn't exist unfortunately.

Hope it helps until Vbc is available.

User avatar
Banshaku
Posts: 2377
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: VBCC Optimizing C-compiler now supports NES

Post by Banshaku » Sat Jul 25, 2020 4:50 pm

Hi!

Regarding your first point :
rox_midge wrote:
Sat Jul 25, 2020 11:00 am
  1. When using the -k option to keep the intermediate files, I'd like to specify a directory where those intermediate files should be written. Right now, the intermediate files (.asm, .o, etc.) get put into the same directory as the corresponding source file. I'd like to be able to have them written to an entirely different directory instead, so that I can examine them without having them clutter up my source directory.
this has to be done with a setting with the compiler and this is what exactly my makefile do, put in the build folder the object/map/asm and in the same structure as your source. Does VC allows to do it? I do not think directly, you have to modify the config file for the target mapper which contains the parameters for vbcc/vasm etc. So it is possible to make it at the moment if you make your own custom config file (and it is necessary if you use your own linker file, unless mistaken).
rox_midge wrote:
Sat Jul 25, 2020 11:00 am
[*] When generating assembly, I'd like some / all integer constants to be rendered in hexadecimal instead of decimal. This would be super helpful when reviewing the output, because although I know that, say, $8000 means the MMC3 bank select register, my eyes glaze over when I see "sta 40960".
I didn't realize up to now about that point, yes, that's all in decimal. I think Vbc would be better placed to answer that question but I will check myself since I'm curious about that.
rox_midge wrote:
Sat Jul 25, 2020 11:00 am
Having the original C source included in the assembly would possibly address the second issue, but I couldn't find a way to do that either.
I asked about that (for the C code inside asm) and such option doesn't exist unfortunately.

Hope it helps until Vbc is available.

rox_midge
Posts: 88
Joined: Mon Sep 19, 2005 11:51 am

Re: VBCC Optimizing C-compiler now supports NES

Post by rox_midge » Sat Jul 25, 2020 7:47 pm

Banshaku wrote:
Sat Jul 25, 2020 4:50 pm
this has to be done with a setting with the compiler and this is what exactly my makefile do, put in the build folder the object/map/asm and in the same structure as your source. Does VC allows to do it? I do not think directly, you have to modify the config file for the target mapper which contains the parameters for vbcc/vasm etc. So it is possible to make it at the moment if you make your own custom config file (and it is necessary if you use your own linker file, unless mistaken).
Although I can do the same thing, running the underlying `vbcc6502` and `vasm6502_oldstyle` commands in my makefile manually, but it appears that when `vc` is run with '-O3', it generates an opaque command script that it passes to `vbcc6502` using the '-cmd' option. I can't make `vc` show me what's in that script. But like I said, it's not a dealbreaker.

I already had my own linker file, and wound up having to create my own config file, because something was causing the %%VBCC%% environment variable to not be available when running `make`. Although I could run `vc` from the command line just fine, when `make` ran `vc` for me, it wasn't properly expanding the %%VBCC%% variable, so I had to hard-code it. Not my favorite thing, but it's better than a sharp stick in the eye.

User avatar
Banshaku
Posts: 2377
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: VBCC Optimizing C-compiler now supports NES

Post by Banshaku » Sat Jul 25, 2020 8:12 pm

rox_midge wrote:
Sat Jul 25, 2020 7:47 pm
Although I can do the same thing, running the underlying `vbcc6502` and `vasm6502_oldstyle` commands in my makefile manually, but it appears that when `vc` is run with '-O3', it generates an opaque command script that it passes to `vbcc6502` using the '-cmd' option. I can't make `vc` show me what's in that script. But like I said, it's not a dealbreaker.
If you are very comfortable with make would suggest to skip the frontend and uses the compiler, assembler etc. The only thing at first is if you do yourself, you have to:

- compile the C file to ASM
- compile the generated ASM file to and object
- link the object to your nes file

so it does make things a little bit harder but it's not impossible.
rox_midge wrote:
Sat Jul 25, 2020 7:47 pm
I already had my own linker file, and wound up having to create my own config file, because something was causing the %%VBCC%% environment variable to not be available when running `make`. Although I could run `vc` from the command line just fine, when `make` ran `vc` for me, it wasn't properly expanding the %%VBCC%% variable, so I had to hard-code it. Not my favorite thing, but it's better than a sharp stick in the eye.
I don't have an example ready yet since I'm mostly porting some code and testing the results but I can share my current ld/makefile which uses segmets (just tested a few minutes ago and it's working well). Although complicated because of my current needs, it may help you figure out how to use the tools.

It uses ramseg instead of rawbin, which means it will split all segments (see it as a group of sections) into binary files and cat them at the end to create the final nes file. This means you need a header file too.

I could create a quick sample soon, maybe nrom would be easier at first. hope the current files helps.
Attachments
files.zip
(3.72 KiB) Downloaded 11 times

vbc
Posts: 40
Joined: Sun Jun 21, 2020 5:03 pm

Re: VBCC Optimizing C-compiler now supports NES

Post by vbc » Mon Jul 27, 2020 1:18 am

Banshaku wrote:
Thu Jul 23, 2020 7:36 pm
One thing I would suggest is even though the code at first was not public, the startup/banking code should be documented so that if people need to adapt they can do it on their own. I could figure it out (at the least the startup code) since I did once for cc65 but some people may have less experience with that. One example is the code for copying BSS data. Just reading the code I wouldn't have known it was for that since it's specific for vbcc.
I agree that code needs some comments.
I have a question regarding vasm and it may come from my lack of experience to uses many assemblers. When using vasm (I guess in old style), except for labels, everything has to be on something else than column 1. Is it for compatibility with older assembler?
Yes, many assemblers consider everything that starts in the first column as label, allowing labels without a colon.

This is legal with the vasm6502_oldstyle, but not with e.g. vasm6502_std:

Code: Select all

label
	jmp label
On the other hand, this is legal with vasm6502_std, but not with vasm6502_oldstyle:

Code: Select all

label:
jmp label
This is legal for both:

Code: Select all

label:
	jmp label
I'm porting one library but I used code that was so specific to ca65 that it's a little bit painful to port. I'm not used to old style syntax so I'm not sure how to use a struct.

In ca65, you could define a struct and use it to access offset at a ram address like this:

Code: Select all

	lda myVar+myStruct::myVal
but from reading the doc, I'm not sure if this is possible to do so. It seems possible to define a memory area and access with the symbols inside but not sure if it can be done that way. Is it? I need to test it but if it's possible, I guess it would be doable that way?

Code: Select all

 	lda myWar+myStruct.myVal
 
but there was no example in the doc, thus my confusion.
You can define and access a structure for example like this:

Code: Select all

        struct point
x:      dw 1
y:      db 2
        endstruct

s1:     point
s2 = $8000

        lda     s1+point.x
        lda     s2+point.y

Post Reply