nesdev.org

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.

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.

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.

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?

thank you again for answering my questions.

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.

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.

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.

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.

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.

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

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.

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.

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.

	lda myVar+myStruct::myVal

 	lda myWar+myStruct.myVal
 

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

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.

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

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.

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.

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.

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

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.

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

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.

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.

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

label
	jmp label

label:
jmp label

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.

        struct point
x:      dw 1
y:      db 2
        endstruct

s1:     point
s2 = $8000

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