|
Post by sunteam_paul on May 18, 2022 19:41:12 GMT
|
|
|
Post by DarkKobold on May 18, 2022 19:45:33 GMT
There's a pretty good reason for that, it's owned by the same person who refuses to take part in this forum, and also used their admin powers to nuke the entire PCEFX discord for "laughs." This is why public ownership is far better for long-term sustainability.
|
|
|
Post by dshadoff on May 18, 2022 19:54:32 GMT
This is my exact point. We have people joining daily, and it feels like there's a competition as to who's repo to use. That isn't fair to new people. Also, I'm not comfortable idea of starting anything public, like a wiki, on anyone's private github. Gredler is chomping at the bit to start contributing to a "public" wiki, but one doesn't exist for him to work on. Right... that's why we are trying to consolidate. Nobody's private GitHub repo - one that we all agree to push updates back into. The reason we got into this situation in the first place was because there was no efficient mechanism of merging changes, and no standard medium for hosting it... GitHub solves both of those things. Just be patient while we work through the steps to start. In the meantime, elmer had mentioned that there was existing documentation that appeared incomplete - if somebody is indeed eager to start, perhaps a set of missing pieces/discrepancies could be made locally, for integration when this is all in place.
|
|
|
Post by spenoza on May 18, 2022 19:58:58 GMT
I think it's nice that we're finally hearing about some of these plans, and I understand that it can be difficult to get people with strong personalities and their own ideas about things to come to a common vision and plan for something. It does seem like the org-style GitHub approach is a good way to do this. I do think there's a certain level of care and commitment necessary, and I hope that once things are settled the attitude of "OK, I did my part, now I'm done" doesn't take hold. I respect that people have lives and HuC is only a small part of that, but without some kind of commitment from all parties involved there's still a risk that there will then be simply another stalled repository of tools on the internet, albeit a more updated one. At the very least there should be a continuity plan in place to ensure there is at least someone active in the PCE space who can access materials and make decisions, even when others step back, and ideally this plan would keep any one person from being able to abuse the repository or other contributors, though I don't know what tools or methods exist to do that. I'm thinking back to a particular forum space and what happened when control was ceded to the wrong individual...
|
|
|
Post by DarkKobold on May 18, 2022 20:34:04 GMT
This is my exact point. We have people joining daily, and it feels like there's a competition as to who's repo to use. That isn't fair to new people. Also, I'm not comfortable idea of starting anything public, like a wiki, on anyone's private github. Gredler is chomping at the bit to start contributing to a "public" wiki, but one doesn't exist for him to work on. Right... that's why we are trying to consolidate. Nobody's private GitHub repo - one that we all agree to push updates back into. The reason we got into this situation in the first place was because there was no efficient mechanism of merging changes, and no standard medium for hosting it... GitHub solves both of those things. Just be patient while we work through the steps to start.In the meantime, elmer had mentioned that there was existing documentation that appeared incomplete - if somebody is indeed eager to start, perhaps a set of missing pieces/discrepancies could be made locally, for integration when this is all in place. This is great. I'm super excited for this, and I think it will be a huge benefit to the entire community. Let me know if I can help. One of the big problems with local copies is what I ran into. I started converting Archaic Pixels into an accelerator/autocomplete-ready format, so HuC would integrate with Visual Studio Code. It's now sitting on a dead SSD I have to send off and spend big $$ to get fixed. That's more a DK problem, however. I'm sure others probably have better backup solutions.
|
|
|
Post by elmer on May 18, 2022 21:11:01 GMT
Also, I'm not comfortable idea of starting anything public, like a wiki, on anyone's private github. Gredler is chomping at the bit to start contributing to a "public" wiki, but one doesn't exist for him to work on. Then, if he doesn't want to use my repo, or turboxray 's repo, he can just fork whoever's repo he likes, and start creating a wiki there on his own github repo. If he makes his wiki publicly writable, then everyone who is interested can edit it. Or he may choose not to. There is no reason to wait around for the organization to be created, it will be able to use the existing github tools to import his wiki when they're ready.
|
|
|
Post by gredler on May 18, 2022 23:49:49 GMT
When I go to that site I get warnings from my anti-virus and web browser both that it's unsafe, and I am not seeing any way to modify / upload stuff to it. Also, is it linked from the pce bible page proper or stickied/promoted on these forums? I know arkhan made a wiki for himself but haven't seen it posted anywhere besides discord or made editable besides by the individuals he has approved to be allowed to edit. In the meantime, elmer had mentioned that there was existing documentation that appeared incomplete - if somebody is indeed eager to start, perhaps a set of missing pieces/discrepancies could be made locally, for integration when this is all in place. In the interim maybe we can just make a live editable document on Google docs that we can all work on until the unified git is made? I will start researching gitwiki formatting and hopefully can work offline and when it comes online we can just copy paste to it
|
|
|
Post by elmer on May 20, 2022 14:29:17 GMT
I know folks are working (or were working) on their own directions, but it would be nice to have agreement all around on a core branch to merge to that's considered stable and establishes a compatibility point with a solid enough development flow that adding features later doesn't threaten to break old code (within reason). Getting this sorted-out is one of the core-tasks of trying to accomplish the transition to an "organization". But please understand, that in order to allow for future growth of the toolchain, there will likely be a couple of small changes that users will need to be aware of. The most-obvious change that is likely, would be to rename HuC's "huc/include/pce/" to (possibly) "huc/include/huc4/". That would allow different languages and versions of the PC Engine library code to co-exist within the same basic structure, and help to get us all passed the divergences that Uli made (and that I have continued), which unfortunately split the previously-happy HuC v3.21 developers from those who were willing to try Uli's improvements. If that change is made, then all HuC users will need to edit the PCE_INCLUDE line in their build-scripts to reflect the new name. That is all that it should take, but it is probably best to finally acknowledge that it may well have been beneficial if Uli had called his updates "version 4" rather than keeping the "version 3" name that seemed to annoy some old HuC v3.21 users. Another deliberate change that may break some existing code, although I'd be very surprised, is that PCEAS now allows for more of the standard-C "escape sequences" in strings and character constants, which makes it more compatible with modern development tools, and other programming languages. C's "escape sequences" are the "\n", "\r", "\\", etc, in strings and character-constants. PCEAS was previously both inconsistant, and non-compliant, in its behavior of the character "\" followed-by-another-character, but now it is much closer to standard-C behavior, and only missing the ancient octal syntax, and the fairly new Unicode syntax, neither of which are (currently) particularly relevent for PC Engine programming. The downside is that #'\' is no longer legal in PCEAS, and it must be replaced by the standard-C syntax #'\\'. The other thing is that previous use of the '\' character in strings may break, because the new PCEAS parser recognizes more of the standard-C escape sequences than the old PCEAS parser, and it follows standard-C practice of rejecting unknown/illegal escape sequences. I'll be really surprised if *anyone's* assembly-language source-code actually breaks in practice, but folks should be aware of the change, and of the compatibility improvement that it brings for the future.
|
|
|
Post by dshadoff on May 20, 2022 14:38:37 GMT
Just wanted to say that octal representation could very well be relevant in the PCE context, when specifying palette colors… but don’t take this as a request for implementing it.
|
|
|
Post by elmer on May 20, 2022 14:53:24 GMT
Just wanted to say that octal representation could very well be relevant in the PCE context, when specifying palette colors… but don’t take this as a request for implementing it. Hahaha, "yes", I did think about that usage as I was writing the post, but since strings and character-constants are inherently 8-bit and not 16-bit at this time, I don't believe that the sytax would benefit us ... yet. Perhaps I'm missing something. Now, as soon a someone chooses to add support to PCEAS for 16-bit strings, then things like the octal syntax, the Unicode syntax, and SJIS all become intriguing possibilities, and the ".encoding" pseduo-op that I had to bring in from KickAssembler may find a useful meaning!
|
|
|
Post by elmer on Jun 18, 2022 19:22:31 GMT
HuC, PCEAS, and ISOlink have all been advanced to version number v4.00 to mark a recent change in HuC's startup code that may break things for assembly-language CD developers who use the default PCEAS and ISOlink settings.
Over the years, different versions of the HuC and MagicKit assembly-language startup code have changed where the System Card's CD boot sequence jumps to in order to execute the HuC/MagicKit game.
As long as developers used HuC or MagicKit, the changes didn't really effect them, because even though the addresses changed, the tools and libraries always stayed together.
Well, once-again the startup address has changed, and HuC users shouldn't see any difference.
Any assembly-language developers need to know that PCEAS and ISOlink default CD boot parameters are now ...
1) the game code starts running at $4000 (instead of $4070). 2) the initial MPR settings are now banks $FF,$F8,$80,$81,$82,$83,$84,$00 (instead of $FF,$F8,$80,$81,$82,$83,$80,$00).
The new settings make a lot more sense as a "generic" startup environment for assembly-language, KickC, and even HuC moving forward, and they should help to allow for multi-language projects in the future.
Another thing that helps to make that possible is that HuC CD overlay programs are now marked with the string "HuC" at the beginning of the overlay (just after a JMP instruction).
Assembly-language developers are still able to change the CD startup parameters to whatever they like, with the command-line options that were added a year-or-so ago.
|
|
|
Post by elmer on Aug 20, 2022 0:29:55 GMT
It's been a while since this thread was updated, and I suspect that most folks here don't browse the github HuC repository regularly.
So I thought that I'd just come in and say that progress on my new assembly-language libraries for asm and KickC continues, and that there are now assembly-language libraries and examples for initializing and accessing the PCE's CD-ROM without using the System Card, and for playing back HuVIDEO (from Hudson's GulliverBoy game CD).
Please understand that these new libraries are NOT intended for use with HuC!
|
|
|
Post by elmer on Nov 13, 2022 15:05:51 GMT
Just letting folks know that there have been a few important bug-fixes in HuC recently, and that the builds on github now include automated version number increments so that you know what version you're running. Here the recently-updated cumulative change list for this year's fixes and updates ... 2022-11-09: -----------
All HuC project tools ... ------------------------- - Bump all HuC programs up to verion number 4.00.xx after the changes. The version number now comes from tags in the GIT repository, rather than being defined in each individual program.
HuC changes ... --------------- - Change the "include/pce" directory name to "include/huc" in order to differentiate it from the old MagicKit library name, because the HuC libraries are not compatible with pure assembly-language development. - Change "-v" argument to behave like HuC v3.21, which means that HuC always asks PCEAS to generate a list file by default, and "-v" will output extra information. - Change "-t" argument to warn that outputting C source to the listing file will disable some code opimizations which can then cause huge C functions to break because they exceed 8KBytes in length. - Add "-O" to the PCEAS command line to enable procedure-packing. - Change startup.asm to boot CD programs at $4000 (instead of $4070), and add a "HuC" string into the programs so that overlays can be identified. - Remove HuC's 2nd (and never used) library font in order to save space. - Change ac_cd_xfer() to use ISOlink's file# instead of sector numbers. - Add lib_exclude.asm to allow a HuC project to customize library settings. - Add Dave Shadoff's old example project that shows how to use CD overlays. - Fix startup.asm when running an SCD program on System Card 2 (or lower). - Fix satb_update() bug.
ISOlink changes ... ------------------- - Add "-sgx" CLI parameter to put a SuperGRAFX string into CD-ROM projects. - Slight changes to the CLI format to allow HuC users to name CD projects. - Change sector location and format of the directory information. - Change HuC location for patching directory info into HuC projects. - Change default startup location for HuC projects. - Add support for creating bootable PC-FX CD-ROMs.
PCEAS changes ... ----------------- - Add a list of procedure sizes to the listing file if list_level >= 2. - Fix PCEAS crash when it processes a .DS with a negative value. - Improve the error messages and information dumps when there isn't enough ROM space for all of the user's HuC or ASM procedures. - Allow KickC to run multiple passes to resolve forward-referenced symbols. - Fix some data directives not expanding the ROM size during early passes. - Enable JMP from one procedure to another to allow tail-call optimization. - Enable expression evaluation to be used in CALL pseudo-op. - Change default procedure packing to match PCEAS v3.21, use "-O" for enable the newer optimized procedure packing. - Fix procedure relocation from breaking some code declared after procedures. - Support more C escape-code sequences in strings and char constants. - Add "-sgx" CLI parameter to put a SuperGRAFX string into CD-ROM projects. - Fix 6502 undocumented "lax abs,y" instruction. - Allow .EQU and .RSSET values to use "$xx:xxxx" to specify bank and addr. - Fix zero-byte procedure relocation when at the end of a bank. - Fix operator precedence of unary "<" and ">".The latest automated-build can be downloaded here.
|
|