rainwarrior wrote:You don't have to.
I guess that CA65 is flexible enough that you guys that are used to it can come up with creative ways to do things, but to me this model is still a bit alien. I don't know how much you can bend the rules.
It was a solution I thought was perfectly fine, as my fixed bank code almost never changes, and of course, if I ever added too much to it, I'd get a linker error preventing me from compiling a bad ROM. If I wanted, I could also produce an error if there was any space left (.error directive allows you to make custom errors); I could even have the error tell me exactly what number to change it to take up the empty space.
Yes, it works... I can certainly adjust the size near the end of development to create a perfect fit, but this goes against the fluidity I'm going for. My main goal is to prevent changes from creating the need to change something else, whenever possible.
I don't think there's an "align to end" feature, but there might be a way to import the segment size for use in linking somehow. I don't have a ready made solution for you that does exactly that, would take some digging to discover a good method, maybe. I don't know off the top of my head, sorry.
If you do ever find out, please do share.
Why exactly do you need "align to end"?
It's not that I absolutely need it, I just want things to be fluid from the very start, and I can just add code and data to the correct places without having to manually tell the assembler how big these places are. This would make it easier to reuse a template for different projects, for example.
How do you accomplish "align to end" in ASM6, by the way?
Code: Select all
.org $10000 - (BlockEnd - BlockStart)
I guess it works because even though the assembler doesn't know the final values of BlockStart and Blockend, it can still calculate the difference because it knows the size of the code between them.
I think I already said this, but you can use :: to specify the scope of a label from another scope.
So I would scope all instances of the repeated code and name only one of them, and I'd use that to access the labels inside?
[/quote]If you're talking about one scope per bank[/quote]
One scope per bank was a bad idea I guess, considering that I need to have parts of the same sub-system (video, audio, etc.) scattered across different banks, and it would be silly to break up the sub-systems like that.
If you don't like having to export or import things at all, you can just go back to putting everything in one big assembly too. That still works fine.
I guess I'd be more comfortable with that, and making use of scoping to deal with the repeated code.
I'm not entirely certain what situation you are describing. Does your main engine really need to know about hundreds of different pointers to animation data? That seems to imply that every animation has unique code in the main engine that refers to its specific data. If that's the case, why not just include that data in the same assembly as that code?
Sorry, I guess I didn't explain it well. Say that in banks that contain CHR data I use labels to identify the tiles that belong to each animation frame. Then, when the game engine is processing animation, it will need access to these labels to set up the pattern transfers that will copy the tiles to VRAM. Now that I realized that one assembly per bank would be a bad idea in my case, I guess this won't be a problem, since I can indeed have everything related to the animations in the same assembly.
The primary use of import and export is for function labels. You can use it for data labels too, if you need to, but I usually find that data is consumed in one place and doesn't need to be available globally? You can also use import and export for constants and enumeration values, if you want to, but I would likely just create a common header file for these, like I would normally do in C.
That makes sense. I guess I just have to get more used to this model of programming.