|
Post by dshadoff on Feb 8, 2021 16:25:28 GMT
Hi elmer, I forked your HuC repository the other day... I had to make some updates in order to get it to compile on the 2020 version of GCC (version 10). These were needed for both linux and MSYS2. ...Are you OK for me to submit a pull request with these updates ? (I didn't add any feature updates; just things required in order to fix compile). I don't want to further fragment the sourcebase, but my repo is here (you can see the commit history): github.com/dshadoff/huc
|
|
|
Post by DarkKobold on Feb 8, 2021 21:49:18 GMT
There's also turboxray's fork of elmer's. Maybe you could update that one?
|
|
|
Post by dshadoff on Feb 8, 2021 22:01:03 GMT
I'm aware that there are several forks, but: - MonstersGoBoom has put that fork into Archive mode (no further updates) - I'm not clear on the additional enhancements added by each of Monstersgoboom, turboxray, and Mooz... turboxray has a set of commits trying to integrate Mooz's, but then apparently rolling them back, so I'm hesitant to fork off of any of those at this time. - At the moment, I really only wanted a compiling version of PCEAS, to bring some older code up to date (not to take advantage of new features).
Any of those repos are welcome to take a look at what I needed to implement inorder to get a compile on gcc 10 .
|
|
|
Post by turboxray on Feb 9, 2021 0:06:01 GMT
turboxray has a set of commits trying to integrate Mooz's I did revert them. His PCEAS changes are from an older fork and so need much more time to bring in (even line by line, it wasn't apparent when I brought them in). MooZ's changes came out of his work for his HuDK project afaik. I think elmer has moved on from PCE stuff. My repo's difference from elmer's should only be in the HuC side. I don't remember needing to modify anything recent in PCEAS. I have video and sound upgrades that are going into HuC, and it needed some premilitary ground work in order to facilitate library bank 1 appending. DK has been using those changes from my my repo build.
|
|
|
Post by dshadoff on Feb 9, 2021 3:00:26 GMT
I suspect that elmer is taking a break, but I don't think that he's moved on... But at the same time, I'm not sure how interested he is in accepting pull requests on those repos.
But don't worry, my fixes are so minimal as be insignificant. (This is really more a situation of reminding the repo owners to keep up with the changes required by gcc)
|
|
|
Post by elmer on Feb 9, 2021 5:26:43 GMT
I suspect that elmer is taking a break, but I don't think that he's moved on... But at the same time, I'm not sure how interested he is in accepting pull requests on those repos. But don't worry, my fixes are so minimal as be insignificant. (This is really more a situation of reminding the repo owners to keep up with the changes required by gcc) I'm not permanently gone ... just resting. "Yes", I should check all of my github repositories and see what the latest version of GCC has gone and broken. Pull requests have always been welcome! Just understand that I tend to rework stuff if it isn't done in a way that I believe is best. For instance ... someone wanted me to accept a pull request that just switched off a bunch of compiler warnings-as-errors, when my preference is to actually look at and fix the source code, and to only ignore warnings if there is no sane way to fix the code itself. As for HuC, I have been "in the middle" of making some serious changes to the HuC overlay system for about a year now, because I want both PCEAS and ISOLINK to be more usable for assembly-language programmers, i.e. none of the hard-coded HuC overlay list, or the assumption that CD programs start at $4050 (or wherever it is). From an assembly-language programmer's POV, the PCEAS and ISOLINK changes were stable early last year, but HuC was fighting me and so I took a break ... and still haven't got back to it. Apart from that ... you're all correct in that I have gotten a bit tired of being the "prime" HuC maintainer, and I would be quite happy to pass that off to turboxray or someone else. I have accomplished my aim of making sure that Uli's excellent work in upgrading HuC didn't get forgotten, and that it had gotten to a stable and usable level. Apart from that, I would like to keep my future changes to bug fixes ... some of which I do need to still apply to the code in gihub.
|
|
|
Post by dshadoff on Feb 9, 2021 5:50:52 GMT
OK, I'll see if I can send the pull request your way in the next day or two. I don't mind if they're reworked - the fixes were just to get it to compile.
I should warn you that one of the items in my pull request was to switch off one of the warnings-as-errors. ...but that's because it simply won't compile on linux. gcc on linux complains a lot harder than gcc on MSYS2 in Windows, which is what was must have been used to compile it. (the dozens of warnings still show during compile though, and I agree that they should be fixed eventually.)
If you and turboxray are looking to "pass the baton", I wonder if there's some orderly way to reconcile the in-progress changes...
My own interest was trending toward assembly, and maybe I'm getting ready to start using the assembler again to write something (and of course, fix any bugs in the assembler which pop up).
|
|
|
Post by elmer on Feb 9, 2021 6:16:24 GMT
I should warn you that one of the items in my pull request was to switch off one of the warnings-as-errors. ...but that's because it simply won't compile on linux. gcc on linux complains a lot harder than gcc on MSYS2 in Windows, which is what was must have been used to compile it. (the dozens of warnings still show during compile though, and I agree that they should be fixed eventually.) I have a really *nasty* memory coming back of working on a fix for some serious GCC warning/error about HuC's code putting pointers in integer variables, which is something where Windows and Linux act differently because of the size of a long-long ... or something horrible like that. I hope that that's not what is tripping up GCC now, because IIRC, the fix meant changing pretty much every single HuC source file. My own interest was trending toward assembly, and maybe I'm getting ready to start using the assembler again to write something (and of course, fix any bugs in the assembler which pop up). Nice! I really still see the PCE as an assembly-language programmer's machine. Doing some Z80 work recently has made me feel even fonder about the HuC6280 processor and the PCE's architecture.
|
|
|
Post by dshadoff on Feb 9, 2021 13:22:13 GMT
No, it's not that bad, but it's not a traditional "error".
linux needs: CFLAGS += -Wno-error=unused-result and of course to assign a lvalue to any such statements if you want to get rid of the warnings. But seeing them as warnings is the only way you'll be able to size the effort of fixing them all.
These are lines like: fwrite (blah, blah, blah); ...without looking at the return code.
...And gcc 10 (new install of MSYS2 on Windows) now appropriately shows an error due to duplicate definition in mod2mml - need to change mod2mml line from: const unsigned char standard_waves[45][32]; to extern const unsigned char standard_waves[45][32];
I'm not sure why this one wasn't always showing up as an error.
I also stuck in some .gitignore lines for the partial-build stuff.
|
|
|
Post by DarkKobold on Feb 9, 2021 16:20:31 GMT
It would be good to get things merged into one branch - turboxray has been making improvements to HuC, and that's the version Gredler and I are using.
We've also been talking a lot about a HuC version 4.0 - One of HuC's biggest issues is the fact that it comes wholesale - you have to include a bunch of stuff in your projects whether you want it or not. Things like the default font, the pixel-based drawing routines, and etc. For most projects, the few extra K of space doesn't matter, but with JJ it became problematic, and I had to go cutting into HuC considerably. A modular library approach would help save space.
|
|
|
Post by spenoza on Feb 9, 2021 16:28:19 GMT
I really think HuC should have more than one maintainer instead of each individual having a different fork. People get busy and this isn't like some huge open source project where a maintainer can do it as part of their job. That way if someone has to really step away other improvement can continue to feed into HuC without people having to determine which of 5 or 6 different HuC releases they should be using. I'm not saying there aren't reasons to fork and maintain different versions. There are indeed legitimate reasons to do so, of course, but I'm not sure I'm seeing that here, really. The three of you work together pretty well when you need to communicate back and forth.
|
|
|
Post by elmer on Feb 9, 2021 23:34:15 GMT
No, it's not that bad, but it's not a traditional "error". linux needs: CFLAGS += -Wno-error=unused-result and of course to assign a lvalue to any such statements if you want to get rid of the warnings. But seeing them as warnings is the only way you'll be able to size the effort of fixing them all. Yuk! Yeah, that's one where I think that it may well be best to just disable the warning/error, at least for now. The current version of Debian 10.8 (in my virtual machine) is still stuck on the old GCC version 8.3, so I'm not seeing that error. What file needs to have that flag added? Is it src/Make_src.inc? ...And gcc 10 (new install of MSYS2 on Windows) now appropriately shows an error due to duplicate definition in mod2mml - need to change mod2mml line from: const unsigned char standard_waves[45][32]; to extern const unsigned char standard_waves[45][32]; OK, I can see that, and have changed it in the source on my machine. I'll wait to push it to github until I know where to add the change to CFLAG.
|
|
|
Post by elmer on Feb 9, 2021 23:46:58 GMT
It would be good to get things merged into one branch - turboxray has been making improvements to HuC, and that's the version Gredler and I are using. We've also been talking a lot about a HuC version 4.0 - One of HuC's biggest issues is the fact that it comes wholesale - you have to include a bunch of stuff in your projects whether you want it or not. Things like the default font, the pixel-based drawing routines, and etc. For most projects, the few extra K of space doesn't matter, but with JJ it became problematic, and I had to go cutting into HuC considerably. A modular library approach would help save space. Uli already added the capability for assembly-language source code "libraries" into HuC, but then he didn't actually chop up all of the old BANK1/BANK2/BANK3 library functions into separate assembly files for functionality ... probably because it would break compatibility with existing HuC projects.
|
|
|
Post by dshadoff on Feb 10, 2021 1:46:12 GMT
linux needs: CFLAGS += -Wno-error=unused-result Yuk! Yeah, that's one where I think that it may well be best to just disable the warning/error, at least for now. The current version of Debian 10.8 (in my virtual machine) is still stuck on the old GCC version 8.3, so I'm not seeing that error. What file needs to have that flag added? Is it src/Make_src.inc? Yes, that's the file. Oddly, my Ubuntu (from an old install, admittedly) is at gcc 7.5.0 and gave that error. ...And gcc 10 (new install of MSYS2 on Windows) now appropriately shows an error due to duplicate definition in mod2mml - need to change mod2mml line from: const unsigned char standard_waves[45][32]; to extern const unsigned char standard_waves[45][32]; OK, I can see that, and have changed it in the source on my machine. I'll wait to push it to github until I know where to add the change to CFLAG. Cool. I won't need to send a pull request then. But I suggest that: 1) You create a .gitignore file (my example is at github.com/dshadoff/huc/commit/ddba97cba6a94e9d8786305ec3f7354890a5655d) 2) It would be nice to provide binaries so people don't need to figure out how to compile it, if they just want to use it.... Dave
|
|
|
Post by DarkKobold on Feb 10, 2021 2:28:23 GMT
It would be good to get things merged into one branch - turboxray has been making improvements to HuC, and that's the version Gredler and I are using. We've also been talking a lot about a HuC version 4.0 - One of HuC's biggest issues is the fact that it comes wholesale - you have to include a bunch of stuff in your projects whether you want it or not. Things like the default font, the pixel-based drawing routines, and etc. For most projects, the few extra K of space doesn't matter, but with JJ it became problematic, and I had to go cutting into HuC considerably. A modular library approach would help save space. Uli already added the capability for assembly-language source code "libraries" into HuC, but then he didn't actually chop up all of the old BANK1/BANK2/BANK3 library functions into separate assembly files for functionality ... probably because it would break compatibility with existing HuC projects. Which is why a version break to 4.0 would be the best time to do that. turboxray has added a lot of functionality we use, and is adding more. It'd be best to be able to pick and choose functions moving forward.
Some of the functionality that's been added -
|
|