-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
default_arm7: build options to include dswifi, maxmod, libxm7 #248
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing the path of the default ARM7 is going to cause a lot of people to complain. This PR would need to preserve the path and add the other elf files to the same folder.
Regarding the FIFO channel for LibXM7, I think it's fine this way. If someone doesn't like it, they can have a custom ARM7 core and change it.
} | ||
|
||
int main(int argc, char *argv[]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I would leave this the way it was before, even if it's unused. It may be useful some day, and it's better to leave the arguments there because people tend to copy the example code right away and forget about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-int main(void)
+int main(int argc, char *argv[])
{
+ // Unused variables
+ (void)argc;
+ (void)argv;
+
// Initialize sound hardware
-int main(void)
+int main(int argc, char *argv[])
{
// Initialize sound hardware
Which one of these would be preferred? The first one avoids unused variable warnings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to silence the warnings, go ahead (even though by default in the Makefile they aren't enabled, so they probably only appear in your setup).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
argc/argv is not implemented and will probably not be implemented on ARM7, so providing it in the main()
function signature feels a little deceptive/misleading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, fair enough, we can leave the arguments out. We can change it back if they are used for something at some point.
How should they be named? I assume the maxmod+dswifi combo should stay arm7.elf, should it also have a copy with a more descriptive name like "arm7_wifi_maxmod.elf", then for the others "arm7_maxmod.elf", "arm7_wifi.elf", "arm7_wifi_libxm7.elf", etc?
I think it might be surprising to newcomers for a user channel to be used for audio in the builtin arm7. If I'm not mistaken the maxmod channel would be unused when libxm7 is in use, so that one could be used (unless we want to support both libraries in the same binary?); perhaps it would need a rename to "FIFO_MAXMOD_LIBXM7" with a alias of "FIFO_MAXMOD" for compatibility, similar to the FIFO_STORAGE/FIFO_SDMMC. |
Well, there are a few options:
The problem was reserving one channel for Maxmod, not the fact that LibXM7 is using an user channel. If anything, we should add a new alias such as ´FIFO_MUSIC_PLAYER |
I like keeping build artifacts under
Realizing now that the user channels would only be used if the arm7 was overridden anyways, so it would make sense to use a configurable user channel for libxm7. Does maxmod hardcode channel 3? If not, maybe FIFO_MAXMOD could just be made into an extra user channel and be used in the default_arm7 for maxmod so that it can be overridden like libxm7 (I guess this would be a separate issue though). |
I think that the main problem here is that
Now the problem is where to keep the In order to keep compatibility with the old path, we can have If we had this:
We would have to copy files with a Makefile to the parent folder of the Makefile, which isn't very logical.
It is hardcoded, yeah: https://github.com/blocksds/maxmod/blob/852f36750c733000a55693dff0b467e4a6e2658e/source_ds9/mm_main9.s#L19 Hardcoding this in libnds and maxmod was a bad choice, I agree. |
What if it is structured like this:
This would be flexible enough to add new cores in the future and allows the cores to be configurable, without duplicating main.c |
Yeah, I think that works for me! |
bf7e423
to
9868ad2
Compare
9868ad2
to
c79f1fc
Compare
I tested this and it seems to work with the libxm7 examples after replacing the custom arm7 with the main_core |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how this looks now, fix the few issues I've mentioned and this is good to go.
install: all | ||
@echo " INSTALL $(INSTALLDIR_ABS)" | ||
@test $(INSTALLDIR_ABS) | ||
$(V)$(RM) $(INSTALLDIR_ABS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need -rf
here: $(V)$(RM) -rf $(INSTALLDIR_ABS)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe $(RM)
expands to rm -rf
throughout all the Makefiles that define it
I think we just have to document how to use this. We could make a change to all makefiles and add an
This way, old makefiles will still work, and people can choose to update them or not. |
…arm7 core for arm9-only projects
@@ -197,7 +199,7 @@ endif | |||
$(ROM): $(ELF) | |||
@echo " NDSTOOL $@" | |||
$(V)$(BLOCKSDS)/tools/ndstool/ndstool -c $@ \ | |||
-7 $(BLOCKSDS)/sys/default_arm7/arm7.elf -9 $(ELF) \ | |||
-7 $(ARM7ELF) -9 $(ELF) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these templates supposed to include a copy of all the default_makefile code or is this supposed to look more like the examples/ where there is a include for the boilerplate?
Decided to take a stab at #242. I haven't tested this code much besides compiling, so it may not be quite ready to merge.
This changes the output path of the binary from "arm7.elf" to "$(BUILDDIR)/arm7.elf", which might have to be accounted for elsewhere. I'm not sure how to go about changing the default Makefiles for this, since it currently leaves no options to disable maxmod or dswifi (should there be more Makefile templates? options within the current templates?)
I wasn't entirely sure what FIFO to use for libxm so I copied the one from the examples (user 7, ie channel 14) which is less than ideal. Assuming maxmod and libxm7 cannot be mixed together, maybe the FIFO reserved for maxmod can be used (channel 3)?
In the Makefile, the DEFINES were originally only being passed to LDFLAGS and not CFLAGS/CXXFLAGS/..., I think that was a bug so I added them to the other flags as well (although no defines were used before so it didn't make a difference)