|
Post by turboxray on Oct 25, 2019 8:35:47 GMT
I'm just curious if some of the tools and PCE libs I wrote are still around, or do people use them or have used them?
Namely, PuCrunch (for pceas and huc), some fmp map converters, some image converters/helper tools, some other PCE converted decompressors (aplib, packfire, etc), cribsheets, fastload CD read routine ripped from late gen PCE games. I just checked yesterday and it looks like my old NAS has pretty much everything on it still. I can't remember all that I've got (there's a lot of PCE related junk.. like 28gigs of stuff).
Also, not that anyone wants to hear this haha, but I fell in love with Lex and Yacc while making a "C--" compiler in my senior year (compiled down to MIPS). Love that idea of a C syntax tree and an intermediate code syntax tree too (three address-code quadruples). Grammar production rules can be a lil bit tricky, but once you have stuff working it's pretty easy to add new syntactical stuff (I did my semantic checking once the C syntax tree was build). The whole time during the class, I thought it would be great to make a C style language for the PCE (or just some C variant itself). That, or modify HuC to have an option to build out a C syntax tree for another tool to take it from there.
|
|
|
Post by ccovell on Oct 25, 2019 14:49:49 GMT
Back in 2007-2008, I took your PuCrunch libraries, and modified them to work with ROM-only projects. I don't remember if I did any other enhancements, like do Sprite Tile decrunching, which had been missing. I forget, sorry.
I also didn't really do anything else with it since "8 Megabits (hucard) should be enough for everyone."
Anyway, the files are still up on my site:
|
|
|
Post by Arkhan on Oct 25, 2019 15:02:44 GMT
I don't think anyone is using your FMP converters because we have all grown to hate mappy and don't use it anymore. I switched to Tiled.
I wasn't aware of all of these other things though. Where were they? I guess I never really googled too much and didn't have a need for compression.
The image converters might have been neat! ..maybe I saw/used them.
|
|
|
Post by turboxray on Oct 26, 2019 7:39:44 GMT
Hmm okay. I'll find some place to host some files and throw them up with some links.
Yeah, I used Tiled a couple of years ago to make a Pokemon RPG game for software engineering class. It was pretty nice tool.
|
|
|
Post by elmer on Oct 26, 2019 23:05:36 GMT
Namely, PuCrunch (for pceas and huc), ..., some other PCE converted decompressors (aplib, packfire, etc), ... If you've already done a version of PuCrunch for HuC, then could we perhaps include it into the current HuC so that DK & Gredler can use it for Catastrophy? I'd be interested to see your aplib decompressor, I didn't know that anyone else had done a version for the PCE ... we can compare code! ;-) github.com/jbrandwood/aplpakIn my tests with the LoX data, PuCrunch and Aplib were basically neck-and-neck, and I ended up choosing Aplib for future projects based on the simplicity of the decompressor. Also, not that anyone wants to hear this haha, but I fell in love with Lex and Yacc while making a "C--" compiler in my senior year (compiled down to MIPS). Love that idea of a C syntax tree and an intermediate code syntax tree too (three address-code quadruples). Grammar production rules can be a lil bit tricky, but once you have stuff working it's pretty easy to add new syntactical stuff (I did my semantic checking once the C syntax tree was build). The whole time during the class, I thought it would be great to make a C style language for the PCE (or just some C variant itself). That, or modify HuC to have an option to build out a C syntax tree for another tool to take it from there. Well, that sort of stuff fascinates me! ;-) Although I've never really loved Lex and Yacc, and prefer the far-less-common Coco/R, primarily for the simplicity of debugging stuff in a recursive-descent system rather than Yacc's table-based system. I don't have the passion by myself to start something from scratch, but the idea of porting SDCC to the 6502 does still have some small appeal. There are a couple of simple, and fairly obvious (in hindsight), rearrangements to the fundamentals of HuC's and CC65's code generation that would make a huge difference to the quality of the code that they could produce. Once I realized that the changed scheme also works on the original NMOS 6502, and so applies to the active NES, C64 and Atari communities, then the idea becomes even more appealing. But then again ... I can happily program any of those machines assembly-language, and I have a ton of other competing calls on my time, so why bother?
|
|
|
Post by turboxray on Oct 28, 2019 20:48:55 GMT
Well, that sort of stuff fascinates me! ;-) Although I've never really loved Lex and Yacc, and prefer the far-less-common Coco/R, primarily for the simplicity of debugging stuff in a recursive-descent system rather than Yacc's table-based system. coco/R uses LL parsing? I've never used LL before. I had some issues like the below rule that I made for chaining variable declarations: Declaration: Type Var_decl ';' { // code } | Type Var_decl error { // code } ;
Var_decl: Var_decl_type { // code } | Var_decl_type ',' Var_decl { // code } | Var_decl_type ',' error { // code } ;
Var_decl_type: ID { // code } | ID '[' NUM ']' { // code } ;
So something like "int x,z,y, a[2];" for the above rule, the parser builds the tree from the bottom up; 'a[]' becomes a child of 'y', which is attached as a child to 'z', etc all the way up to 'x' (because of the recursive rule). But I want z, x, y, and a to be siblings. So I had create a parent node when it hits 'a[]' (because that's the end of the rule match), and as it works backwards on the match, I keep attaching the children to the temp parent node. When I finally got back up to 'type', I set its node to the temp parent, and then reset the temp parent back to null. I couldn't initially create the temp parent node at "Type Var_decl ';'" when it starting the match, because Yacc won't execute code associated on a partial match (it does so on the way back up the tree). What would that grammar look like for LL? I like the idea of HLA (high level assembly language) for non-critical parts of an ASM project. I did a lot of complicated stuff with macros, so it got me thinking why not a simple inline "C" for ASM? Or maybe a struct style data structure for ASM with dot operators? I dunno. I don't want to mess with PCEAS for that, so making a pre-processor with grammar rules would be a lot of fun!
|
|
|
Post by elmer on Oct 28, 2019 22:44:01 GMT
|
|