PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: Bonknuts on August 15, 2016, 02:31:01 PM
-
https://github.com/uli/huc
So is anyone interested in using this?
On a side note:
I downloaded the source and tried to compile it under gcc using code:blocks, but it errors out on fmemopen() reference. I looked it up, and according to gnu it's part of stdio.h (http://www.gnu.org/software/libc/manual/html_node/String-Streams.html). But when I look at stdio.h from mingw include folder, fmemopen (as well as open_memstream) is not declared in the file. Why would mingw exclude this in stdio?
Update:
Commenting the fmemopen reference...
/*if (!data)
data = fmemopen(data_buf, DATABUFSIZE, "w");
if (!rodata)
rodata = fmemopen(rodata_buf, DATABUFSIZE, "w");
*/
And it compiles without problems. Just need to figure out how to re-implement fmemopen in mingw.
-
But when I look at stdio.h from mingw include folder, fmemopen (as well as open_memstream) is not declared in the file. Why would mingw exclude this in stdio?
Presumably because it's of limited practical-use, and can be replaced reasonably-easily where it has been used ... which it obviously isn't in the hundreds of packages that mingw-w64 does support.
It was a bit lazy of Uli to use it, but he did, and now it's up to someone else to fix it if they don't want to compile under cygwin on Windows.
It's just being used to buffer and rearrange different sections in the HuC output. That's something that Uli added, and it wouldn't be too tough to implement the same functionality in a different way that didn't need fmemopen().
BTW ... I'd recommend using Artemio's fork-of-Uil's-fork rather than Uli's version. Artemio fixed a few things after Uli stopped working on it.
You may have missed my cygwin build of it here ...
HuC - Newbie questions?
http://www.pcenginefx.com/forums/index.php?topic=21136.msg461615#msg461615
It's definitely a little better than the old HuC ... but not leaps-and-bounds.
To be blunt ... no matter how much lipstick you put on the pig, it's still a pig.
HuC was wonderful for its time ... but it's architecturally hamstrung because of its Small C origins.
Eric Petrich (the SDCC developer that I've been working with) recently "went public" and created a new SDCC branch in the main SDCC codebase on SourceForge for the new 6502 compiler port.
Since he's actually one of the main SDCC developers ... that means that it's all going to eventually get rolled into the main SDCC codebase when it's finished.
But, to be honest, I've haven't been as active as I should be in helping him get the SDCC port done.
It's my current task to add 6502 support to the ucsim simulator that's going to be used for automated-testing of the 6502 port, but I've been too busy with the Xanadus, and PC-FX GCC, and now in preparing to disappear into the desert for a week.
IMHO ... if you want to take the time to try to improve C on the PCE, then may I suggest that you consider helping out the SDCC port rather than applying yet-another layer of small fixes to HuC?
-
To be blunt ... no matter how much lipstick you put on the pig, it's still a pig.
Well, I was thinking of a new different shade of lipstick; Objective Small C. Ok, maybe not as advance as the original pre-processor of Objective C, but something along the lines of it. Something to toy with for a future class project.
-
I've used it for about a year now. I use Cygwin for compiling and you can use the compiled exe without Cygwin later, just need to have a cygwin dll copied alongside the exe files.
I would not have started doing PCE homebrew without this fork.
-
So, I'm using "vanilla" HuC. The thought of having to install Cygwin to compile a new version of HuC sounds less fun that punching myself in the nuts. What benefits are there to switching to a new version of HuC? (EDIT: Saw elmer provided a download. Will try it. Still curious what the benefits are.)
Additionally, HuC might be a lipstick wearing pig, but she's gettin' the job done to build a homebrew, that would have never existed had it need to be written in ASM. I can't think of anything less fun than writing 6802-style ASM. Maybe compiling a compiler.
-
I can't think of anything less fun than writing 6502-style ASM
Hu6280's asm is fun, really :wink:
Huc is really fun to start with PCE coding, but it shows it's limits quickly .
-
Well, I was thinking of a new different shade of lipstick; Objective Small C. Ok, maybe not as advance as the original pre-processor of Objective C, but something along the lines of it. Something to toy with for a future class project.
One of the best aspects of HuC is that it's a simple-enough compiler to "play" with.
You might also consider modifying LCC, if you want a well-documented (there's a book) C compiler to play with.
I've got to say that I found the SDCC code to be incomprehensible to me. :oops:
What benefits are there to switching to a new version of HuC? (EDIT: Saw elmer provided a download. Will try it. Still curious what the benefits are.)
A whole bunch! :)
ANSI C syntax instead of the horrible old K&R syntax is the most immediately-obvious.
Just look at the README in the link that Bonknuts put in the 1st post in this thread.
I would not have started doing PCE homebrew without this fork.
Additionally, HuC might be a lipstick wearing pig, but she's gettin' the job done to build a homebrew, that would have never existed had it need to be written in ASM.
Comments like these show that there's a desire for a C compiler for PCE development, and HuC has been wonderful for that.
It's just that there are much better open-source compiler front-ends available these days than Ron Cain's Small C, and it should be possible to generate much better 6280 code than HuC can ever be "fixed" to generate.
Until that happens, HuC (or Uli-fork-with-Artemio's-improvements) is the best option for folks.
-
Clang + LLVM backend for Hu6280 would be optimal. HuC works fine for me but a better compiler would mean more advanced homebrew.
In my homebrew game the game code is cross platform and the PCE backend is a mix of HuC + asm. I plan to port it to Amiga and SNES in the future (if I ever finish it). Without C this would not be possible.
-
Been trying to make sense of fmemopen and how it's used. I think I got this figured out. It'll be kind of a hack, because how he reused functions pointing to file streams instead of buffers, but I could change data and rodata to actual fopen(). There's a point where data and rodata get fclose() and just the data from the buffer is transferred to the main output stream (output) - this is in dumpfinal(). This could be changed to a simple read the file contents back into the buffers, then pass those buffers along.
No where else is fmemopen() used except in main.c and in the global definition section dumpglbs().
That, or where everything eventually gets routed to a single fputc() output, a little bit of conditional code to handle writing directly to the data/rodata buffers upon detection. Either should work and remove the cygwin dependency.
Note: Not that I write the most beautiful code, but goto and continue usage seems.. I dunno, out of place. Feels hack-y/rushed in code design instead of thought out. I shouldn't criticize, really. But it is strange to see it there.
Edit: Meh.. I'm just gonna rewrite *buffer version of all the fstream functions. There's not that many. It'll be more readable.
-
More Posix specific stuff that's not in mingw (lock and unlock stuffs for File streams), but this time in pceas.
-
OK. I got HuC compiled with the changes and removal of fmemopen. It compiles a simple source file, but pceas is complaining that it can find the x86 pseudo reg names (they now have an underscore). This looks to be a backend lib thing and not a executable issue (there were notes mentioning of moving and changing the asm lib stuffs).
Elmer, is that link from your drop box Artemio's fork?
EDIT: Nevermind about the x86 pseudo reg issue. Seems to be from add32() fastcall that's internal to HuC. No one bothered to change the names of the pseudo regs for the internal fastcalls to the match the changes to the backend lib. I'll update those now in HuC source code.. I'm not even sure why there are even internal fastcalls. Those should all be in the library..
Here's the modified main.c for mingw
(edit: I'll upload it as complete source package and binary snapshot once I get enough testing done. So far, so good.)
-
OK. I got HuC compiled with the changes and removal of fmemopen.
Excellent! Congratulations! :D
Elmer, is that link from your drop box Artemio's fork?
Yes, the build that I made was from Artemio's github fork.
Good luck! :wink:
-
Ok. Do you know what the differences are? I looked at the git that I posted at the top of this thread, and saw the pull requests from Artemio and trap (and someone else). They even submitted the changed files (trap did switch case extension to 256 levels, and re-wrote code for pcxtool - needed for dealing with photoshop's PCX format). Artemio's pull request was just for PCEAS and better bank sorting. Did he touch HuC at all? Did he have a git page?
-
Update: Just testing out some features of the 3.98 HuC build. Seems const arrays can be populated during compile time, but variable arrays can not be populated during runtime. But that's not the issue per se; it's how HuC is handling the error messages. It's hard locking the program.
I'm gonna run the compiler through the gnu debugger with PCE C source files known to cause HuC errors, to see what's happening.
Update2: Wow! Looking at variable array direct access and it's fast. Very nice. Pointer into array isn't that bad either (IIRC it was treated as far access in HuC 3.21, not so in this release).
Update3: I'm looking at the code generation for pointers and arrays, and I'm pretty happy with the improvement. Though there's one thing that could be improved further; if the index into an array pointer (if char *x, then x=array, x[i ] =0) is smaller than 256, it should be indexed by Y instead of added to the pointer manually (it's a 16bit add regardless of the value for the code generation).
-
Ok. Do you know what the differences are? I looked at the git that I posted at the top of this thread, and saw the pull requests from Artemio and trap (and someone else).
When you're on Uli's github web page, just click on the number to the right of "Fork" near the top of the screen.
That'll take you to the revision graph. You can click on any of the different fork's revisions on that graph and it will take you directly to the github page for that fork/revision.
That's the easiest way (that I know of) to get to Artemio's page from Uli's page.
-
Ahh thanks! I'm not familiar at all with github, so just now getting a chance to explore it/figure things out. It's actually pretty decent idea.
Also, having some fun testing out new features:
#include "huc.h"
#include "string.h"
struct BMP {
int height;
int width;
char name[10];
};
struct BMP bmp;
struct BMP png;
struct BMP *bmp_ptr;
main()
{
set_color_rgb(1, 7, 7, 7);
set_font_color(1, 0);
set_font_pal(0);
load_default_font();
disp_on();
cls();
bmp.height = 1;
bmp.width = 1;
strcpy(bmp.name, "test");
put_string(bmp.name, 8, 5);
bmp_ptr = &bmp;
bmp_ptr->width = 256;
bmp_ptr->height = 192;
strcpy(bmp_ptr->name,"Ginger");
put_string(bmp.name, 8, 6);
bmp_ptr = &png;
bmp_ptr->height = 32;
bmp_ptr->width = 32;
strcpy(bmp_ptr->name,"Bonk");
put_string(png.name, 8, 7);
bmp_ptr = &bmp;
strcpy(bmp_ptr->name,"test2");
put_string(bmp_ptr->name, 8, 8);
while(1){};
return 0;
}
Note: I'm also looking at code improvements. The compiler sometimes optimizes for values kept in A:X, which is decent, but then there are occasions like temp++; which loads a 16bit value of temp (which is a char) into A:X, but then does a simple inc temp following it.
The other thing that bothers me, is that all 8bit values being extended into 16 values (A:X) are done at runtime instead of compile time, if the variable is signed. Because the compiler is doing this automated extension, it also means signed extension has to be handle at runtime. This means unsigned vars will always be faster than signed - for chars. If compiler didn't automatically extend everything into 16bit, this wouldn't be a problem. So this is an area where the compiler still needs work. I mean, unsigned char is just one extra byte and 2 extra cpu cycles (cla).
In other words, the compiler is automatically type casting every char. It shouldn't. There should a specific set of build-macros just for handling char values (I think Dave Shadoff was working on this as an optimization switch in the 3.21 version).
-
I can't think of anything less fun than writing 6802-style ASM. Maybe compiling a compiler.
This got me thinking. So, do you have any ASM mixed into your C code? Would you be willing to use some generic, easy to use ASM template code if it was given to you in tutorial form - to mix with C?
-
Arkhan and I have been finding ways around HuC's limitations for years now. Just sayin'. :D
-
Arkhan and I have been finding ways around HuC's limitations for years now. Just sayin'. :D
Can you blame folks for wanting better? The tools folks use are important to them.
-
I can't think of anything less fun than writing 6802-style ASM. Maybe compiling a compiler.
This got me thinking. So, do you have any ASM mixed into your C code? Would you be willing to use some generic, easy to use ASM template code if it was given to you in tutorial form - to mix with C?
Um, absolutely, if it helps the program. That said, I'm not sure what you could provide, since that is really the job of the compiler, right?
-
Can you blame folks for wanting better? The tools folks use are important to them.
No way! Never once in the 13+ years I've been using HuC have I ever thought "you know what? it would be nice if this was more efficient and I didn't have to longform certain techniques just to get good speed out of them at the expense of code size"... never once crossed my mind!
-
That said, I'm not sure what you could provide, since that is really the job of the compiler, right?
Speed.
In the form of small copy/paste segments of asm code that you simply replace the variable name.
Anything else, like added complexity, and you'd just have to learn ASM yourself to implement it.
Arkhan and I have been finding ways around HuC's limitations for years now. Just sayin'. :D
It wasn't aimed at asking HuC vets ;) Funny though, but I haven't seen you guys post anything public about it, specifically. Or did I miss something? Exclusive club? :P
-
Funny though, but I haven't seen you guys post anything public about it, specifically. Or did I miss something? Exclusive club? :P
Perhaps because these solutions are usually specific to the implementation and don't have general application. Either that or we just converse in secret, keeping all of the secrets of the universe to ourselves. :lol:
-
Illuminati!
-
If only the Illuminati would release the PC Cocoron ISO.
-
Can you blame folks for wanting better? The tools folks use are important to them.
Having a compiler that barely-qualifies as recognizable modern-C, and that requires you to perform all sorts of undocumented and hidden gyrations in order to work around its limitations ... is not very user-friendly.
IMHO, it should be possible to do better these days, and have a compiler that produces "just-about-acceptable" code that's no more than 2 or 3 times slower than pure hand-optimized assembly language.
The work that Uli (and Artemio and the others) have done has been a big step forward in making HuC more usable for modern folks, and I hope that people will take advantage of it.
I just know that a better compiler is possible, and that it could help people.
But it doesn't replace the desire or passion of dedicated homebrew developers, who will work long hours to create something fun on the PCE with whatever tools are available.
Arkhan and I have been finding ways around HuC's limitations for years now. Just sayin'. :D
And as Arkhan has said himself ... he basically prototypes in HuC, and then when he's got the logic flow written, he rewrites large chunks of C code in pure assembly.
That shouldn't really be necessary ... or at least be something that's confined to a few specialized functions that get called lots of times per frame.
No way! Never once in the 13+ years I've been using HuC have I ever thought "you know what? it would be nice if this was more efficient and I didn't have to longform certain techniques just to get good speed out of them at the expense of code size"... never once crossed my mind!
Good for you! :wink:
For me ... I looked at language limitations and the code that it produced and said "I'd rather be writing in assembly".
-
Having a compiler that barely-qualifies as recognizable modern-C, and that requires you to perform all sorts of undocumented and hidden gyrations in order to work around its limitations ... is not very user-friendly.
IMHO, it should be possible to do better these days, and have a compiler that produces "just-about-acceptable" code that's no more than 2 or 3 times slower than pure hand-optimized assembly language.
The work that Uli (and Artemio and the others) have done has been a big step forward in making HuC more usable for modern folks, and I hope that people will take advantage of it.
I agree. And not just modern folks, but the whole idea of a higher level language environment is to avoid dedicating years of experience with assembly targeted for said platform. It seems ridiculous that programmers should have to fight the compiler the whole way through, such as HuC, when there are much more similar and mature language products.. on similar spec'd platforms.
I know the 65x arch isn't the best design for efficiency for something like C, but that isn't the whole excuse. HuC, version 3.21, I wouldn't even call it "small" C.. I'd call it "barely" C. I'm not bagging on it for not being more than what it was (Dave Shadoff even described it as being an introduction to PCE programming and nothing equating seriousness). To me, that implies "novice" and "toy". But that doesn't mean both functionality (support for more modern concepts and constructs), and speed/efficiency can't be brought up quite a few levels. I find the upgrades that Uli has done to be quite staggering by comparison (you don't get a full picture until you go through the hundreds of test files in the PCE C test source folder, showing off new functionality).
I admit my motives might extended beyond just the benefits of the PCE, but I find the platform a comfortable choice since I know it so well; I'm interested in both compiler work and implementing different programming concepts. That said, I'm actually kinda excited to do a C project for the PCE with the new changes/upgrades. This.. coming from an assembly-to-the-core guy for PCE. Heh.
-
If you really want to talk about high-level programming, then even more important than the compiler is the set of libraries and base functions which are available to the programmer out-of-the-box.
HuC implemented many things which had not been attempted or available before - and were developed as part of the work of HuC:
Such as:
- CD-ROM boot (and a dual-boot option which some had thought was not possible)
- standard hooks into the CDROM card (including documentation), and replacements of most functions for HuCard builds
- more access to the VDC than had been available previously
- an integrated font and print functions (not just POSIX streaming to a termnal device)
- access to backup ram functionality
- PCE mouse functionality
- a clock timer
- random number generator
- a standard set of IPL routines (including initialization to various resolution modes)
etc.
A lot of work went into this functionality which could have otherwise been spent on the compiler - but then the compiler would have been even less useful.
While you work on the newer compiler, please keep this in mind and consider the libraries - which would by definition be hand-optimized and the best code available - and make a lush set of building blocks. If done properly, this could reduce reliance on the code generator for speed and efficiency - and on the language itself for ease-of-programming.
Please be my guest to use what exists in HuC, and build on it where it makes sense.
-Dave
-
I never posted anything publicly for assembly optimizations, because it's simply hand-converting C code to 6502 assembly.
If you don't know how to do that, me pasting it to you isn't going to help, lol.
It came up briefly in that other thread.
It's as simple as accessing arrays using 6502 assembly. That's something any 6502 book will show you, fairly simply.
and then If/Else is just converted to compare/branch code. Simple, really. Just find a 6502 tutorial and read how to do compares and indexing.
It's not really a mind blowing process. It's more like mind numbing.
The compiler, even if it were to be improved over HuC, would still be a bit goony with regards to doing efficient array usage in something like:
if(thing[i] > thingy[i]).
You could make it smart about the generation of stuff, but then it adds alot of complexity to how you generate that code.
Hand converting functional C code to 6502 is OK by me. It's a great learning experience, and a great encouragement to convert to using z80 instead.
6502 is mental.
lol
-
The compiler, even if it were to be improved over HuC, would still be a bit goony with regards to doing efficient array usage in something like:
if(thing[i] > thingy[i]).
You could make it smart about the generation of stuff, but then it adds alot of complexity to how you generate that code.
HuC 3.98 code generation isn't too bad:
__ldub _arr1+1
__pushw
__ldub _arr2+1
jsr gt
__ldub is just ldx $abs and then a "cla", which is pretty fast. __pushw is a bit ugly since it uses the larger stack by default, but Uli has working optimization switches which use a much faster internal stack method in the code generation. At least the array access is fast.
Dshadoff: That's a great point. Sometimes I forget just how much work was put into the library for HuC.
-
Hnmng. I'm still using HuC 3.21 from 2005 (The one where the mod player will be released next week).
It generates some pretty goobery code from what I recall when you do alot of array usage within If/Else stuff. .
You can optimize that stuff like mad if you just convert it yourself.... and most of the time, game code is not really that complicated, so it's not that much work.
The library and such is why using HuC is still an OK idea. You just need to get used to the idea of having to do assembly.
honestly, if you don't want to do assembly, you are f*cked, more or less.
Most of Atlantean simply turned into C entry points that were full of giant #asm blocks of what used to be C code.
-
Most of Atlantean simply turned into C entry points that were full of giant #asm blocks of what used to be C code.
Well, as homebrews go, Atlantean is a pretty attractive, smooth-operating game, and I'm not at all surprised that was necessary to make it like that. That said, for Gredler and DK, having a robust HuC implementation allows them to get their feet wet making a game which may be compromised in some ways, but is still functional. And as their abilities improve, they can slowly start learning to insert ASM to replace some of those C functions. But the easier it is to work with HuC and still get acceptable results, the more likely they are to keep at it and develop those skills.
-
Most of Atlantean simply turned into C entry points that were full of giant #asm blocks of what used to be C code.
Well, as homebrews go, Atlantean is a pretty attractive, smooth-operating game, and I'm not at all surprised that was necessary to make it like that. That said, for Gredler and DK, having a robust HuC implementation allows them to get their feet wet making a game which may be compromised in some ways, but is still functional. And as their abilities improve, they can slowly start learning to insert ASM to replace some of those C functions. But the easier it is to work with HuC and still get acceptable results, the more likely they are to keep at it and develop those skills.
Well said, and true, if it weren't for HuC's approach-ability we would not be making our project. When I met DK I showed him HuC and he has taken the reigns since then doing 100% of the coding. I hope to help and do some stuff eventually, but as it stands right now I haven't even seen our code.
-
Well, maybe some peeps can do a basic ASM tutorial geared directly for HuC. Starting with pretty simple optimizations and usage of ASM, and move to more advance stuffs.
A tutorial on how to do benchmarking (which should be super simple), should be included.
I'm just throwing ideas into the fish bowl...
-
Well, maybe some peeps can do a basic ASM tutorial geared directly for HuC. Starting with pretty simple optimizations and usage of ASM, and move to more advance stuffs.
A tutorial on how to do benchmarking (which should be super simple), should be included.
I'm just throwing ideas into the fish bowl...
Very much appreciated ideas, I can't speak for DK but performance profiling, bench marking, and resource tracking seem to be non-existent. Debug options in modern engines are what have spoiled me the most, I would say.
-
I benchmarked Atlantean by writing an FPS counter basically.
You can also print stuff into the overscan area and see what routines take the longest (this is a common thing).
Sometimes, you might spend time optimizing useless crap, so it's best to optimize the most often-called things first.
-
Sometimes, you might spend time optimizing useless crap, so it's best to optimize the most often-called things first.
I agree. Throwing ASM at everything, isn't necessarily going to net you much.
It's not just speed, in making your code faster, but in the context that if you have faster methods - you might be able to user more advance concepts. Better design, etc.
Uhm.. let me see if I can think of an example. Animation is one area. Not the animation cells them selves, but how you interface with them. You could just use fixed code branches that handles most objects, but as processing resource increased as game and arcade systems advanced, the use of multiple layers of indirect of data types allows for more flexibilty in design. Even some NES games use this, to some degree. It allows you to make changes to the game design, without modifying a lot, or any, code. It also might allow for more advance or precise definitions related to timing and response of objects.
The data structure might look something like this:
Frame-> has attributes: meta cell patterns, X/Y offsets, duration of frame until next, etc and the length of this set (because the data elements could be variable in number/size).
The frame would be part of a larger definition, such as walk, run, jump, attack, etc. So through a series of table of pointers and indirection, data/definitions are accessed and objects are built. Simply pointing to a different data structure builds different objects. If I were to do this entirely in HuC, it would be pretty slow. I could circumvent it by building sets of code to directly handle specific objects, but then you lose flexibility in design and changes, etc. Object behavior/reaction/AI/logic can be handled in the very same way, with layered data structures that eventually points to code as well.
This is how I've done my stuff. Even in ASM, I trade a little bit of performance for flexibility. I'll cheat in areas where some objects are simplistic in design, so I'll use simpler code paths, but ultimately I want to use external tools to create complex objects (enemies, events, whatever).
The problem inherent in HuC, or at least 3.21, is that pointer use is fairly slow. The other problem is that language structure itself is expecting some instances or forms recursion (whether you make a recursive function or not), so there is a lot of internal (software) stack manipulation. The two together, really bog down the processor in its current implementation. Learning a little but of ASM, and how pointers work, can save a lot of performance itself - but it can also allow for more complex design like I (tried to) demonstrated above.
tl;dr - Speed isn't just speed. It's also translates into other things. You might say, "my game runs fast enough". And that would be fine. So maybe that speed translates into something else; more complex or capable and flexible game and code design?
-
The data structure might look something like this:
Frame-> has attributes: meta cell patterns, X/Y offsets, duration of frame until next, etc and the length of this set (because the data elements could be variable in number/size).
The frame would be part of a larger definition, such as walk, run, jump, attack, etc. So through a series of table of pointers and indirection, data/definitions are accessed and objects are built. Simply pointing to a different data structure builds different objects. If I were to do this entirely in HuC, it would be pretty slow. I could circumvent it by building sets of code to directly handle specific objects, but then you lose flexibility in design and changes, etc. Object behavior/reaction/AI/logic can be handled in the very same way, with layered data structures that eventually points to code as well.
This sounds like how it would be done in a lot of modern object oriented applications, and seems to make sense if I am understanding you correctly. Catastrophy has some complicated animation stuff we're doing, I wonder if there are big performance gains to be had there (or like you said, more we can do - like in terms of contextual animation)
-
There are other things to consider when writing C on a small machine like this. You need to understand how C works, if you want fast code.
For example, let's ignore pointers and arrays for a minute, and talk just about scalars.
1) You should know that local/automatic variables are generally allocated on a 'stack' - on any machine. But on this machine, the stack is slow. So, local variables = bad. Global variables = good.
2) Parameter-passing. This is also done through a 'stack'. But they also need to be packed (by the calling function), and referenced/unpacked (by the called function). On this machine, the stack is slow. So parameter passing is something to be avoided too, where possible. Again, substituting with globals is preferred (where possible).
You will notice that assembly-language programs from the same era also do these same two things... sometimes the globals are in zero-page, and sometimes outside of it.
Trying to use 'modern' programming principles throws away CPU cycles - cycles which aren't considered a big deal on modern CPUs, but cycles which were precious in the 8-bit era.
-Dave
-
Here's the thing about our game - its separated into chunks. The only real complexity comes from the number of "modes" the game has. Each boss has its own "player control" function, so I can tweak how each part of the game handles. I like it that way.
Thus, my code lacks flexibility. Once the player control code is copied and pasted into a new boss, any changes have to be done to each function, rather than across the board. That said, each boss should control differently. All in all, the code is fast enough, and simple enough, that I don't need any extensive clean-ups, or switches to ASM. Thus far, there is no slow down. The real limitation we are going to run into is ROM space. If a new fork of HuC made the best use of ROM space, or wrote smaller ASM from C, that would help in the long run.
That, and not having a sound guy. We still don't have a musician/sound effects guy. Our game is still mute, for the most part. That is a far bigger downfall to the game, than anything with the current speed of the code.
-
That, and not having a sound guy. We still don't have a musician/sound effects guy. Our game is still mute, for the most part. That is a far bigger downfall to the game, than anything with the current speed of the code.
As great as squirrel is, trying to get guys to use it has been like pulling teeth. The only sound in the game so far (and anytime soon, it's looking like) has been made by me with a C- programming knowledge, and a F- music/sound knowledge ;) Castastrophy might sound catastrophically bad
-
Here's the thing about our game - its separated into chunks. The only real complexity comes from the number of "modes" the game has. Each boss has its own "player control" function, so I can tweak how each part of the game handles. I like it that way.
Well, I was just using one example. There many other examples as to what ASM can translate into besides just speed. But it sounds like space is the only real issue you have for this project.
Thus, my code lacks flexibility. Once the player control code is copied and pasted into a new boss, any changes have to be done to each function, rather than across the board. That said, each boss should control differently. All in all, the code is fast enough, and simple enough, that I don't need any extensive clean-ups, or switches to ASM. Thus far, there is no slow down. The real limitation we are going to run into is ROM space. If a new fork of HuC made the best use of ROM space, or wrote smaller ASM from C, that would help in the long run.
Typically, code is much smaller than data for game projects. Of the roms and such that I've traced through on the PCE (hucard and CD), code is typically 32-40k. Data, tables, sprites, - anything data is much larger part of the game.
Maybe you can save some space by compressing your graphic data (specifically, tiles and sprites). You don't need ASM to do that, and it doesn't even have to be fancy like LZSS, etc. Thought that means you'll need to have to create your own pcx or bmp conversion tools.
I have some pics somewhere that I can post, showing visually what I mean (and how much it safes). Should be easy to write the decompressing code (that writes directly to vram) in C too. No ASM.
Stuff like using mappy 16x16 format saves on tilemap size, but it doesn't use a LUT for the tiles in the 8x8 segments of the meta-tile. Depending on your tileset, there could be a lot waste just in redundant 8x8 tiles inside the pseudo 16x16 set. Also, there's no simple RLE or column/row/token reference compression for the map data either, etc - but depending on your game, tilemap data might not be that big to begin with.
As for code, have you tried stripping out stuff in the library that you don't need? Like the pixel draw routines and such?
-
Maybe you can save some space by compressing your graphic data (specifically, tiles and sprites). You don't need ASM to do that, and it doesn't even have to be fancy like LZSS, etc. Thought that means you'll need to have to create your own pcx or bmp conversion tools.
I have some pics somewhere that I can post, showing visually what I mean (and how much it safes). Should be easy to write the decompressing code (that writes directly to vram) in C too. No ASM.
Stuff like using mappy 16x16 format saves on tilemap size, but it doesn't use a LUT for the tiles in the 8x8 segments of the meta-tile. Depending on your tileset, there could be a lot waste just in redundant 8x8 tiles inside the pseudo 16x16 set. Also, there's no simple RLE or column/row/token reference compression for the map data either, etc - but depending on your game, tilemap data might not be that big to begin with.
Thanks I would appreciate all the info I can get to become more efficient with art generation. Is the data size of the pcx file unrelated to its impact on the footprint on the rom size?
As an artist, besides just using less tiles and less sprites, is there something I can do to help? Currently our tilemaps are pretty danm big, if I recall the shower scene is a 256x192 or so. Our sprites are large too, the vacuum is 64x192.
-
Compressing graphics is a thing. Or if you're using CD, you can just load them as you need them.
As for Squirrel, were your dudes having problems with it? I really don't think you will find an easier way to get SFX and music going in your game. The learning curve isn't as steep as some would think, especially now that there are so many easy to use DAWs that spit out MIDI which is so easy to convert to MML.
-
Compressing graphics is a thing. Or if you're using CD, you can just load them as you need them.
As for Squirrel, were your dudes having problems with it? I really don't think you will find an easier way to get SFX and music going in your game. The learning curve isn't as steep as some would think, especially now that there are so many easy to use DAWs that spit out MIDI which is so easy to convert to MML.
Thanks for the help senior, very appreciated!
We are trying to get this thing on a hucard, so CD is not an option for our rom size and graphical woes - compression sounds necessary!
The guys I've reached out too seem to have trouble comprehending the midi to squirrel process; be it limited channels or cleanup they really seem to have a hard time with it. These dudes are just people who have ability to play instruments and limited ability in coding, no real development knowledge.
Can you provide some freeware examples of DAWs? Right now it looks like if I am not doing the music and sound than I will be training the person who will, and right now I just code everything in MML by hand, resulting in the atrocities we call music in our game. If I had a tool to compose with it would level up a tiny bit, and might help me be able to get someone with actual ability to work on it by bridging the disconnect between typical music generation software and squirrel.
My good friend who wants to develop games with me was the prime candidate for our musician, and his software of choice is "renoise" which in my inspection seemed to be overkill and excessive for our needs, so a simple common documented equivalent that we don't have to invest funds in for a license would be most helpful!!
-
Can Deflemask output to MIDI? The only reason I ask is that it is commonly used to craft "chiptunes" using classic samples. There are a surprising number of folks out there who work in chiptunes who only know how to use trackers, and having a path for them to get to Squirrel might be helpful.
'Course, if your friend is a legit musician, just generating something in MIDI is probably a lot easier.
-
3MLE is a MIDI piano roll program for free. That's your best bet.
-
As for Squirrel, were your dudes having problems with it? I really don't think you will find an easier way to get SFX and music going in your game. The learning curve isn't as steep as some would think, especially now that there are so many easy to use DAWs that spit out MIDI which is so easy to convert to MML.
Squirrel is awesome for getting music and SFX into the game. It works great, at least from the coding side.
The biggest key has just been finding someone willing to actually make the music and SFX for us.
-
None of the guys I've tried to get involved seem to have given it a fighting chance, to be fair too. I am going to try using 3MLE to make something, and maybe it won't be so abrasive.
-
https://www.youtube.com/watch?v=XeZTqqN0FtM
https://www.youtube.com/watch?v=yy9gNPfTmgU
-
3MLE is the tool I use for MIDI->MML conversion. Works like a charm.
-
https://www.youtube.com/watch?v=XeZTqqN0FtM
https://www.youtube.com/watch?v=yy9gNPfTmgU
Thanks for posting these here, but I've gone through them a bunch of times already - I really appreciate the detailed documentation between these and the readme.
3MLE is the tool I use for MIDI->MML conversion. Works like a charm.
I think this is where the disconnect is for myself and the two guys I've tried to get to use this workflow - authoring a halfway decent midi.
Where were you getting your midi's from?
Right now it seems like making the song straight up in 3mle is my best option, but I've looked into "anvil" and a few other programs to create midis with.
-
I use fruity loops.
Really though, making music requires you to ... know how to make... music.
Any music program from the last 25 years that isn't a shitheap can export a MIDI, basically.
-
Really though, making music requires you to ... know how to make... music.
Well, danmit. Where is the make music button?! Get your shit together!
-
(http://www.pcedev.net/pics/compression/sprite_compression.png)
So one example of your large sprite, here I color coded a few areas to show some simple compression schemes you could apply directly in HuC. So while the PCE sprites cells are 16x16 in hardware, that doesn't mean you couldn't store them in smaller components like 8x8. Matter of fact, it's pretty easy to convert four 8x8 sprites into a single 16x16 when writing it to the hardware. But for the sake of simplicity and keeping the planar format, I chose 8px wide as the smallest width.
So the simplest area of compression is of course just to omit blank 16x16 tiles. Those are marked in red (a group of 8x8 tiles making a 16x16 block). But obviously it doesn't always work with all sprites and sizes.
The darker blue translucent areas show part of the image that can be represented as 2bit color instead of 4bit. That's an automatic 50% saving in those areas. Some of the transitioning areas of the bag in that image, have a limit of 7 colors and could be stored in 3bit format for a 25% savings per cell area (which I didn't highlight). Notice that I used 8x8 sectioning in the highlighting.
The light blue and orange-ish areas show repeated data. Since this is planar, and a byte can represent 8px across, that data can be represent in numerous ways (RLE, bitmask for repeat patterns, etc). You can head sections of tile groups with headers, indicating which tiles are compressed and what type of decompression to use. I didn't highlight the whole image with all of columns of repeating 8px wide sections along 8x8 cells, but just enough to demonstrate.
Darker-Pink is similar to light blue areas, except the whole tile can be represented as a single row of 4bit 8x line and a simple RLE for the column length.
The purple one is just an example of where a whole 16x16 cell is wasted to show a few pixels. The art could be changed slightly, and you'd save 128bytes right there.
And just look at all those 8x8 green tiles (which are invisible pixels). Those could easily be represented as a single header byte (blank 8x8 tile). There are all sorts of compression schemes that you can throw at it, and having a diverse set of simple schemes can help out quite a bit. These types of schemes are also very fast to decompress to vram; many hucard games use compression schemes like these. If all you did was compress for blank 8x8 tiles and nothing else, you'd save 1,800 bytes alone in that pic (20% rom saving in space for the image).
-
Thanks Bonknuts! I totally see the sloppiness in the edges cutting into 8x8 quadrants of larger sprites like this in many of my assets, if we implement a compression element that would need to be updated, but thats nbd if needed!
I should note that this image was a rough cutout for the web, the final sprite is cut into small enough peices that most of the green empty 8x8 quadrants are not accounted for.
Great to know about the color compression potential as well, if we can implement that the art can design around these restrictions for sure!
-
(http://www.pcedev.net/pics/compression/sprite_compression.png)
So one example of your large sprite... you'd save 1,800 bytes alone in that pic (20% rom saving in space for the image).
I just wanted to say that even though I don't post often in technical threads, I absolutely love reading them, (especially when I can actually follow along semi-competently).
I appreciate the time you, elmer and others take to explain stuff.
:)
-
Getting back to work on Catastrophy, I've had a few thoughts on what would be helpful to have, as asm code.
First, there is no way to clear vram directly. A quick bit of asm that writes all zeros to vram would be helpful. cls() and reset_satb() don't actually empty the vram. (The main reason I need this is because I'm using 48pix high images in 64pix high sprites. Thus, I need to clear out the extra 0x80 of unused sprite space)
Second, an asm code for doing simple RLE decoding into vram would be awesome, assuming one could also add a separate program that compresses images into .bins, and tells you the % savings.
Finally, a program that helped you keep track of what is in vram would be awesome. Essentially, it'd just be a 32pixel wide listing from 0x0000 to 0x8000, so you could insert your images, and see how much you are using up. I know that sort of exists in emulators, but its hard to actually use.
-
I handle the last part by planning out a VRAM map in advance. It's not terribly difficult to do, and saves a lot of headache later.
Normal tiles use 0x10 VRAM words (#incchr).
Metatiles use 0x40 VRAM words (#inctile).
Sprites use 0x40 VRAM words per section (so a 32x64 sprite, 8 sections, is 0x200 VRAM words).
Each section of the BAT uses 0x400 VRAM words (so the default 64x32 BAT is 0x800 VRAM words).
The rest is just knowing where stuff goes. The BAT is typically at the start of VRAM, the SATB at the end. So you have all the space in between to do whatever you want with, though personally, I typically put the font right after the BAT.
Here's how Lucretia is set up, for example:
common graphics addresses
4600-49FF pause graphics
4A00-4FFF UI
5000-53FF player 1 sprites
5400-57FF player 2 sprites
5800-59FF projectiles
5A00-5BFF items
stage 1
3000-3BFF demon lamp
4000-42FF onigrass
4400-45FF oni-o-lantern
5C00-5FFF moon
6000-69FF birdie
6A00-71FF witch
7200-73FF powerup
7400-75FF tombstone
7600-79FF fence
-
First, there is no way to clear vram directly.
Yes, there is a way, you can use VRAM->VRAM DMA.
Or in asm, a loop with some stx can do the job quickly .
-
I think he meant with straight-up HuC code though... there's no direct function for it.
-
I think he meant with straight-up HuC code though... there's no direct function for it.
Ah ok, if it's only huc functions you'r right .
-
Getting back to work on Catastrophy, I've had a few thoughts on what would be helpful to have, as asm code.
First, there is no way to clear vram directly. A quick bit of asm that writes all zeros to vram would be helpful. cls() and reset_satb() don't actually empty the vram. (The main reason I need this is because I'm using 48pix high images in 64pix high sprites. Thus, I need to clear out the extra 0x80 of unused sprite space)
Yeah, if I remember (this weekend), I can write you a simple set of functions in HUC to do this for you. If someone hasn't already.
Second, an asm code for doing simple RLE decoding into vram would be awesome, assuming one could also add a separate program that compresses images into .bins, and tells you the % savings.
That's pretty doable. I don't know about anyone else, but I've had to write different RLE compressors to re-inserting compressed graphic data back into rom (hacking). So it wouldn't be too difficult just to adapt such tools for regular use.
Finally, a program that helped you keep track of what is in vram would be awesome. Essentially, it'd just be a 32pixel wide listing from 0x0000 to 0x8000, so you could insert your images, and see how much you are using up. I know that sort of exists in emulators, but its hard to actually use.
So you feed a "script" file some text, like what HUC uses, and use that to output a list as well as a visual pic of how vram is organized? Pretty doable, but it's only really valuable if your level or such is static in vram usage. Dynamic allocation is a bit harder to show resource usage for.
-
So you feed a "script" file some text, like what HUC uses, and use that to output a list as well as a visual pic of how vram is organized? Pretty doable, but it's only really valuable if your level or such is static in vram usage. Dynamic allocation is a bit harder to show resource usage for.
Honestly, I was just thinking something like an excel style chart, where I could just load the PCX files in. Its probably really not necessary, as better planning and execution would help. As rover pointed out, a little bit of planning goes a long way. Usually I just load stuff into vram where I'm fairly certain there is free space.
-
Getting back to work on Catastrophy, I've had a few thoughts on what would be helpful to have, as asm code.
First, there is no way to clear vram directly. A quick bit of asm that writes all zeros to vram would be helpful. cls() and reset_satb() don't actually empty the vram. (The main reason I need this is because I'm using 48pix high images in 64pix high sprites. Thus, I need to clear out the extra 0x80 of unused sprite space)
Yeah, if I remember (this weekend), I can write you a simple set of functions in HUC to do this for you. If someone hasn't already.
Any luck with this?
-
I'm not at a system that I can test this code on, but try this out:
void clearVram(int cellOffset, int numOfCells)
{
/* vramAddress and VDCcells are global ints */
vramAddress = cellOffset<<4;
VDCcells = numOfCells;
#asm
;// In ASM, global variables are accessed with a preceding underscore.
st0 #$00
st1 #low(_vramAddress)
st2 #high(_vramAddress)
st0 #$02
lda #low(_VDCcells)
ldx #high(_VDCcells)
st1 #$00
.loop
;// Plane 0 & 1
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
;// Plane 2 & 3
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
sec
sbc #$01
bcs .loop
dex
bne .loop
#endasm
}
It doesn't stall interrupts. It clears vram on a tile basis count, and a tile offset location. Normally vram is $0000 to $8000, but using tile offsets it's $000 to $800. Typically, HuC puts tiles at vram address $1000, which it tile offset $100. If you want to clear a single sprite cell, that would be a group of 4 tiles (a tile is 32 bytes, a sprite cell is 128 bytes). For example: to clear a single 16x16 sprite at vram address $5000, then do $5000 / $10 = $500 and a sprite cell is 4 tiles, so clearVram($500, 4). To clear all of vram; clearVram($000, $800). Etc.
It's pretty rare that you'd want to "clear" a section of vram that's not tile based (the offset or segment system) - i.e. finer than 32byte segment/offset. It's also faster to do it this way too (32 bytes are clear in one loop iteration).
-
It's more faster to hide sprites and clear the BAT (addr $0000 -> $0800,it depend of your virtual screen size), than all the vram .
If you put zero in the BAT region to clear it, you'll see some artifact the next time on empty BAT parts if your screen is not entirelly filled with tiles,this is why it's better to clear the BAT with an empty tile .
-
I'm assuming he wants to clear vram so that when he's viewing it in debugger window, vram contents match the area/section of the game code.
-
I'm assuming he wants to clear vram so that when he's viewing it in debugger window, vram contents match the area/section of the game code.
Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.
P.S., thanks for the code. I'll probably just use it to clear VRAM entirely at each level load, so timing shouldn't matter a ton.
-
I'm assuming he wants to clear vram so that when he's viewing it in debugger window, vram contents match the area/section of the game code.
Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.
P.S., thanks for the code. I'll probably just use it to clear VRAM entirely at each level load, so timing shouldn't matter a ton.
Let me know if you have problems with it, or want to change it in anyway. I usually have some time on the weekends, so I can get to it within a week time frame. PM here and I'll give you my tomaitheous email address.
-
Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.
With meta sprites your problem would have gone .
You can also use this trick, you can transfert a blank 32x16 sprite in top/bottom of your 32x48 to clear the unused part,before transfer your sprite .
It's more faster than clearing all sprites/VRAM .
-
Well, I'm assuming he wants to do this during the start of level or area loads. Not exactly in the middle while the game mechanics are functioning.
Otherwise, if you're dynamically updating sprite data during the game and have this issue, I would use a special sprite load routine where it blanks out the remaining cells.. is best (and not the whole 32x64 block). That could work during in game updating. The routine I wrote could still work in conjunction with this as well.
-
Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.
With meta sprites your problem would have gone .
I haven't a clue what you mean by metasprite? A 32x32 and 32x16 put together?
-
I haven't a clue what you mean by metasprite? A 32x32 and 32x16 put together?
Yes it's an exemple, it's a logical(software) sprite composed by many hardware sprites .
for a 32x48 pixels sprite you don't have to worry for the last 32x16 pixels,because it decomposed into 2 "little" sprites(32x32+32x16) and not a whole 32x64 like you did with 1 hardware sprites.
It's also a more efficient method to avoid/reduce flickering.
32x64 is very good for a full filled sprite, not for unsuported intermediate size like 32x48 or 16x48 etc ..
-
If you have sprites to spare, 32x32+32x16 is better, but if your game is a sprite monster, 32x64 is sometimes your only option. It all depends on your sprite budget. From what I have seen of DK's game, it uses a lot of huge sprites, so maybe 32x64 is better. Also, if you have a general sense of where your sprites will be during gameplay, you can optimize the sprite pixels. For example... in HE's stage 00, we have 32x48 objects, but they have to use 32x64 sprites because the game engine literally uses every sprite the hardware has. However, we leave the bottom 16 pixels open. For some games, you might want to do the reverse... make the top pixels open and align the sprite pixels to the bottom of the sprite block... useful for, say, a 32x48 stalactite in a cavern... that way, you don't have 16 empty lines at the bottom of the stalactite, just waiting to cause an unintended overflow. :D
-
FWIW, I've created a github fork of Artemio's fork of Uli's updated HuC so that I can make some changes.
The lack of the standard "<", ">", and "^" synonyms for PCEAS's "LOW()", "HIGH()", and "BANK()" just finally got me annoyed-enough that I fixed it.
CA65 (and most other 65xx assemblers) support the "<", ">", and "^" syntax, and the lack of them in PCEAS was making it troublesome to convert source code back-and-forth between assemblers.
I've also taken the opportunity to fix the Windows compilation of PCEAS and the other tools so that they can be built with msys2/mingw-w64 so that cygwin isn't needed anymore.
And for the last thing, I've updated PCXTOOL with the latest changes from Markus Buretorp's fork of HuC.
Anyone that's interested in building the tools can find the source at https://github.com/jbrandwood/huc
There's a pre-built 32-bit Windows version of the new/updated tools at ...
<Removed link to obsolete version>
You *should* just be able to drop these into your existing /huc/bin/ directory and have things work as normal.
I *may* look at the other HuC compilation issues at some point, but it's a low-priority for me.
I'm more interested in making some more small changes to PCEAS, such as allowing the user to specify the load address and start address of an ISO.
Enjoy! :wink:
-
Nice!
Do you want the main.c file I modified for HuC?
-
Do you want the main.c file I modified for HuC?
I just read back through the thread ... I'd forgotten that you'd already fixed the HuC compilation issues.
Yes, please! :D
Then I can make a full build of the new HuC that doesn't rely on the gawd-awful-slow-and-huge cygwin.
-
http://pastebin.com/raw/QtUmw5jV
It's a little bit dirty, in that I just redid 7 functions that work specifically with data and rodata. All the final output code cares about, is a pointer to a block of memory anyway.
-
{} style brackets aren't use for anything in PCEAS, right?
One of the problems I've had with PCEAS with when I want to group multiple data assets together and still use sizeof(). Currently, you can only use sizeof on a label if an incbin immediately follows it on the same line. Would be nice to be able to encapsulate data and get the size of it as a whole without manually doing it. The label right before the starting bracket would be the label for the whole data set, although any labels inside would still be global and not limited in scope.
And better yet, have the encapsulation mechanism build out labels from the primary label with added "." to the labels inside.
Like this:
encap Level1 {
.tileset .incbin "tileset1.dat"
.pal .incbin "pal1.dat"
.map .incbin "map1.dat"
.startX:
.db 00
.startY
.db 00
thisIsGobal: .incbin "some.dat"
someBssVAR = var ;var being a BSS define
}
So it creates labels like Level1.tileset, Level1.someBssVar, Level1.thisIsGlobal, etc. Both local labels and global labels inside the encapsulation would be dot connected - all become global.
Or maybe I should just save this for my pre-processor project for PCEAS.. heh.
-
Thanks to Bonknuts' generous help and source code, the entire HuC compiler and toolchain is now compiling cleanly on Windows with msys2.
Github has been updated with the latest changes, and a complete build of the latest version of HuC, with all the executables, include files, examples and source code can be found here ...
<Removed link to obsolete version>
If anyone downloads this and gives it a try, even perhaps, you know, like the folks involved in a certain high profile Kickstarter ... then I'd love to get some feedback on whether there are any problems (I hope not). :-"
-
Thanks to Bonknuts' generous help and source code, the entire HuC compiler and toolchain is now compiling cleanly on Windows with msys2.
Github has been updated with the latest changes, and a complete build of the latest version of HuC, with all the executables, include files, examples and source code can be found here ...
https://www.dropbox.com/s/kknwx1jqitizeap/huc-2016-11-03.zip?dl=0
If anyone downloads this and gives it a try, even perhaps, you know, like the folks involved in a certain high profile Kickstarter ... then I'd love to get some feedback on whether there are any problems (I hope not). :-"
Unknown instruction!
--:A068 __cmpwi_eq 3
Unknown instruction!
--:A078 __cmpwi_eq 0
Unknown instruction!
--:A078 __lbeqn LL1234
Unknown instruction!
--:A07F __cmpwi_eq 0
Unknown instruction!
--:A07F __lbeqn LL1235
Unknown instruction!
--:A08F __cmpwi_eq 4
Unknown instruction!
--:A09F __cmpwi_eq 0
Unknown instruction!
--:A09F __lbeqn LL1239
Unknown instruction!
--:A0A5 __lbran LL1238
Unknown instruction!
--:A0A5 __lbran LL1217
Unknown instruction!
--:A16E __lbnen LL1244
Unknown instruction!
--:A177 __incb_s 0
Unknown instruction!
--:A031 __lbeqn LL1256
Unknown instruction!
--:A036 __lbran LL1246
Unknown instruction!
--:A028 __lbnen LL1261
Unknown instruction!
--:A031 __incb_s 1
Unknown instruction!
--:A053 __lbnen LL1265
Unknown instruction!
--:A08A __lbnen LL1269
Unknown instruction!
--:A093 __incb_s 0
Unknown instruction!
--:A0B7 __addb_s 2
Unknown instruction!
--:A0FC __lbeqn LL1271
Unknown instruction!
--:A126 __lbeqn LL1272
Unknown instruction!
--:A150 __lbeqn LL1273
Unknown instruction!
--:A172 __addwi_sym _my_buffer
Unknown instruction!
# 1017 error(s)
Tried it out, tons of fails. No idea how to help.
-
Tried it out, tons of fails. No idea how to help.
Thank you, I really appreciate you giving it a try! :wink:
At first glance that looks like a whole bunch of missing macros.
IIRC, bonknuts said something about Uli renaming a few things ... but that may have nothing to do with this.
Since I'm an assembly guy, and not a HuC guy, I'm going to have to do some research, and hopefully get some help from bonknuts and any other HuC user that's actually tried the recent Uli/Artemio builds.
Thanks! :D
-
I'm not at a system that I can test this code on, but try this out:
void clearVram(int cellOffset, int numOfCells)
{
/* vramAddress and VDCcells are global ints */
vramAddress = cellOffset<<4;
VDCcells = numOfCells;
#asm
;// In ASM, global variables are accessed with a preceding underscore.
st0 #$00
st1 #low(_vramAddress)
st2 #high(_vramAddress)
st0 #$02
lda #low(_VDCcells)
ldx #high(_VDCcells)
st1 #$00
.loop
;// Plane 0 & 1
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
;// Plane 2 & 3
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
sec
sbc #$01
bcs .loop
dex
bne .loop
#endasm
}
It doesn't stall interrupts. It clears vram on a tile basis count, and a tile offset location. Normally vram is $0000 to $8000, but using tile offsets it's $000 to $800. Typically, HuC puts tiles at vram address $1000, which it tile offset $100. If you want to clear a single sprite cell, that would be a group of 4 tiles (a tile is 32 bytes, a sprite cell is 128 bytes). For example: to clear a single 16x16 sprite at vram address $5000, then do $5000 / $10 = $500 and a sprite cell is 4 tiles, so clearVram($500, 4). To clear all of vram; clearVram($000, $800). Etc.
It's pretty rare that you'd want to "clear" a section of vram that's not tile based (the offset or segment system) - i.e. finer than 32byte segment/offset. It's also faster to do it this way too (32 bytes are clear in one loop iteration).
FYI, this worked great. Finally got a chance to add it to the code. Honestly, I'm pretty much always going to just be doing clearVram(0, 800); when a new level starts.
-
I'm not at a system that I can test this code on, but try this out:
void clearVram(int cellOffset, int numOfCells)
{
/* vramAddress and VDCcells are global ints */
vramAddress = cellOffset<<4;
VDCcells = numOfCells;
#asm
;// In ASM, global variables are accessed with a preceding underscore.
st0 #$00
st1 #low(_vramAddress)
st2 #high(_vramAddress)
st0 #$02
lda #low(_VDCcells)
ldx #high(_VDCcells)
st1 #$00
.loop
;// Plane 0 & 1
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
;// Plane 2 & 3
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
st2 #$00
sec
sbc #$01
bcs .loop
dex
bne .loop
#endasm
}
It doesn't stall interrupts. It clears vram on a tile basis count, and a tile offset location. Normally vram is $0000 to $8000, but using tile offsets it's $000 to $800. Typically, HuC puts tiles at vram address $1000, which it tile offset $100. If you want to clear a single sprite cell, that would be a group of 4 tiles (a tile is 32 bytes, a sprite cell is 128 bytes). For example: to clear a single 16x16 sprite at vram address $5000, then do $5000 / $10 = $500 and a sprite cell is 4 tiles, so clearVram($500, 4). To clear all of vram; clearVram($000, $800). Etc.
It's pretty rare that you'd want to "clear" a section of vram that's not tile based (the offset or segment system) - i.e. finer than 32byte segment/offset. It's also faster to do it this way too (32 bytes are clear in one loop iteration).
FYI, this worked great. Finally got a chance to add it to the code. Honestly, I'm pretty much always going to just be doing clearVram(0, 800); when a new level starts.
I should probably note: Don't call this during active display. Matter of fact, I should probably modify this source code to save the VDC reg. You'll get all sorts of corruption if you call this at the wrong time. Sorry. I tend to think in terms of ASM, where this wouldn't be a problem for me. I'll update the code when I get a chance. I mean, it might work now - but it's best to make it safe for active display (and just in case vblank interrupts it too).
Elmer: Yeah, he changed internal macro stuff so that it couldn't possibly conflict with HuC label names.
It might be that DarkKobold is mixing library code between builds (paths are shared or something, library files directly in project folder, etc).
-
Unknown instruction!
--:A068 __cmpwi_eq 3
Unknown instruction!
--:A078 __cmpwi_eq 0
... and so on!
Tried it out, tons of fails. No idea how to help.
It might be that DarkKobold is mixing library code between builds (paths are shared or something, library files directly in project folder, etc).
Yep, that's what I'm thinking, too.
Those macros are all part of Uli's new version of HuC.
The new compiler can find them and use them fine when it builds the programs in the Examples directory.
I can only assume that DarkKobold has either got some old files in his project directory, or that his paths are set up so that some of the old HuC executables/include-files are being used.
DK ... while my first build of the tools-only could just be dropped into an existing HuC "bin/" directory, the last build of the entire HuC compiler and tools absolutely *must* be used as a *replacement* for the old version of HuC.
AFAIK, the easiest thing to do is to just rename you old HuC directory as HuC-old, and then create a new HuC directory for the new version.
When you've done that, you'll need to delete any old HuC-generated ".s" files in your project directory.
I hope that that will get things working for you!
-
Unknown instruction!
--:A068 __cmpwi_eq 3
Unknown instruction!
--:A078 __cmpwi_eq 0
... and so on!
Tried it out, tons of fails. No idea how to help.
It might be that DarkKobold is mixing library code between builds (paths are shared or something, library files directly in project folder, etc).
Yep, that's what I'm thinking, too.
Those macros are all part of Uli's new version of HuC.
The new compiler can find them and use them fine when it builds the programs in the Examples directory.
I can only assume that DarkKobold has either got some old files in his project directory, or that his paths are set up so that some of the old HuC executables/include-files are being used.
DK ... while my first build of the tools-only could just be dropped into an existing HuC "bin/" directory, the last build of the entire HuC compiler and tools absolutely *must* be used as a *replacement* for the old version of HuC.
AFAIK, the easiest thing to do is to just rename you old HuC directory as HuC-old, and then create a new HuC directory for the new version.
When you've done that, you'll need to delete any old HuC-generated ".s" files in your project directory.
I hope that that will get things working for you!
So I've been.... sloppy. I've been doing all of my code generation in the HuC/bin directory. (I know, I know, don't murder me!)
Would it be sufficient to just delete the HuC/include, delete the .s files, and then overwrite the HuC/bin executables?
-
Would it be sufficient to just delete the HuC/include, delete the .s files, and then overwrite the HuC/bin executables?
Errr ... possibly, but you'll need the new include directory, and you'd have a mess of files between different versions.
If you've got all of your source code in the huc/bin/ directory (not a good idea, but not a horrible sin), then can you just delete all the other directories in /huc/ *except* for /huc/bin/ and then decompress the new files into /huc/ as normal?
The executable files for the new HuC have the same names as the old ones and should just overwrite the old files.
-
Here's a question that's been bothering me: why is your project files inside huc\bin directory?
-
Here's a question that's been bothering me: why is your project files inside huc\bin directory?
A combination of simplicity and how Catastrophy came about. I literally just started one file using the tutorial in the HuC\bin folder, so I could compile by executing "huc main.c" from a command window. Everything has grown organically from that. Yes, I could set paths and etc, but there was never a compelling reason to. Catastrophy literally started as "Do I have the ability to program for the PC Engine?"
Technically, these two videos are iterations of the same C file. I never started from scratch after doing the tutorial.
https://www.youtube.com/watch?v=Ol9uKeTwSOk
https://www.youtube.com/watch?v=LFF4VBwZW_A
EDIT: Got it working. However, it has two conflicts with Squirrel
#define IRQ_TIMER 0
#define IRQ_VSYNC 1
These are duplicated in Squirrel. Deleting them causes a ton of errors.
-
#define IRQ_TIMER 0
#define IRQ_VSYNC 1
These are duplicated in Squirrel. Deleting them causes a ton of errors.
Can't you just search-and-replace the ones in the Squirrel source file? Say to some like SQ_IRQ_TIMER?
-
IRQ_TIMER and IRQ_VSYNC are used as bitmasks in HuC for enabling/disabling interrupts. Appending _MASK at the end would probably be a better name for them anyway.
-
IRQ_TIMER and IRQ_VSYNC are used as bitmasks in HuC for enabling/disabling interrupts. Appending _MASK at the end would probably be a better name for them anyway.
I wouldn't disagree ... but it might not be a easy change for DarkKobold to make (multiple files), and it might need the compiler to be rebuilt.
AFAIK Squirrel is a single (or maybe 2) files to change ... and anyway, library code like Squirrel shouldn't pollute the application programmer's global namespace, it's rude. :wink:
-
Squirrel is a single (or maybe 2) files to change
Funny thing is, I just did a find in all files (*.*) in the squirrel directory, and there were no hits.
I'm not saying it isn't there, just my editor didn't find it.
And yeah, DarkKobold, if you find it in the squirrel stuff, I'd change it to "PSG_ON_TIMER" and "PSG_ON_VSYNC". Should be more descriptive anyway. Afaik, they are only #defines for the parameter to one of the psg setup functions.
library code like Squirrel shouldn't pollute the application programmer's global namespace, it's rude.
If there were seperate namespaces, it wouldn't. However library code often has include files as part of the interface; using the #defines in them is recommended practice (just in case the values change)
System code and variables, however are supposed to use '__' or '_' as a preface to indicate it's a system reserved value. :D
-
[Don't know why, But I don't have an edit button, so....]
Okay, I finally found it. It's part of the defines for a test program. One of the squirrel examples. :/
To show people what values are useable, more than anything.
-
Thanks to Bonknuts' generous help and source code, the entire HuC compiler and toolchain is now compiling cleanly on Windows with msys2.
Github has been updated with the latest changes, and a complete build of the latest version of HuC, with all the executables, include files, examples and source code can be found here ...
https://www.dropbox.com/s/kknwx1jqitizeap/huc-2016-11-03.zip?dl=0
If anyone downloads this and gives it a try, even perhaps, you know, like the folks involved in a certain high profile Kickstarter ... then I'd love to get some feedback on whether there are any problems (I hope not). :-"
I downloaded this link and gave it a try on some code laying around, and I'm getting errors relating to farptr.
This first example is odd; the error seems sporadic and random even without changing the target code...
So, once it might show an error on one line number:
;error: player.c(167)
; load_vram(0x6400 ,hero_spr+0x3c0,0x40);
; ^
;****** can't get farptr ******Another time it might error on a different (but similar) line number:
;error: player.c(115)
; else if(i==8)load_vram(0x6400 ,hero_spr+0x80,0x40);
; ^
;****** can't get farptr ******..And still other times it builds with no errors but the resulting binary doesn't work correctly. (everything is fine using the ancient build of HuC)
Another project always fails to build, and in the same way each time:
04:A267 sta <__fptr
Undefined symbol in operand field!
04:A27D sta <__fptr+1
Undefined symbol in operand field!
04:A27F lda [__fptr]
Undefined symbol in operand field!
Hope this helps~
-
I downloaded this link and gave it a try on some code laying around, and I'm getting errors relating to farptr.
Sorry to hear that!
There's a limited amount of debugging that I can do on the compiler, but let's try and get some of the obvious problems out of the way first.
It would be good to find out if I've broken something, either with my change to PCEAS, or with the mingw-w64 build itself.
Would you please try this version of HuC that I posted a few months ago?
It's built with cygwin using Artemio's source code without any changes ...
https://www.dropbox.com/s/4dy8tujysefqupd/huc-aurbina-2016-06-20.zip?dl=0
If that version still gives you problems, then what you're seeing is because of Uli's changes to the compiler.
If that version works, then we can continue to track down what's gone wrong with the new build.
Another project always fails to build, and in the same way each time:
04:A267 sta <__fptr
Undefined symbol in operand field!
04:A27D sta <__fptr+1
Undefined symbol in operand field!
04:A27F lda [__fptr]
Undefined symbol in operand field!
I'd focus on this project first! Debugging is so much easier with a reproducible problem.
Hope this helps~
Definitely, thanks!
I don't use HuC myself, and all that I've done is integrate Bonknuts's Windows-compatibility patch into the new compiler (with some of my own changes).
Since I don't use HuC, I'm going to have to rely on other people to come up with existing projects that the new compiler fails on.
-
Squirrel is a single (or maybe 2) files to change
Funny thing is, I just did a find in all files (*.*) in the squirrel directory, and there were no hits.
I'm not saying it isn't there, just my editor didn't find it.
That is the crazy thing. I couldn't find where it was used either. I searched a ton, and as far as I can tell, its just in the "defs" .h file. That said, it wouldn't compile, and it looked to have something to do with the psg stuff, from squirrel. It may have actually been totally unrelated.
Maybe if someone pings Arkhan, we can figure this mess out.
-
Maybe if someone pings Arkhan, we can figure this mess out.
<lol> He won't know. I have the original sources for the squirrel player, anyway.
I don't want to mess up my HuC installation (I need it for a game), so I'm working on
re-purposing another computer to install this new build. Once I get a generic "hello"
program compiling, I'll look into it a bit more. I do vaguely remember that there is an
attempt at doing the psg stuff in HuC, but it never got finished. That might be it.
Also note there appears to be a problem with far pointers; I've never used them, but
I'll be looking into that problem, too.
So if you are checking this out and have a problem, please post it here. We can't fix it if we
don't know what/how it broken.
-
It would be good to find out if I've broken something, either with my change to PCEAS, or with the mingw-w64 build itself.
Would you please try this version of HuC that I posted a few months ago?
It's built with cygwin using Artemio's source code without any changes ...
https://www.dropbox.com/s/4dy8tujysefqupd/huc-aurbina-2016-06-20.zip?dl=0
If that version still gives you problems, then what you're seeing is because of Uli's changes to the compiler.
If that version works, then we can continue to track down what's gone wrong with the new build.
Another project always fails to build, and in the same way each time:
04:A267 sta <__fptr
Undefined symbol in operand field!
04:A27D sta <__fptr+1
Undefined symbol in operand field!
04:A27F lda [__fptr]
Undefined symbol in operand field!
I'd focus on this project first! Debugging is so much easier with a reproducible problem.
OK, I just tried with that 2015-10-14 build and got the same errors.
The code I have laying around is designed specifically with HuC in mind (ie, i would likely do things differently when using another compiler), so maybe it's just poor code whose support has been broken by uli's fixes? you're welcome to take a look at the example (http://pce.lifeabroad.org/files/vwf.zip) i used if you like.
-
OK. I got HuC compiled with the changes and removal of fmemopen. It compiles a simple source file, but pceas is complaining that it can find the x86 pseudo reg names (they now have an underscore). This looks to be a backend lib thing and not a executable issue (there were notes mentioning of moving and changing the asm lib stuffs).
EDIT: Nevermind about the x86 pseudo reg issue. Seems to be from add32() fastcall that's internal to HuC. No one bothered to change the names of the pseudo regs for the internal fastcalls to the match the changes to the backend lib. I'll update those now in HuC source code.. I'm not even sure why there are even internal fastcalls. Those should all be in the library..
Another project always fails to build, and in the same way each time:
04:A267 sta <__fptr
Undefined symbol in operand field!
04:A27D sta <__fptr+1
Undefined symbol in operand field!
04:A27F lda [__fptr]
Undefined symbol in operand field!
Hmmmm ... the problem that Bonknuts was seeing is the same type of error as the problem that cabbage has compiling his program.
Uli's new source files contain an inconsistent mix of "fptr" and "__fptr", just as though he was in the middle of changing things and then stopped part way through.
I've renamed all the instances back to their old HuC names "__fptr", and now cabbage's VWF test program compiles.
But it doesn't work properly, either with the old cygwin build, or with the new mingw build. ](*,)
...
<hours pass>
...
OK, cabbage's source code now builds and runs properly with the new compiler. :D
The problem wasn't in his code, it was a change that Uli made in the new compiler.
Uli decided that "char" should be signed instead of unsigned, and that "#incbin" should define its label as a "signed char *".
This was breaking cabbage's program, and lots of other people's HuC programs probably, because that's different to how the old versions of HuC do things (and they were doing the sensible thing IMHO).
I've changed things so that #incbin always defines the label as an "unsigned char *", and I've changed the default char to be unsigned as well.
There are new compiler flags to change that default char setting "-fsigned-char" and "-funsigned-char".
With all of today's changes, cabbage's source code now compiles and runs properly with the latest version of the compiler.
The changes have been checked into github, and here is a new Windows 32-bit version of HuC ...
<EDIT - Removed obsolete build.>
Please let me know if folks still have problems with it.
-
Great work, elmer! With this updated build, the other random error I spoke of is gone and the program compiles and runs just fine.
Since you asked, I found another issue. Here's an example program:
#include "huc.h"
char j;
#incpal(pal,"img.pcx");
#incchr(img,"img.pcx");
main(){
load_palette(0,pal,1);
for(j=0;j<64;j++){
load_vram(0x1000+0x10*j,img+j*0x10,0x10);
put_raw(0x100+j,j%32,j/32);
}
}And here's an img.pcx file to go with it. (http://pce.lifeabroad.org/foo/img.pcx)
HuC "Denki release" handles it just fine, but the new build gives an error:
HuC (v3.98-d31dfaa-dirty, 2016-11-05)
;error: test.c(8)
; load_vram(0x1000+0x10*j,img+j*0x10,0x10);
; ^
;****** can't get farptr ******It's due to the img+j*0x10 part -- by deleting +j*0x10, HuC stops complaining.
-
It's not just +j*0x10 , but anything with j in the seconded argument. Even this causes a problems: load_vram(0x1000+0x10*j , j , 0x10). But somehow load_vram(0x1000+0x10*j , img , 0x10) compiles fine.
-
It's not just +j*0x10 , but anything with j in the seconded argument. Even this causes a problems: load_vram(0x1000+0x10*j , j , 0x10). But somehow load_vram(0x1000+0x10*j , img , 0x10) compiles fine.
The code to do the conversion from an arg_to_fptr() is in function.c
It's barely changed since the old HuC ... but looking at the information coming into it, I can't see how-on-earth it ever worked with complex values like "img+j*0x10".
It *seems* like the problem is in the code that checks to see if the argument is legal more than the actual code generation itself.
<EDIT>
I *suspect* that both the old & new code that checks the argument is basically wrong, and only worked before because the old code generator output the math in a very specific order, and wasn't very optimized.
Not sure how to fix this without opening up a can of worms.
-
I *suspect* that both the old & new code that checks the argument is basically wrong, and only worked before because the old code generator output the math in a very specific order, and wasn't very optimized.
Not sure how to fix this without opening up a can of worms.
I've rewritten the arg_to_fpt() function to deal with the optimizations that Uli made in the expression parsing.
HuC should now get passed all the variations of input code that cabbage was throwing at it.
It can still get confused, and will give errors on some legal-but-unusual ANSI C code, but it should work for all common usage, and it is no worse (IMHO) than the code that was previously in there.
The changes are checked into github, and there's a new build here ...
<Removed link to obsolete version>
-
I didn't look over load_vram's second argument. Is it expecting a far_ptr as the argument type? Is it just a matter of the expression inside of the second argument not returning a far_ptr type?
-
I didn't look over load_vram's second argument. Is it expecting a far_ptr as the argument type? Is it just a matter of the expression inside of the second argument not returning a far_ptr type?
Yes, it was all a problem with converting the second argument into a far_ptr type.
HuC needs to figure out which bank contains the address that you're trying to use for that 2nd parameter.
The code that it uses to figure that out is in arg_to_fptr().
Unfortunately, that code doesn't have full access to the all the syntactic information that it needs, and has to guess at which symbol the programmer wants to use as the base address just from looking at the I-CODE stream (the intermediate code representation).
The old HuC code that was in there couldn't handle the changes that Uli made in the expression parsing to produce a more-optimized I-CODE sequence.
I had to experiment to see what kinds of I-CODE sequences are now produced for the common types of C-usage that are going to be written by HuC programmers.
Then I had to figure out how to determine where the base address is, but still reject the common illegal-parameter errors that programmers often make.
The end-result is very similar to the original HuC code, but it's a bit more flexible in its ability to handle the different I-CODE streams that Uli's changes produce.
************
Even though there are still niggles like these to fix, I'm really impressed with all the work that Uli put into improving the HuC compiler.
It's pretty amazing that it's gone from using 54 different I-CODE functions in the old HuC to 94 now.
That's a lot of new codes to allow him to optimize the output that HuC generates! :shock:
-
Just in case I was actually spending some time looking at the HuC code generation to see what improvements Uli had made, then, well, I might just have noticed the processing for the "switch" statement.
WTF ... how come nobody has rewritten that darned thing in real assembly-language in the last decade ... it's a monstrosity!!! ](*,)
I know that I've ragged on HuC a bit (well, too much, in truth) ... but really ... it's absolutely amazing the amount of work that Dave Shadoff and the others put into HuC; and their love of the PCE shows.
But someone should have re-written that crazy ___case function *years* ago!!! :shock:
-
Just in case I was actually spending some time looking at the HuC code generation to see what improvements Uli had made, then, well, I might just have noticed the processing for the "switch" statement.
WTF ... how come nobody has rewritten that darned thing in real assembly-language in the last decade ... it's a monstrosity!!! ](*,)
I know that I've ragged on HuC a bit (well, too much, in truth) ... but really ... it's absolutely amazing the amount of work that Dave Shadoff and the others put into HuC; and their love of the PCE shows.
But someone should have re-written that crazy ___case function *years* ago!!! :shock:
Sounds like a volunteer offer to me! :D
-
Sounds like a volunteer offer to me! :D
Ah ... but if *I* do it, then you'd have to take all the other things that I'm interested in, like the small-but-incredibly-fast zero-page stack.
And that goes along with a re-arrangement of CPU register usage that will piss-off anyone that's got lots of inline assembly, or who calls assembly-language functions that they've written from HuC. #-o
The benefits of rearranging the registers are too positive to ignore. :wink:
-
But someone should have re-written that crazy ___case function *years* ago!!! :shock:
Sounds like a volunteer offer to me! :D
OK, you got me, it wasn't hard to change it from the new register layout to the old one, so here's a new build with the faster switch/case processing ... :)
<Removed link to obsolete version.>
This build also fixes the compiler test suite that Uli added to deal with the changes that I've made in the last week, and all the tests pass (including today's changes to switch/case).
The changes are checked into github as usual.
I've rewritten the arg_to_fpt() function to deal with the optimizations that Uli made in the expression parsing.
It would be really nice to get some confirmation from HuC users that things are working (or not) with their projects.
-
Wow - I was only teasing with my comment, but thank you for your time and energy to further improve the toolsets for us all. I hope this helps the programmers - I have still not gotten into the coding yet outside of a basic hello world :P
-
Wow - I was only teasing with my comment, but thank you for your time and energy to further improve the toolsets for us all. I hope this helps the programmers - I have still not gotten into the coding yet outside of a basic hello world :P
I'd rewritten it anyway, and the old-register version is 99% the same as the new one ... so it worked out. :wink:
I've been meaning to see how Uli's testsuite stuff worked, and it was a convenient time to figure that out, as well.
The real questions come moving forwards ... does anyone actually *want* a better performing version of HuC if it's not 100% identical to the current version (i.e. the register usage changes)?
Then there's the question of the current multiply function which uses the standard slow shift-then-add algorithm.
Would people be willing to give up 2KB of ROM space and 8-bytes of ZP for a super-fast version that's actually usable?
Most 6502 programmers just avoid things like multiplies and divides, so I'm not sure that it's worth it. :-k
-
Does HuC call a function to do the multiply? If so, maybe it can be handled via backend lib and passing a switch via command line (if <> defined, else - etc). But I think the 2k method should have been in there to begin with (such a brilliant method).
Is the shift handling in HuC still really slow in the new build? The old build would call a function and do a loop - ugh. A little bit of bloat from a variable length macro in the trade off for speed would be worth it IMO.
-
The real questions come moving forwards ... does anyone actually *want* a better performing version of HuC if it's not 100% identical to the current version (i.e. the register usage changes)?
Would people be willing to give up 2KB of ROM space and 8-bytes of ZP for a super-fast version that's actually usable?
As a noob programmer, would I even notice these being used up? I'm pretty sure HuC's target audience would benefit more from increased performance, than they'd ever notice how you are changing these aspects.
Additionally, most HuC programmers don't set what is in the zero page versus not. I just declare my variables, and they go in ram wherever they go. Maybe more advanced HuC users, such as Arkhan or Cabbage have more input.
-
Does HuC call a function to do the multiply? If so, maybe it can be handled via backend lib and passing a switch via command line (if <> defined, else - etc). But I think the 2k method should have been in there to begin with (such a brilliant method).
Yep, there are both a mulu, and a muls function.
I agree, if you're going to use a darned multiply, then it *should* be fast, and it *could* probably be included conditionally.
Is the shift handling in HuC still really slow in the new build? The old build would call a function and do a loop - ugh. A little bit of bloat from a variable length macro in the trade off for speed would be worth it IMO.
Uli already inlined fast code for shifts by a constant 1, 2 and 8. Other immediate values drop through to a routine that's a streamlined version of the general variable-shift code.
So it's about as improved as it can be for the time being.
Seriously ... this new version of HuC has so many improvements over the old version that I'm kinda shocked that there seems to be so little interest in it.
If folks don't kick the tires and give it a spin, then we'll never find out if there's anything else broken like the farptr stuff was (but isn't anymore).
-
DK I'll buy you a beer if you give it a whirl and post feedback about what differences you notice :P
-
If folks don't kick the tires and give it a spin, then we'll never find out if there's anything else broken like the farptr stuff was (but isn't anymore).
I'll give it a try this weekend. Did the conflict with squirrel get taken out, or do I still need to solve that before I can continue?
-
Seriously ... this new version of HuC has so many improvements over the old version that I'm kinda shocked that there seems to be so little interest in it.
Yeah. I was impressed by the code generation for the a lot of stuff in Uli's updated HuC.
-
Did the conflict with squirrel get taken out, or do I still need to solve that before I can continue?
Not by me ... I don't have an example that "breaks".
It should just take a trivial multi-file search-n-replace within the Squirrel directory (or wherever the files are).
If you don't have the tools to do that, then I can do it if you send me the files.
-
But I think the 2k method should have been in there to begin with (such a brilliant method).
Dang it, but that's a *really* fast multiply routine! :shock:
I wish that I'd known about that one back in the 1980s! #-o
It's such a nice way of dealing with fixed-point numbers, too.
HuCard users wouldn't care about the 2KB of tables, but CD users might prefer the smaller 1.5KB version.
It's also interesting that the bottom 16-bits of a signed 16x16 multiply is *exactly* the same as an unsigned 16x16 multiply.
So there's no need for an "smul" routine if you're just wanting a 16-bit result.
As a noob programmer, would I even notice these being used up? I'm pretty sure HuC's target audience would benefit more from increased performance, than they'd ever notice how you are changing these aspects.
Additionally, most HuC programmers don't set what is in the zero page versus not. I just declare my variables, and they go in ram wherever they go. Maybe more advanced HuC users, such as Arkhan or Cabbage have more input.
There's so much about *how* people are using HuC in practice that I don't know about.
AFAIK, people are avoiding using local variables and parameters to functions as much as they can, and just use global variables instead.
So I *think* that would put all the variables into main RAM and not in fast zero-page.
Actually ... I've just been looking for zero-page usage in HuC, but can't find it.
Does anyone know how you can specify variables in zero-page in HuC?
-
Does anyone know how you can specify variables in zero-page in HuC?
#asm
.zp
var1: .ds 1
ptr1: .ds 2
tinyarray: .ds 8
#endasm
No need to worry about addresses. Just use the label names. This is what I've always done in HuC for ZP variables. And of course .BSS for non ZP variables.
-
Using local variables isn't as bad in this version if you compile with -fno-recursive -msmall.
-
In my game I don't use any explicit multiplications at all, so personally I don't want the 2k table in my ROM. But there are probably a bunch of implicit ones from array accesses though.
I use "16bitvalue >> 4" a lot though, I haven't looked into optimizing the generated code for that. Is that worth doing?
-
#asm
.zp
var1: .ds 1
ptr1: .ds 2
tinyarray: .ds 8
#endasm
No need to worry about addresses. Just use the label names. This is what I've always done in HuC for ZP variables. And of course .BSS for non ZP variables.
Hahaha ... Thanks, that makes sense! :)
I keep on forgetting that HuC is really just a pre-processor for PCEAS, and that you can just drop down into assembly like that.
Using local variables isn't as bad in this version if you compile with -fno-recursive -msmall.
Yep, that's right, "-fno-recursive" just makes every local variable into a global variable, and so they go through the existing semi-fast processing for globals.
Then "-msmall" just drops the high-byte adjustment of the stack pointer, leading to shorter and faster stack code.
But stack usage is still *slow*, and it's used *constantly* for intermediate results and so it would benefit from being faster, even if you don't use true local variables or parameters.
In my game I don't use any explicit multiplications at all, so personally I don't want the 2k table in my ROM. But there are probably a bunch of implicit ones from array accesses though.
It would be interesting to streamline the library so that some functions aren't included if they're not used.
You could easily to a search for "jsr muls" and "jsr mulu" in your output file to see if and where they're used.
OTOH ... not sure why you're so worried about the 2KB table. Are you really bumping up against the 1MB ROM limit?
I use "16bitvalue >> 4" a lot though, I haven't looked into optimizing the generated code for that. Is that worth doing?
Uli's code in the new HuC is definitely faster than the old code for that, but a shift by 4 is still going through a function and a loop rather than being inlined as fast code, so you can definitely improve the speed if you want to.
Another big thing is whether you're shifting a signed or unsigned value ... the unsigned shift is faster.
Shifts by 4 could certainly be inlined if you do them a lot. The code will be a lot faster, but it'll cost you 11 bytes each time that you use it, so it's a tradeoff.
You can just modify the __asrwi and __lsrwi macros in huc.inc to try it and see how it works for you.
-
elmer: This was the very reason why I wanted to do a single inline #asm for HuC. So a macro could be used inside something like this:
var = index[U_shift_left_int(idx,4)];
With U_shift_left_int being a macro to inline asm code.
-
elmer: This was the very reason why I wanted to do a single inline #asm for HuC. So a macro could be used inside something like this:
var = index[U_shift_left_int(idx,4)];
With U_shift_left_int being a macro to inline asm code.
That kind of capability would be nice ... I just have no current idea of how it would be implemented in practice, or how you'd know the current state of the expression parsing so that you didn't get in the way.
Did you get it working? I'd be happy to add the patch for it into the current code.
The easiest way to *currently* get some control of the code generated for those shifts would just be to add a #pragma or something like that to enable/disable the fast-inlined shift-by-4 code.
The current __asrwi and __lsrwi macros could be easily modified to look at a global symbol to decide what to do.
<EDIT>
I'm also a bit peeved at the restrictions of trying to keep everything working for HuCard development.
The 6502/6280 can sometimes really benefit from the self-modifying code that the CD format allows for. ](*,)
-
; load_vram(0x7E00,DogHead+0x200,0x80);
; ^
;****** can't get farptr ******
"#incspr(DogHead,"spr/spr_dog_head.pcx",0,0,2,9)"
getting my own farptr errors. These didn't occur before Cabbage's fix.
Also, the IRQ_TIMER and IRQ_VYSNC, I couldn't find them in any other file in Squirrel.
-
A nice little macro would fix that: get_far_ptr(label,index)
That aside, internally if HuC supported 24bit primitives - all labels could be kept as linear addresses. Then when used as a far pointer, simply converted to bank:local address on the fly. In the load_vram case, 0x200 would be added to the 24bit linear address of DogHead, then an internal macro would convert that to bank:local address. In this case, it would be a compile time calculation, but for something like DogHead+j it would still work as I described.
-
getting my own farptr errors. These didn't occur before Cabbage's fix.
Also, the IRQ_TIMER and IRQ_VYSNC, I couldn't find them in any other file in Squirrel.
Thanks for testing it out! :D
Congratulations, you've definitely found a problem.
It looks like the "fix" that I put in for the farptr wasn't good enough to deal with Uli's "symbol+offset" optimization. #-o
That's the one that was causing a lot of problems with cabbage's code.
I thought that I'd found where Uli was doing that, and that his code was incorrectly setting the symbol type to '0'.
I was wrong ... I've finally found exactly where he's doing the optimization, and it's an "uninitialized-variable" problem.
That's why it's tripping up on different symbols randomly. It certainly shows that the optimization is getting used in a lot of places, which is good.
I've fixed it now, but it's not the most "elegant" fix, so I'm going to see if I can switch it to use Bonknuts's idea of the macro instead.
A nice little macro would fix that: get_far_ptr(label,index)
Yep, Uli is not-really-creating a fake new-symbol with the "symbol+offset" as the new name.
It's certainly one way of doing it, but the macro way would be cleaner, if it can be done.
That aside, internally if HuC supported 24bit primitives - all labels could be kept as linear addresses. Then when used as a far pointer, simply converted to bank:local address on the fly. In the load_vram case, 0x200 would be added to the 24bit linear address of DogHead, then an internal macro would convert that to bank:local address. In this case, it would be a compile time calculation, but for something like DogHead+j it would still work as I described.
Ahhh ... but that would be a huge change.
HuC doesn't really seem to deal with symbol values, just strings of text.
All of the actual numerical stuff for symbols is deferred until PCEAS.
-
Ahhh ... but that would be a huge change.
HuC doesn't really seem to deal with symbol values, just strings of text.
All of the actual numerical stuff for symbols is deferred until PCEAS.
Maybe not that big. If HuC isn't actually handling this, but passing it along to PCEAS, then why not add a linAddrOf() directive to PCEAS? Honestly, it would make dealing with arcard card defines much easier as well (of course we still need a .bssAC directive).
But yeah, let PCEAS handle it with linear address support.
-
Maybe not that big. If HuC isn't actually handling this, but passing it along to PCEAS, then why not add a linAddrOf() directive to PCEAS? Honestly, it would make dealing with arcard card defines much easier as well (of course we still need a .bssAC directive).
But yeah, let PCEAS handle it with linear address support.
I look forward to receiving your patch to add this capability. :wink:
In the meantime ... I'm still trying to find a "clean" solution for the current farptr problem.
Using the macro to do it has potential issues that will need some thinking about.
Uli's solution was the "safe" one, if a bit wasteful. I might have to keep on using it.
-
So if I do this for PCEAS, you'll handle the HuC side? Deal. Best deal ever.
-
So if I do this for PCEAS, you'll handle the HuC side? Deal. Best deal ever.
Hahaha! :lol:
That would be an overly optimistic, and wildly inaccurate interpretation of what I wrote. :wink:
-
If anyone downloads this and gives it a try, even perhaps, you know, like the folks involved in a certain high profile Kickstarter ... then I'd love to get some feedback on whether there are any problems (I hope not). :-"
Said folks will give this all a spin soon enough. ;)
-
Said folks will give this all a spin soon enough. ;)
Excellent! :D
I should have the current bug fixed soon ... I think that the quick-and-dirty fix is safer at this point than changing the macros to allow for an offset parameter. The behavior of those macros is relied upon in too much of the optimizer code.
The next question is ... are you open to a change in the HuC register usage? :-k
HuC currently uses A:X for the 16-bit accumulator, and Y is used mostly for slow stack accesses (being set to the value 1).
Changing that to have the 16-bit accumulator in Y:A, and using X to be the data-stack-pointer offers a considerable performance and size benefit when matched with a zero-page stack.
That stack can be tiny (probably 8-bytes or less) if you're using all of the current HuC tricks to have global variables and avoid the stack ... but if you give it a 32-byte or 64-byte stack, then you can probably avoid needing to use most of those tricks and just rely upon the compiler to auto-magically use the stack for local variables, and have it run as fast as putting everything into zero-page.
Remember that on the PCE, the "zero-page,x" addressing mode is just as fast as the basic "zero-page" addressing mode.
It'll need some improvement to the HuC optimizer to take full advantage of the capability ... but the main assembly-language code generation and libraries are looking good so far.
-
Next question ... does anyone have a HuC project that they would be willing to share with me for testing?
I really need to see a reasonable-sized project in order to test the changes to HuC.
Uli's new testsuite is great ... but it has obviously missed a few problems with the new compiler that I've been having to fix.
If I make more-radical changes, then I'll need a better test.
-
Next question ... does anyone have a HuC project that they would be willing to share with me for testing?
I really need to see a reasonable-sized project in order to test the changes to HuC.
Uli's new testsuite is great ... but it has obviously missed a few problems with the new compiler that I've been having to fix.
If I make more-radical changes, then I'll need a better test.
Elmer, greds and I chatted about it. We wouldn't mind sharing catastrophy, in its current state. That said, there are a few obvious and not so obvious caveats before we just dump our code and such to you.
Lets chat via PM?
-
Elmer, greds and I chatted about it
(http://i.imgur.com/Z1PYiLs.jpg)
"grovy"
-
Elmer, greds and I chatted about it. We wouldn't mind sharing catastrophy, in its current state. That said, there are a few obvious and not so obvious caveats before we just dump our code and such to you.
Lets chat via PM?
That would be absolutely perfect ... I hoped that you'd volunteer. :D
I'll send you a PM.
-
Maybe if someone pings Arkhan, we can figure this mess out.
<lol> He won't know. I have the original sources for the squirrel player, anyway.
errr.
Those defines can be omitted, or renamed. They're just convenience defines for calling psgOn in your code for readability from what I remember.
I am pretty sure Atlantean just does psgOn(1) and doesn't even use the define.
what *other* explosions happen? Rename those defs to anything you want, or omit them.
I don't have the new fork of HuC, so I can't really comment on it. I'm also balls deep in MSX stuff so I am not really itching to grab it and start swinging at it...
but if you copy paste errors, I can try to help.
-
But someone should have re-written that crazy ___case function *years* ago!!! :shock:
It's coming right after that MOD player comes out next week in 2007 or 8.
-
(http://i.imgur.com/Z1PYiLs.jpg)
Stoned af.
-
System code and variables, however are supposed to use '__' or '_' as a preface to indicate it's a system reserved value. :D
I agree ... at least within some reasonable limits. :-k
Uli deciding to change the old System Card parameter names from "_al", "_bx", etc so that you could use variable names "al", "bx" etc in your HuC code, was the correct (IMHO) idea, but he went in the wrong direction (also IMHO).
He changed them to "al", "bx", etc in assembly language ... which just means that they conflict with a programmer's own usage of simple names for their own variables.
So I've changed them in the opposite direction ... the System variables are now "__al", "__bx", etc in assembly code, and can be referred to directly in HuC as "_al", "_bx", etc (since C prefixes an '_' onto all variables.
This makes it easier to differentiate System and HuC internal variables from C variables, from assembly-language variables.
-
Well, Catastrophy has shown that there's something going wrong somewhere in Uli's new optimizations in HuC. :(
This C code fails ...
const char a[6] = {60, 61, 62, 63, 64, 65, 66};
main()
{
char x,y,z;
x = 2;
y = 3;
z = a[x+y];
if (z != 65)
exit(1);
return 0;
}
This will take some serious debugging to find out what's going wrong! ](*,)
*************************************
While I'm at it, it gives me an excuse to talk about *why* rearranging the register usage would be an improvement.
The example above generates assembly language code that uses the "__stbps" macro.
That macro stores a byte at the location whose address is on the top of the stack.
That's not uncommon when doing any array indexing or storage through pointers.
Here's what that macro does in Uli's HuC now ...
====================
pha
phx
lda [__stack]
tax
ldy #1
lda [__stack],Y
stx <__ptr
sta <__ptr+1
pla
plx
sta [__ptr]
sax
inc <__stack
inc <__stack
22 bytes, 62 cycles
====================
And it's even bigger and slower in the old HuC that doesn't have the "-msmall" small stack option! :shock:
Here's the same thing with the rearranged registers and the zero-page stack that I'd like HuC to use ...
====================
sta [__stack,x]
inx
inx
4 bytes, 11 cycles
====================
-
const char a[6] = {60, 61, 62, 63, 64, 65, 66};
That should be a[7]. There are 7 values.
if (z != 65)
This may be your problem. The original HuC would see the 65 as an int, and then screw up the compare. IIRC, it would compare two bytes, using the byte after z as the high byte for the compare.
Not sure thats the problem, but you might want to check it. HuC really doesn't llike it when you mix types.
-
That should be a[7]. There are 7 values.
Whoops ... that's just a typo in my post. :oops:
The test array actually has 10 bytes, but I hand-edited it to make it smaller in the post.
This may be your problem. The original HuC would see the 65 as an int, and then screw up the compare. IIRC, it would compare two bytes, using the byte after z as the high byte for the compare.
Good point, but AFAIK, it's a bit better about those comparisons now.
The actual problem is that the optimizer turns
z = a[x+y] into a[0] = z[x+y]
That's a big screwup!
<EDIT>
It's actually probably just a 1 line typo somewhere that causes the error to propagate into that terrible result.
-
z = a[x+y] into a[0] = z[x+y]
Looks like somebody got the macro parameters backwards... :)
-
just a 1 line typo somewhere that causes the error to propagate into that terrible result.
This is what gets me about programming, the room for error for an error prone person makes a difficult learning curve!
The above convo sounds awesome though, seems like progress is progressing!
Stoned alf.
That's not supposed to be alf, it's supposed to be a cat, my drawing skills need to improve like HuC is!
-
Looks like somebody got the macro parameters backwards... :)
Hahaha, yes, that's exactly what it looks like, doesn't it! :lol:
Actually, I've already found *where* the problem is ... but now I've got to find out *why* it's going wrong.
It's in an incredibly excellent new optimization that Uli added that will be critical (in the future) to getting good performance out of the zero-page stack.
It's moving the wrong address from the stack to the end of an assignment ... it's grabbing the address from one I-CODE too soon.
Now ... *why*??? :-k
This is what gets me about programming, the room for error for an error prone person makes a difficult learning curve!
IMHO, access to a good source-level debugger is crucial to learning as a beginner.
Unfortunately, there's very little that we can do about that on the PCE. :(
-
It's moving the wrong address from the stack to the end of an assignment ... it's grabbing the address from one I-CODE too soon.
Now ... *why*??? :-k
Bug fixed, and the fix is checked-in to github.
There's no new build yet because there's still something else left to fix this weekend.
-
Finally got a chance to look at the code for the new HuC, specifically with respect to the IRQ_TIMER/IRQ_VSYNC stuff.
It's only #defined in HuC.h. As far as I can tell, it's not used anywhere.
Any idea why Uli did that? I assume it's for the mod player, but shouldn't that code be more library-like? Not everyone is gonna want the mod player code in every program.
There's also a handful of new #defines there that I'm semi-sure are also gonna cause problems, notably the ADPCM stuff he added...
Can he even access a #define value in assembler? I never could get that to work....
-
What mod player program??? The one that DM made a long time ago and never publicly released the source (which I have, somewhere - but it's kinda useless in its unfinished state). That made it into HuC? Or at least part of it?
-
What mod player program???
I'm not sure; I haven't looked into it that much. I'm not even sure there is a mod player, yet.
However, the version I downloaded and set up has tools that work on mod files. Again, not sure
what they do, but they are there.
I assume (and could be wrong) that there is either a mod player in the code, or that one was planned; In either case, I also assume that's why the #defines are there, as support for that.
Note that, like for squirrel, I did a find-in-all-files for IRQ_TIMER and IRQ_VSYNC. The only place they occur are in HuC.h. In addition, I also did a find-in-all on the original HuC files; the defines do not occur there, so they are apparently new.
I'll keep you posted as I look through the code. I'm particularly interested now in what changes were made to the irq handler.
-
I'm particularly interested now in what changes were made to the irq handler.
From what I've looked at, at least the timer irq does nothing now (I think). It requires setting up a user irq handler to be useful. That's probably why the mml player doesn't work on the timer.
I'm not even sure there is a mod player, yet.
There is a pair of files (st.c/st.h) that appear to contain the code to play mods (?). Not sure if they get included in the system or not, but they are available for use.
Something called SimpleTracker? That's all I know about it.
-
This?
/* SimpleTracker
Plays MOD files converted to ST format by mod2mml.
Copyright (c) 2014, Ulrich Hecht
All rights reserved.
See LICENSE for details on use and redistribution. */
-
Yep, that's the one.
-
It's not mod files. It says "SimpleTracker" but from the quick look over the code, it's not even a tracker format. I suspect is just commandstring format like mml, maybe with fixed length parameters or some hybrid. From the mention of "mod2mml", I'm guess it's just the raw note data; nothing that specifically attribute to real mod files or anything close to it. But yeah, looks unfinished or super bare bones.
-
It's not mod files....
Okay. You would know more about that than me; I only assumed mod files because of the naming.
My point is that he was trying to get a new sound engine in Huc. That's what caused the problems with using the (disassembled) bios code. I think that's a good idea, just a poor way to do it :/
-
What mod player program??? The one that DM made a long time ago and never publicly released the source (which I have, somewhere - but it's kinda useless in its unfinished state). That made it into HuC? Or at least part of it?
Don't you remember, back when I first showed up to make Insanity, and there was that MOD thing for HuC that would supposedly be "released next week", and never actually happened?
It was either in the topic for #utopiasoft, or on one of the sites. It was also mentioned verbally a few times.
and then I got tired of waiting, hate trackers anyways, and used a better solution to the problem, lol.
IIRC, there were/are some pretty goony PSG related things floating around in HuC, some of which may be commented out.
-
There's no new build yet because there's still something else left to fix this weekend.
Catastrophy is now working perfectly (as far as I can tell) with the latest version of HuC. :D
The last problem was with PCEAS not handling "BANK(symbol+offset)" properly, which was messing up the sprites in Catastrophy.
That's a common construct in the new HuC, and is a major improvement over the previous code generation.
All in all, with the old HuC compiler, Catastrophy uses 92878 bytes of code, and with the new HuC compiler (using "-msmall -fno-recursive"), Catastrophy uses 57823 bytes of code.
That's a huge improvement! :dance:
The changes are checked into github, and here's the latest Windows build ...
https://www.dropbox.com/s/tjms9nzyzfrfhrx/huc-2016-11-20.zip?dl=0
It would be nice to get a confirmation that this works (or not) from other HuC users.
*****************
There's a known issue with Squirrel, where the PSG player needs to be modified to run with the new code.
I've done that for Catastrophy, but it's really up to Aetherbyte to make an "official" release for the changes in the new HuC startup.
I'd recommend just putting the changes to the HuC startup.asm that they've made for the HuCard PSG player into my fork of HuC, and then make them conditional so that people can choose to use it, or not.
The rest of the PSG BIOS player code could stay on the Aetherbyte site as it is now, but at least it would mean that future changes to startup.asm (and there will be some coming up) won't keep on breaking Squirrel.
But that's up to TheOldMan and Arkhan. :-k
-
How do you compile for Windows if you are not using Cygwin?
I can test your latest build but it is currently incompatible with my game due to the struct member limit. Here are a couple of changes I did to in my fork of Ulis HuC that I never pushed. Btw, I'm markusburetorp on Github, I also did some changes to pcxtool which you already integrated.
bump total number of struct members from 30 to 128
src/huc/defs.h
-#define NUMMEMB 30
+#define NUMMEMB 128
irq_enable and irq_disable behavior was inverted
include/pce/library.asm
_irq_enable:
txa
+ eor #$ff
sei
- ora irq_disable
+ and irq_disable
sta irq_disable
cli
rts
_irq_disable:
txa
- eor #$ff
sei
- and irq_disable
+ ora irq_disable
sta irq_disable
cli
rts
-
Hi Markus, thanks for your work on pcxtool! :D
How do you compile for Windows if you are not using Cygwin?
Msys2/mingw64 (the 32-bit "i686" version, and not the 64-bit version).
I use the old-fashioned installation instructions, but apparently there's a new executable installer at ...
http://msys2.github.io/
I can test your latest build but it is currently incompatible with my game due to the struct member limit. Here are a couple of changes I did to in my fork of Ulis HuC that I never pushed.
I've applied your fixes, checked them into github, and updated today's build with the changes.
It's at the same link that I gave in the last post.
<EDIT>
I have a question for you ... do you (or any other user of Uli's new HuC) actually use the new ability to create IRQ or SIRQ handlers in Huc?
That's something that I'd like to remove. It's sort-of-clever, but it's horribly inefficient.
IMHO, regular timed-events are better-handled in game's main loop, leaving the IRQs for *fast* assembly-language code.
-
I use the timer interrupt for DDA sound streaming. The way I setup my IRQ handler is super hacky and it would much better if there was a cleaner way of doing this.
This is my initialization code
#asm
sei
setvec #2, pce_timer_interrupt
vec_on #2
cli
#endasm
irq_enable(IRQ_TIMER);
timer_set(1);
timer_start();
pce_timer_interrupt defined as follows
#asm
...
pce_timer_interrupt:
dda_update 0, _pce_dda0, _pce_dda0+1, _pce_dda0+2, _pce_dda0+4
dda_update 1, _pce_dda1, _pce_dda1+1, _pce_dda1+2, _pce_dda1+4
;// Remap old banks if changed
bbr7 <snd_flags, .return
rmb7 <snd_flags ;// Clear mapped bit
lda _pce_snd_oldbanks ;// a = old lower bank
tam #DATA_BANK
lda _pce_snd_oldbanks+1 ;// a = old upper bank
tam #DATA_BANK+1
.return:
rts
#endasm
I also modified startup.asm in HuC to get my handler up and running
timer_user:
jmp [timer_jmp]
timer:
- bbs2 <irq_m,timer_user
pha
phx
phy
+ bbr2 <irq_m,.ack
+ jsr timer_user
+.ack:
sta irq_status ; acknowledge interrupt
-.exit: ply
+ ply
plx
pla
rti
As I said, this was just hacked together to get around the unfinished IRQ/timer implementation in HuC.
-
I successfully compiled HuC with the msys2 you linked, but I cannot launch the executables outside the msys shell. Missing msys-gcc_s-1.dll and more.
-
I successfully compiled HuC with the msys2 you linked, but I cannot launch the executables outside the msys shell. Missing msys-gcc_s-1.dll and more.
You didn't make a static build, so it's bringing in a bunch of DLLs.
You can just copy the DLLs from their location in msys2 ... but it'd be better to make a static build so that they're not needed.
You may also be missing a bunch of the static libraries, it depends upon the packages that you've installed in the msys2 environment.
That's why I have my own batch file to automate an installation! :wink:
<EDIT>
These 2 commands will install my base set of msys2 packages ...
pacman -S --noconfirm --needed base-devel nano
pacman -S --noconfirm --needed mingw-w64-i686-toolchain
I *may* have needed some other packages for my GCC and Mednafen builds, and they *may* have pulled in something else that's missing on your setup ... but if so, I don't know what.
-
Yep, I installed the wrong gcc package (just named "gcc"). Apparently that is based on Cygwin... #-o
EDIT: Works now and the game runs. I also had to increase "#define NUMTAG 10" to 64.
-
elmer: But.. if you use ZP as a fast stack.. how are we going to use recursion to solve ackermann's function?
-
I'd recommend programming your new Sharper Image Internet-Connected Back Scratcher to solve the problem, instead.
It's probably got more processing power by itself than every PCE ever made put together! :wink:
-
Yeah.. well... yeah.. but.. so.. well.. 3 PCE's networked together with three monitors to do a faithful port of Darius!
-
Yeah.. well... yeah.. but.. so.. well.. 3 PCE's networked together with three monitors to do a faithful port of Darius!
Well ... since it's you asking, I probably should have just said ... "You can write it in assembly language with a couple of simple macros". :wink:
It's best (IMHO) to tailor HuC to the things that the 6502/6280 does well ... and a small zero-page stack together with a reasonable use of "global/static" variables, and continued upgrades to the libraries, could allow us to get to that "only 2-4 times slower than hand assembly" goal that I'd love to see.
BTW ... it's going to be easy to modify Mednafen so that it will trap and report a stack-overflow condition with the small stack. That, together with a good error message about using "static variables" or the "-fno-recursive" option, should avoid the annoyances of the random crashes that a small stack architecture can lead to.
The next big question is going to be how to get a decent (and legal) sound driver.
As DK & Gredler have talked about with Catastrophy, it's hard to get someone on this side of the planet interested in MML.
A MOD player of some kind is going to be needed ... preferably with some sample playback, and/or use of the ADPCM hardware. I know that Arkhan loathes the format ... but musicians that either love or tolerate it are *much* easier to find on this side of the pond.
It's a pity that the Deflemask internal audio format isn't documented anywhere.
Do you know of any other good, popular MOD players? :-k
-
The next big question is going to be how to get a decent (and legal) sound driver.
I'm voting for a stock interface to the sound driver from system code. Kind of "these are the routines you supply, and this is when they are called". That would allow us to have multiple drivers (presumably in seperate directories in pce/include), that could be turned on/off via #defines in the user code. [Which would use sound.inc to include the correct files]
Do you know of any other good, popular MOD players?
The place to start with that is Bonknauts. He did a -lot- of work on various sound routines.
After that, -if- we straighten out the system files, it should be (relatively) easy to install user supplied drivers, provided they work in a 'standardized' way.
-
I'm voting for a stock interface to the sound driver from system code. Kind of "these are the routines you supply, and this is when they are called". That would allow us to have multiple drivers (presumably in seperate directories in pce/include), that could be turned on/off via #defines in the user code. [Which would use sound.inc to include the correct files]
I'd prefer to avoid the overhead of a JSR if possible (especially in a TIMER interrupt) ... but it would certainly be possible to have a 2-level structure in startup.asm ...
Level 1 would just invoke different #include files for in-the-middle-of-vsync, in-the-middle-of-timer, and other-stuff-in-the-system-bank.
If those were something like "sound/vsync.asm", "sound/timer/asm", and "sound/system.asm", then you'd just change your PCE_INCLUDE environment variable to include whichever driver you wanted.
Level 2 would be a #define to entirely remove the vsync and timer handling code from system.asm and let you define your own, in which you could do whatever you like.
I suspect that we don't need a more complex interface than just providing those two options to any programmer.
The place to start with that is Bonknauts. He did a -lot- of work on various sound routines.
After that, -if- we straighten out the system files, it should be (relatively) easy to install user supplied drivers, provided they work in a 'standardized' way.
I'm hoping that he'll have an opinion to share! :wink:
In the meantime ... it looks like the Deflemask formats *are* somewhat documented ...
http://www.deflemask.com/DMF_SPECS.txt
http://www.deflemask.com/DMP_SPECS.txt
That's good/bad/annoying/hopeful. :-s
-
Sound drivers.. that's messy business :D
I think by MOD, you're probably meaning "tracker" or tracked format? And not specifically long sample frequency-scaling MOD specific?
I wasn't going to release these yet, but whatever:
This is the sample sound driver. It's a real "MOD" sound driver. As in, it resamples the frequency on the fly to play whatever long samples on the PCE MOD style. It has some requirements for video setup (263 scanline mode recommended), but I have a future version that eases that timing requirement by a lot. They'll play identical. Mean while, you can take a look at this mess...
http://www.pcedev.net/HuPCMDriver/HuPCMDriver1.2.1.zip
XM is sooo much a better fit than the traditional MOD format. Even if you just used PCE legal 32byte waveforms.. XM format is superior. I was able to write this super basic XM player for the PCE in 4 hours. The TXM format is just the XM file without its sample or envelope data. But other than that, it's XM song data to the tee.
http://www.pcedev.net/HuPCMDriver/HuPCMDriver_Demo_HuXMPlay.zip
In order to make the wave files repeatable, I have this utility that will convert 8bit wave files to 5bit special format (has terminator marker in the sample data either for end of sample or for looping. The converter allows creating loop points).
http://www.pcedev.net/HuPCMDriver/wave2six_ver1.1.2.zip
It wasn't really meant for HuC. Matter of fact, I didn't think anyone would even use it (I use it, though).
-
In the HuPCMDriver, I'll be moving the ProcessPCM code (macro) inside the sound driver so timing will never be an issue. Simple fix, just didn't get around to it.
Deflemask is a really good format to go with. It supports some nice PCE only effects. Something XM and other generic trackers don't.
As far as Deflemask. Just use the cooked output. Yeah, it's big - but LZSS compress the shit out of the main data, and just slowly decompress to a small window and execute the updates as it goes along. Samples will always be samples. So nothing to lose there.
-
Squirrel can be fudged into using samples.
Though, I really think everyone who doesn't like MML simply misunderstands it.
You don't write the songs in MML. That's 100% stupid. You write them elsewhere and simply CONVERT the songs to MML. If you understand half an ounce of sheet music (anyone who claims they are a musician should be able to comprehend even the most basic bits), using MML is easy.
Especially with piano-roll software like 3MLE that visually shows the crap.
I think people need to get over it. Everyone waves their dicks around about all this technical crap, and is stopped up by something that can be called from BASIC with a PLAY command?
Please., lol
-
I think by MOD, you're probably meaning "tracker" or tracked format?
To me, MOD means some program that looks sorta like a piano roll, and makes sound.
I don't really understand the difference between trackers and mods, and probably never will (I don't care that much how it makes sound. Just that it does)
Just out of curiosity, would we need an HSync hook? I can foresee that being a problem; it already can be in the bios player, if you are doing scroll areas.
-
Squirrel can be fudged into using samples.
Doesn't Squirrel use the sys card PSG player? AFIAK, it doesn't support samples. The two games that use it and ADPCM at the same time, use some hack-y audio driver on the side the peeks at the player, and syncs itself with it as it runs a separate data stream/channel for manipulating ADPCM stuffs. Other games just straight out bypass the sys card player all together. What do you guys do for sample support?
-
Just out of curiosity, would we need an HSync hook? I can foresee that being a problem; it already can be in the bios player, if you are doing scroll areas.
No Hsync. It's all timer based. Vblank is used to resync the timer every frame (reset the TIMER counter unit). And the Timer IRQ code immediately re-enables interrupts so that Hsync always has priority. That was a big thing I wanted in the player. The player also has a flag so that it can't be called more than once when interrupts are re-enabled during its initial call. That keeps things from crashing into each other. It might delay the sample(s), but "jitter" on these old systems is pretty much unavoidable. And it's not like it'll be Genesis bad - lol. So yeah, it plays nice with Hsync interrupts.
MOD.. eh. In the context of computers, it just means tracked music. But in the context of consoles, it's about playing wave files at different frequencies. Basically what the PCE does with its little 32byte buffer each channel, but these are biiiiggg samples. It's why the Amiga and the PCE, while both technically the same in application - sound nothing a like. They both use samples. They both use the exact same period system and same period values for notes. But the PCE's sample memory is so gimped, that it sounds more like PSG than anything from "sample-based synthesis" (SNES, AMIGA, TRACKED music for 90's PCs, etc). MOD is basically sample-based synthesis. Lots of consoles in the 32bit generation (PS1, Saturn, Jag), and later generations (PS2, etc) use this but with better refinement.
-
Squirrel can be fudged into using samples.
Doesn't Squirrel use the sys card PSG player? AFIAK, it doesn't support samples. The two games that use it and ADPCM at the same time, use some hack-y audio driver on the side the peeks at the player, and syncs itself with it as it runs a separate data stream/channel for manipulating ADPCM stuffs. Other games just straight out bypass the sys card player all together. What do you guys do for sample support?
The HuCard version sure as shit doesn't use the system card player, since the system card doesn't exist.
At one point years ago, I fudged a drum sample. if you get a short enough wave, you can break it into a few 32byte segments as custom waveforms, and then switch them.
It works, but isn't exactly ideal. Especially for literally every other human that might use it besides me, since MML hurts everyone or whatever.
I decided I liked my deep kickdrum that is currently in use more anyways. Some of the greatest PCE games don't even use samples, and rely on noise-drums, so I also stopped caring.
-
At one point years ago, I fudged a drum sample. if you get a short enough wave, you can break it into a few 32byte segments as custom waveforms, and then switch them.
If you're talking about doing that at 60hz, that's only 1.9khz output. I can see that working for instruments with changing timbre, but that's not really what I meant by sample playback.
And you'd have a loud noise floor at 60hz (beating noise) because of the "pops" on the channel when you turn it on and off - unless you have an SGX or one of the core grafx systems that used the revision 6280a that doesn't have this problem. That DAC pop is annoying. The only way to cancel out the popping for something like that (on the non 6280a cpu's), is to use two channels. You alternate between updating two channels. The turning off of one, cancels out the turning on of the other - since the pop direction is in relation to the volume change on the channel. But you still need to update faster than 60hz to get to the original PCE 7khz timer method - something like 218hz updates.
The HuCard version sure as shit doesn't use the system card player, since the system card doesn't exist.
Ok. So if you added sample support for the hucard version - then what? Just not have it for the CD games?
-
The HuCard version sure as shit doesn't use the system card player, since the system card doesn't exist.
This is one of the areas where you and I have been butting heads for a while.
We talk a different language.
Sorry ... but AFAIK (and with increasing certainty since I've recently compared the source code) the Squirrel HuCard audio player is a dissassembled-then-reassembled version of the Sytem Card audio player, with minor changes.
That's what TheOldMan has said (a few times, now), and that's what it *looks* like to me.
But you need to understand that dissassembly-into-source does *not* give you ownership rights over the code.
There's nothing horribly *wrong* with doing it ... and it's a sensible thing to do in order to keep compatibility with the System Card player.
But, if true, then it does mean that you don't *own* the copyright to Squirrel's audio playback code ... just to your MIDI-to-MML converter utility that you ship in the Squirrel package.
Again ... there's nothing horribly wrong with that, and your tool that converts MIDI to the System Card MML format is a boon to the community.
But ... please be honest and attribute the creators as appropriate.
From what I can see, TheOldMan has been very careful to do that with the playback code in the Squirrel package.
Please consider following his example rather than making statements that attempt to suggest that you're not using the System Card player. That may be true from a literal standpoint, but it's not true, from what I see, from a copyright/legal/honest standpoint.
-
But ... please be honest and attribute the creators as appropriate.
And, as a follow-up ... a lot of my recent posts have been about fixing bugs in Uli's improvements to HuC.
I want to be very clear here ... the incredible amount of hard work that he put into improving HuC is *why* I've spent a lot of my time over the last week-or-so into seeing if I can move things forward a little further and fix some of the bugs that were introduced.
AFAIK, HuC/PCEAS is the creation of David Michel, David Shadoff, and Oliver Jolly, with major contributions by Uli, and other improvements by Bonkunts, Artemio Urbina, and Markus Buretorp.
I'm still just playing and effing around at the edges of their project.
That may become more-significant if I can get the zero-page stack and register rearrangement working ... but it's still going to be a project based mostly upon the work of other people.
I've spent most of my professional life writing software ... an appreciation for these kind of distinctions comes with the territory.
-
This is one of the areas where you and I have been butting heads for a while.
We have? I can't say I recall that.
We talk a different language.
Sorry ... but AFAIK (and with increasing certainty since I've recently compared the source code) the Squirrel HuCard audio player is a dissassembled-then-reassembled version of the Sytem Card audio player, with minor changes.
That's what TheOldMan has said (a few times, now), and that's what it *looks* like to me.
But you need to understand that dissassembly-into-source does *not* give you ownership rights over the code.
Please consider following his example rather than making statements that attempt to suggest that you're not using the System Card player. That may be true from a literal standpoint, but it's not true, from what I see, from a copyright/legal/honest standpoint.
I understand that this is how it works, and I am fully aware of the distinction. I kinda do this thing for a living, you know. We even have to go through the legal department all the time when doing things.
I am not trying to state otherwise. You just misunderstand me. Or we're all misunderstanding each other slightly.
When I hear "system card player", I assume "system card" or "IFU required", which isn't true in this case now.
I'm talking strictly from a hardware-required standpoint. System card / PSG BIOS to me implies you need a system card/CD dock/whatever. That is what *I* mean when I say it's not the same thing.
So when Tom mentions the system card player, I assume he too is talking about when you have the CD hardware/etc. present. He even mentioned ADPCM, which I assumed was the ADPCM RAM on the CD hardware. You can't use that if you don't have the CD dock, because it's not there, lol.
But, if true, then it does mean that you don't *own* the copyright to Squirrel's audio playback code ... just to your MIDI-to-MML converter utility that you ship in the Squirrel package.
Again ... there's nothing horribly wrong with that, and your tool that converts MIDI to the System Card MML format is a boon to the community.
But ... please be honest and attribute the creators as appropriate.
I am being honest. As I said, you're just misunderstanding me. I am talking about from a usability/requirements standpoint.
We have already stated on here, somewhere, probably repeatedly awhile ago, that it's simply recreated for HuCard so you can use it without having to make a CD game. I think that topic came up before you came around, actually. I've even stated this verbally to people who've asked at conventions. I don't know if Spenoza remembers, but I definitely told him once. Maybe Zeta too.
But, since it no longer requires the System card or CD hardware, it's not THAT one in terms of usability. We moved it. It wasn't straightforward, or easy, but we moved it. It's clearly the same thing though, since it accepts the exact same format. It was all created from... disassembly, develo book, Hu7 CD book, an oscilloscope, OldMan's excessive free time and curiosity....
This was not done to imply that we created some brand new player. It was done so when people make goobery little games like Reflectron or Cabbage's adventure game (that won an award IIRC), they aren't required to distribute pain-in-the-ass ISO images of them, which are then another pain-in-the-ass just to fire up in an emulator or whatever.
You can't jam em on a flash cart either. That was the driving force behind making the PSG player exist outside of the CD hardware. I don't recall us ever trying to take credit for any of that really outside of recreating and getting it to work.
That is also why Squirrel's manual's main focus is explaining MML, and how to make sounds come out, as opposed to rambling about the player stuff. Squirrel isn't really the player crap. Squirrel is literally the MML compiler. It existed *before* the HuCard version of the player. That's what was used for Insanity.
There was no HuCard player yet, but there was Squirrel.
The player crap is all tucked away and ignored because you are supposed to pretend it's still "built in". Nobody should have to look at, or touch any of it.
I'm not trying to pretend or be dishonest about anything. I am just saying, it's "not the system card one", because it doesn't require it anymore. It's been extracted so you don't need a System Card anymore. The big difference is that now, since the code is there and touchable, one could bastardize the flying shit out of it and make it no longer operate like the CD BIOS one, which could get hilarious and interesting.
The only ownership we really can claim is that "we moved it" so it's more useful to people.
The MML compiler is the important part anyways, because the player is 100% useless without it.
and most of this is a moot point since everyone's afraid of MML, lol. I just find it comical that people making games for 30 year old game consoles don't want to deal with it, but people playing a goofy free MMO called Mabinogi (read: 15 year old kids) are completely OK with using it to make songs for their characters to play in-game.
Kiiiiiiiinda goofy, I'd say.
Now, I think the big mixup comes from when you'd asked about tweaking squirrel to redistribute awhile back.
Maybe I/we misunderstood what you were asking with regards to that. We don't own any of that code, technically. All that was ever asked for if Squirrel as a whole is used is that you credit us, and if physical copies are made, mail us a copy. That's pretty common for these scenes. That's exactly how the licensing agreement is for the player I am using for MSX that my friend wrote.
We won't share the source for the compiler for Squirrel, but, we're already sharing the player code.
I guess it's OK to redistribute that and credit as such, noting whatever changes are made and by who to get it fudged into working again.
But, then we get into whatever license is used for HuC's distribution. Is it actually OK to distribute the player code around in that, or do we get into that weird dicey territory? I'm not sure. I'm also not sure if, really, Hudson/NEC would come down on the whopping what, 6 people who would be partaking? lol.
At one point years ago, I fudged a drum sample. if you get a short enough wave, you can break it into a few 32byte segments as custom waveforms, and then switch them.
If you're talking about doing that at 60hz, that's only 1.9khz output. I can see that working for instruments with changing timbre, but that's not really what I meant by sample playback.
And you'd have a loud noise floor at 60hz (beating noise) because of the "pops" on the channel when you turn it on and off - unless you have an SGX or one of the core grafx systems that used the revision 6280a that doesn't have this problem. That DAC pop is annoying. The only way to cancel out the popping for something like that (on the non 6280a cpu's), is to use two channels. You alternate between updating two channels. The turning off of one, cancels out the turning on of the other - since the pop direction is in relation to the volume change on the channel. But you still need to update faster than 60hz to get to the original PCE 7khz timer method - something like 218hz updates.
The HuCard version sure as shit doesn't use the system card player, since the system card doesn't exist.
Ok. So if you added sample support for the hucard version - then what? Just not have it for the CD games?
I am talking about doing it with the regular waveform playback by bleeding notes together while changing the wave in use.
Not by enabling the actual sample mode. You don't get the same sonic capabilities as using the real sample playback, but you can still fudge some sounds. You won't really get that AirZonk dance beat "yeah *bang* yeah *bang*" 90s dance beat rap jam drum crap out of it, lol.
and yes, if sample playback were to be fudged into the HuCard player, it would only exist for HuCard projects, because we can't really modify the system card....
..... yet. 8)
PS: I am starting a new thread about MML stuff here. I hope it's exciting.
-
Holy shit that post was long ^^
edit:
https://www.youtube.com/watch?v=26xYJKunr5Q
This was pre-HuCard-Player-Ever-Existing footage of Squirrel. note the description, lol.
Here's another one:
https://www.youtube.com/watch?v=d_fJZsfQ7gs
f*ckin trackers
-
elmer: You might want to disregard my post with the driver, code, and such. The driver is just that - software driver that emulates a hardware interface for something the PCE can't normally. It's NOT a music engine, or something that specifically aid in music generation (like the PSG music player on the system card, or countless other music drivers). The HuXMPlayer is not something I'm going to finish either. That nothing more than a simple "music engine" to demonstrate the "driver". Nothing more.
Lol arkhan. You're all how and bothered now. I'll reply over at your new thread.
-
Lol arkhan. You're all how and bothered now. I'll reply over at your new thread.
Nah, I'm not hot and bothered, lol
More like, I bought 30lbs of candy corn because it was on sale, and ate like 3lbs of it in one sitting.
I think we've all just slightly misunderstood each other's word usage, and Elmer ended up thinking that I'm claiming we wrote some brand new, mind blowing player, lol
the MML thread was just made to break that discussion out because it's not HuC relevant and will just end up clogging this thread up.
-
I am not trying to state otherwise. You just misunderstand me. Or we're all misunderstanding each other slightly.
When I hear "system card player", I assume "system card" or "IFU required", which isn't true in this case now.
Yep, it's mostly just that we have different internal understandings of the precise connotations of what is meant by "System Card Player".
So you're hearing that phrase as "requires a System Card", where as I hear it as "the same software that is included in the System Card".
That comes from my having to sign long and scary contracts with folks that have big legal departments, and who don't want to get sued by a competitor for copyright infringement.
The MML compiler is the important part anyways, because the player is 100% useless without it.
Absolutely ... your work on that is/was marvelous! :D
We have already stated on here, somewhere, probably repeatedly awhile ago, that it's simply recreated for HuCard so you can use it without having to make a CD game.
But, then we get into whatever license is used for HuC's distribution. Is it actually OK to distribute the player code around in that, or do we get into that weird dicey territory? I'm not sure. I'm also not sure if, really, Hudson/NEC would come down on the whopping what, 6 people who would be partaking? lol.
Legally ... no. And as a professional in the software industry, I'm really surprised that you have to ask.
It's Hudson's code ... which makes it Konami's code, now.
Nobody has a right to distribute it without a license from Konami ... and neither did you, if you included it in Atlantean.
Practically speaking ... if Konami can't be bothered to sue Tobias for wholesale duplication of "Castlevania: Rondo of Blood", and now "Sapphire" again ... then they're not going to be bothered to come after anyone.
But some folks don't want to risk their personal reputation, and potential blowback from employers, by using unlicensed "stolen" code.
Now, I think the big mixup comes from when you'd asked about tweaking squirrel to redistribute awhile back.
Yes, I was under the impression that Aetherbyte had written its own playback code that was compatible with the System Card player.
That would have made it legal to use/license.
But that's not the case ... so it isn't.
Maybe I/we misunderstood what you were asking with regards to that. We don't own any of that code, technically. All that was ever asked for if Squirrel as a whole is used is that you credit us, and if physical copies are made, mail us a copy. That's pretty common for these scenes. That's exactly how the licensing agreement is for the player I am using for MSX that my friend wrote.
We won't share the source for the compiler for Squirrel, but, we're already sharing the player code.
I guess it's OK to redistribute that and credit as such, noting whatever changes are made and by who to get it fudged into working again.
<sigh>
You don't seem to get it .. unlike your friend, who apparently wrote his/her own playback code, and therefore has legal and moral rights to it, and can license it under whatever terms they like .. you actually have almost no rights over the playback code in the Squirrel distribution.
It's a derivative-work of someone else's copyrighted code.
The only ownership rights that you have are to the excellent comments and explanations that TheOldMan has put into the source code.
All of those could be stripped out, and the label names changed, and what would be left would be 100% functional source code that you'd have no rights over.
But it would be both rude to do that, and pointless ... since whoever did that wouldn't have any rights to it, either!
It's all a bit of a mess for people wanting to develop for the HuCard format. :(
-
Oh. I get it.
It's just, when I say "ok to redistribute", I'm speaking more loosely... to the tune of what you've already pointed out that Konami doesn't give a flying f*ck, and probably doesn't even have anyone on their staff that would understand any of the crap going on with the PCE right now.
We're talking about crap for a 30 year old console, from a company who is pulling out of the console industry, and literally said on Facebook "oh, hey! cool! You pirated Dracula X and made a boxed set! We want copies too!". They were handed copyright infringement, and said "neat! give us copies!"
All of the games any of us make are unlicensed.
Also, I could be wrong, isn't some of the stuff in MagicKit derived from the actual development kits? I don't think anyone was licensed to use that, either.
The whole thing's a bit goony, because of the target platform and such.
Hence me speaking a bit more loosely than you'd see me doing when we're talking about current commercial/professional software.
-
So, elmer, you said "Squirrel is working" but Catastrophy has been mute since the upgrade. I'm not sure if I fudged up the code, or if its a compiler issue.
Squirrel has worked fine for us, aside from the lack of any musical talent on our team of 2.
-
So, elmer, you said "Squirrel is working" but Catastrophy has been mute since the upgrade. I'm not sure if I fudged up the code, or if its a compiler issue.
Squirrel has worked fine for us, aside from the lack of any musical talent on our team of 2.
how are you calling PSGInit (or is it PSGOn, I don't remember.)
The one where you pass in what kind of timer. I think Elmer only got the VSYNC one to work, so if you have it on something else, it might just be doing diddlydick.
-
Back on topic. Avoiding the arguement.
I'd prefer to avoid the overhead of a JSR if possible (especially in a TIMER interrupt)
I understand, but that's not -quite- what I was thinking...
My thoughts were more "We need to call the user routine from an irq...If we used a standard macro name....Wonder if that would work?"
If those were something like "sound/vsync.asm", "sound/timer/asm", and "sound/system.asm", then you'd just change your PCE_INCLUDE environment variable to include whichever driver you wanted.
I was actually thinking sound.inc would be an index of the available drivers, with a protected include for each one. Then in the main program file, you would #define which driver you wanted, which would enable the main include for the driver.
You wouldn't have to change anything other that the #define to change drivers (theoretically). And, if you didn't want sound at all, you could comment out/remove the #define from the main program.
When you wanted to choose a sound engine, you could see whats available by looking at sound.inc.
........................
Just an idle question: Is it possible to replace the 'new' system stuff with the 'old' Huc stuff, and still have the compiler generate a working executable? Or have enough things in the compiler changed that that's no longer feasable?
-
I was actually thinking sound.inc would be an index of the available drivers, with a protected include for each one. Then in the main program file, you would #define which driver you wanted, which would enable the main include for the driver.
You wouldn't have to change anything other that the #define to change drivers (theoretically). And, if you didn't want sound at all, you could comment out/remove the #define from the main program.
When you wanted to choose a sound engine, you could see whats available by looking at sound.inc.
This would be good.
I have another question?
Maybe this came up before. Why not just port the HuC libs to SDCC or something, and then throw our hands up and walk away?
Is this all for curiosity's sake, or because we think that doing it this way will produce better, more PCE specific code, or something?
-
I understand, but that's not -quite- what I was thinking...
My thoughts were more "We need to call the user routine from an irq...If we used a standard macro name....Wonder if that would work?"
That could work. The question is ... where would the macros be defined?
I was actually thinking sound.inc would be an index of the available drivers, with a protected include for each one.
Where does that "sound.inc" come from, and who maintains it?
It's best to do something based upon the order of include paths, IMHO, so that people don't need to mess with the compiler or driver, or dump files into their project directory in order to change things.
Then in the main program file, you would #define which driver you wanted, which would enable the main include for the driver.
You wouldn't have to change anything other that the #define to change drivers (theoretically).
Unfortunately, theory and practice are at odds right now.
HuC doesn't seem to pass the #defines on to PCEAS, and it includes startup.asm before processing anything in you main C file anyway.
****************
Hmmmm ... OK, with a bit more thought, that could work out quite well.
You'd just have a "sound.inc" as huc/include/pce/sound.inc, and have it define some empty macros.
Then you'd just place your sound-driver include path before the HuC include path, and put a "pce/sound.inc" in there, and the compiler would find the driver's one first.
Exactly the same as you're doing with startup.asm now, but it would allow the changes to be localized to a few macros instead of replacing the entire startup.asm file.
That sounds good to me! :D
Just an idle question: Is it possible to replace the 'new' system stuff with the 'old' Huc stuff, and still have the compiler generate a working executable? Or have enough things in the compiler changed that that's no longer feasable?
If it works now, then it won't for much longer.
It's never a good idea to mix things from different distributions ... just pick the one that you want to work with.
We're basically at the point where Uli's version of HuC is fully working, and is backwards-compatible with old-HuC source code.
What would be the advantage in mixing things, or in going back to the older compiler?
Maybe this came up before. Why not just port the HuC libs to SDCC or something, and then throw our hands up and walk away?
Mainly because the 6502 port of SDCC doesn't exist yet.
I spent the summer working on the Xanadu games, and not helping with SDCC, so now the main developer is busy again.
I suspect that further development won't happen until next summer.
Is this all for curiosity's sake, or because we think that doing it this way will produce better, more PCE specific code, or something?
Curiosity, and because HuC is a relatively-easy project to modify.
Too much of CC65's code-generation has been moved into the compiler itself. It's too hard to easily modify it.
Uli has shown that HuC can still be substantially improved, with only modest effort.
I wanted to see if the register-rearrangement would be possible in practice, and if the existing HuC libraries did things that would show it to be a bad idea.
They've actually shown it to be a good idea (IMHO).
Uli's addition of the "-msmall" and "-fno-recursive" flags just follow how people use HuC in practice, and how folks avoid anything to do with the stack.
So making the stack even smaller isn't going to cause problems, and just brings benefits.
FYI ... the last time that we talked, the C stack in SDCC was going to be put onto the hardware-stack ... so it would still be limited to 256 bytes.
BTW ... making stack access "abs,x" instead of "zp,x" makes it all a little larger, and slower, and loses you some of the instructions that only work on zero-page locations.
It's not *horrible*, but I was curious about what the zero-page stack would look like.
-
Why not just port the HuC libs to SDCC or something, and then throw our hands up and walk away?
My goal is to split things up, so you only include the stuff you actually use. If you don't need scrolling areas, you don't include that code; if you do need them, you include them. If you don't need the system font, don't include it. Things like that.
I'm finally getting comfortable with HuC, and the stuff it uses. I have no desire to learn a new compiler setup, unless its something I write and am initimately familiar with. I would also like to be able to move functions, etc between compilers/assemblers/etc. I understand there would have to be changes made to do that. The basic code, however, -should- be moveable.
In theory, this would allow groups to set up a project, using what they are comfortable with, and the code could be re-built using whatever compiler/assembler/etc.
-
Yeah, it's good that some people with more curiosity and time to mess with it have proved that it can at least go somewhere. We had toyed around with the idea of rewriting stuff at one point, but I personally am more wrapped up in the game writing than the tool writing, because... the tool writing is sometimes kind of boring, and working around it in assembly turned out to not hurt that bad.
How far away is a 6502 SDCC? I could've sworn there was one.
-
So, elmer, you said "Squirrel is working" but Catastrophy has been mute since the upgrade. I'm not sure if I fudged up the code, or if its a compiler issue.
I've sent you updated versions of HuC and Squirrel that will get you back the sound again.
I've also sent the changes to Squirrel to Arkhan and TheOldMan so that they can decide if they want to change anything before they release a new version.
In the meantime, the changes to HuC are checked into github, and here's the latest build ...
https://www.dropbox.com/s/abch2ar3krr4s9u/huc-2016-11-22.zip?dl=0
This build still won't work with the old version of Squirrel's HuCard player, but it'll work with the System Card, or if someone uses a different sound driver, or no sound driver at all.
How far away is a 6502 SDCC? I could've sworn there was one.
At least a year. Progress has stalled (at least on my side).
-
I'm looking at the HuC graphics library function "fade_color()".
Has anyone tried to use this?
The code looks like it has a major bug in it, and I'm tempted to just remove it if people can't confirm that it works.
-
There's another function.. load something or other that has a bug in it. Rov' would probaby remember (loadbat or something like that?). I just remember that huc users were avoiding it, using loadvram instead (I think). Maybe someone else can confirm.
-
I think you might be referring to load_sprites(), which wasn't buggy per se, it just wasn't documented very well so some people didn't quite understand how to use it. Originally, Bt was using load_sprites() for sprites that were smaller than 32x64 and it was causing major slowdown in his run-n-gun game. I just told him that it's a function intended to load multiple large sprite blocks and that he should use load_vram() for loading sprites that are smaller. He made the change and the performance of his game returned to normal. This is the only thing I can think of along these lines.
-
I hope I'm not derailing the topic, so if I am, please let me know.
SHORT: ASM-only programming: which release of HuC / MKit to use???
Has anyone tried assembling their own .ASM program with "HUC" not defined anywhere, recently?
I'm trying to get a nice, most-recent version of HuC/PCEAS to assemble my own short test .asm files, but it's driving me crazy. For my own ASM projects, I had always used some rather old versions of PCEAS from MagicKit, simply because the libraries were short and simple.
For the tutorial videos, I thought I ought to let beginners start at an up-to-date version of HuC & use the PCEAS portion of it only-- so that if they decided they wanted to switch to HuC, they could -- ..., only to find tons of errors.
Perhaps someone here can help.
In both HuC 3.21 and 3.22 (Artemio's) if I supply a very short .ASM file with a .include "STARTUP.ASM", it gives tons of errors (.bank DATA_BANK,"User Program" Different bank names not allowed! ) , ( __ldw <_ax Unknown instruction! ) eg.
If I actually define HUC, it gives a different raft of errors.
Any known way out of this morass? Should I just stick with the oldest MagicKit?
-
Or, just not use any of the libraries with any of them. I've never used any those libraries from Mkit. And definitely not anything from HuC (startup.asm, etc) for ASM stuff. Not for the reasons you listed, but I think I do remember running into some of the same stuff as you are - in that I didn't care to sort out.. at one time (was doing it for someone else, I think).
You can still use the built in sprite, tile, and bat directives/import features without needing Mkit map routines. It's not like the PCE hardware is some convoluted design; it's clean and easy to understand, so writing your own code to show off stuffs should be easily to follow. My personal philosophy; every assembly programmer should have to learn how to write their own map routines from scratch before using anyone elses libs.
If you want a very basic library to include with your examples, I could always adapt the stuff that I use (startup routine that initializes hardware, sets up banks, jumps to main. A set of macros, print routines, etc).
Or maybe this is a better question: what is it exactly that you need from huc lib or Mkit lib?
-
Abandoning the MKit libraries going forward is not a good idea, 'cause:
1) While I don't expect to use HuC or the...er... larger library functions, I also don't want to force PCE ASM beginners to ride bareback, either.
2) It means the MagicKit libraries become mere support functions for HuC only, rather than things to support actual humans who might use the other, also useful, half of the HuC package.
-
It would just be easier to make a custom lib from HuC/Mkit library.
What exactly do you need from those libraries, though?
-
SHORT: ASM-only programming: which release of HuC / MKit to use???
Has anyone tried assembling their own .ASM program with "HUC" not defined anywhere, recently?
When I tried this last year, I just gave up. The mess of nested includes was too horrible to deal with.
I can't see why-on-earth you'd want to lock new assembly-language programmers into the horrors that are in startup.asm.
Because of all the stuff that's in there, it's just plain *nasty* trying to wade through the listing file output of a HuC project to see where you own assembly code actually is.
IMHO, if you want to make things "easy" for folks, just target the SCD with all of the built-in System Card stuff to make things simpler for people.
Both Bonknuts and I posted simple ASM skeletons (that don't pull in huge chunks of HuC) in the "Getting started programming?" thread.
You can still use the built in sprite, tile, and bat directives/import features without needing Mkit map routines. It's not like the PCE hardware is some convoluted design; it's clean and easy to understand, so writing your own code to show off stuffs should be easily to follow. My personal philosophy; every assembly programmer should have to learn how to write their own map routines from scratch before using anyone elses libs.
This. Really. This.
Another alternative is to extract your own "beginner" set of simple functions from the libraries.
Again ... if you base things on the SCD rather than the bare HuCard system, you get a whole lot of basic functionality built into the System Card, so that you can just focus on the simple flow of your lessons.
If you were using the System Card environment for the guts of the lessons, then you probably wouldn't even need much from the MKit libraries.
Abandoning the MKit libraries going forward is not a good idea, 'cause:
You are more-than-welcome to get onto github and start generating some pull-requests that clean things up a bit so that people can actually write assembly-only projects with the current tools. :wink:
-
Hmm... OK, food for thought. My vague idea for the videos had been to stay close to the hardware and thus not rely on functions, libraries, or a whole book of things to learn. Just jump right in and learn how to write things to regs... I guess it might make sense to start out with nothing and write my/our (meaning the viewer) own startup libraries...
But at the same time I did want the viewer to download 1 thing (HuC) and start up a command prompt and type PCEAS and/or be able to switch to a higher/more complex thing (HuC w/ libs or PCEAS w/ libs) if they wanted to. At this point, the latter is not possible.
-
My attempts at writing assembly-only programs with pceas (Denki version) could not succeed at all without the default libraries, at which point it seemed fruitless to even bother trying. You either use the libraries and gain very little advantage over clean HuC code, or start from nothing and attempt to lift mountains. Didn't seem to be any in-between without already being an expert in assembly.
-
Hmm... OK, food for thought. My vague idea for the videos had been to stay close to the hardware and thus not rely on functions, libraries, or a whole book of things to learn. Just jump right in and learn how to write things to regs... I guess it might make sense to start out with nothing and write my/our (meaning the viewer) own startup libraries...
Well.. take the startup routine for PCE for example: set high speed cpu mode, set stack pointer, clear ram, disable interrupts, a block of reg stuff copied to the VDC (no need to go over individually each part yet of the regs). Maybe something for the sound, map in a couple of banks. That's your basic startup.
To me, stuff like this is part of what beginners should be learning. Simply because, there isn't a nice complete set of libs out there for the system. And learning the basics makes them free'er than lib dependency. Can help with problem solving in the future too.
But you could make something, where they could reuse it for experimenting beyond or in between your tutorials (have links to downloadable stuff). A basic startup routine would be a good starting point.
But at the same time I did want the viewer to download 1 thing (HuC) and start up a command prompt and type PCEAS and/or be able to switch to a higher/more complex thing (HuC w/ libs or PCEAS w/ libs) if they wanted to. At this point, the latter is not possible.
Maybe break it off into tutorials for assembly, and a separate one for HuC?
My attempts at writing assembly-only programs with pceas (Denki version) could not succeed at all without the default libraries, at which point it seemed fruitless to even bother trying. You either use the libraries and gain very little advantage over clean HuC code, or start from nothing and attempt to lift mountains. Didn't seem to be any in-between without already being an expert in assembly.
Yeah, but if there were tutorials to show how to do all the basics, the learning curve would be that much more shortened. I'm definitely not against showing how to do tilemap routines from scratch; the exact opposite.
But it's that assembly is a specific type of environment and expectations. I've always argued that learning processor assembly is the easy part - it's learning how to use and understand all the surrounding hardware on the same low level that's the challenge. I was no expert in assembly back in 2005, even if I had some previous experience with ASM on PC and gameboy color. It took me a year to get pretty comfortable on the PCE. A year of dabbling here and there.
Ccovell: If you do plan to write some simple tilemap routines from scratch, and want to use Mappy - I have a commanline conversion tool you can use. I've not made it public, but I don't mind distributing it for tutorials (include it directly, if you need to).
FMP to PCE map converter. Ver 1.0.6-a
-Usage: fmp2pce <source.ext> -option
-o<n> <n> is the subpalette offset for the tilemap. 1 digit hex
-l<n> <n> is the length of output palette block; (n+1)*16. 1 digit hex
-v<n> Tile offset in vram (kWORDs). 3 digit hex. Default is 100h
-s Output the tile map in vertical strips instead of horizontal
-c<n> Output byte-wide collision map for <n> layer.
-e Use embedded color encoding to build palette map data in tilemap
-x1<n> Clip map: horiztonal start position. Value must be a 4digit hex
-y1<n> Clip map: vertical start position. Value must be a 4digit hex
-x2<n> Clip map: horiztonal end position. Value must be a 4digit hex
-y2<n> Clip map: vertical end position. Value must be a 4digit hex
-m16 Convert 16x16 map for 'no LUT' expansion.
-m8 Convert 16x16 map into 8x8 map. (TO DO)
-to<n> Offset collision tile # (tile# - n, saturated floor at 0x00/0x01).
^-Note: <n> is 3 digit hex max. Large values create 0/1 maps.
-z<name> Up to 10digits. Results in <name>.ext for file outputs.
'14 Tomaitheous
I remember HuC having FMP support, but I don't remember it in PCEAS. Either way, I needed more options.
-
Hmm... OK, food for thought. My vague idea for the videos had been to stay close to the hardware and thus not rely on functions, libraries, or a whole book of things to learn. Just jump right in and learn how to write things to regs... I guess it might make sense to start out with nothing and write my/our (meaning the viewer) own startup libraries...
Well.. take the startup routine for PCE for example: set high speed cpu mode, set stack pointer, clear ram, disable interrupts, a block of reg stuff copied to the VDC (no need to go over individually each part yet of the regs). Maybe something for the sound, map in a couple of banks. That's your basic startup.
To me, stuff like this is part of what beginners should be learning. Simply because, there isn't a nice complete set of libs out there for the system. And learning the basics makes them free'er than lib dependency. Can help with problem solving in the future too.
Well, I'm sure that people will have various opinions on whether I was successful or not, but...
This is exactly what I was trying to convey when I wrote and profusely commented the HuC libraries:
1) initialization sequence - what is required, and why you would want to do any of those things
2) some notes about the hardware, to build famliarity - because documentation on even the hardware itself is/was scarce
3) some standard ways of accessing the hardware, which work - so that you don't have to reinvent the wheel. Mix and match is you like.
4) some notes on a way to manage memory banks (pin one, assign "jobs" to the others for simplicity (i.e. paged code, paged data, hardware, etc.), and page them in/out as needed).
None of the above would be even close to obvious to somebody who hasn't worked on another contemporaneous paged-memory, hardware-mapped I/O system. And this is usually where people still find fault... while the code works and is commented (two things which aren't true of most business systems I have had to fix for my day job), it still isn't obvious enough for most people.
This is why my first response to everybody who wants to use assembler on the PCE has always been to start by examining the HuC libraries. Not because they're perfect in any stretch - but because they convey necessary information. In building them, I had to learn the hard way what was necessary (and why), and it was my way of sharing that hard-fought knowledge.
Having said that, I'm sure that videos would be helpful, because you can take a minute or two to explain *why* something is the way it is - whereas writing the same thing may take 30 minutes, and still not convey it well enough.
-Dave
-
Please, experts, give all your input (Like Dave, Tom, Elmer have) because I'm not one yet.
If you think of HuC as "PCE 101" in college, then I think ASM using the libraries to help you would be "PCE 201", and without libraries would be "PCE 220", if not a postgraduate course :-)
Although starting with setting up the system / banks / etc is a good idea, even for beginners to the PCE, I think some preexisting helper libraries are needed for the beginner after the basic HW init is done.
-
Please, experts, give all your input (Like Dave, Tom, Elmer have) because I'm not one yet.
If you think of HuC as "PCE 101" in college, then I think ASM using the libraries to help you would be "PCE 201", and without libraries would be "PCE 220", if not a postgraduate course :-)
Although starting with setting up the system / banks / etc is a good idea, even for beginners to the PCE, I think some preexisting helper libraries are needed for the beginner after the basic HW init is done.
Well... how far down the rabbit hole do you want to go ?
Should we assume that the consumer of your work is familiar with assembler on another processor ?
...is aware that I/O is done via memory-mapped locations ?
...is aware that IDE's, performance profilers, and single-step debuggers all came after this machine was released ?
...is familiar with the concept that code can compile and not run properly, and it may not be obvious what is wrong because there is no operating system to intervene ?
I mean... 8-bit limitations and memory mapping to circumvent address space limitation will not be obvious to modern users, unless they write operating systems.
So, please define who you think your target audience is, or what you expect of them.
-
The target is: people who already know 6502, at least. Probably some experience with NES or C64 programming. Thus, it doesn't re-teach 6502 basics.
-
If they came from the NES, c64, or even systems no 65x based but still low level, then you can probably assume some other things as well; capable of writing their own sprite routines and tilemaps. Not that a quick tutorial or video showing them how to get started would be a waste, because no matter how simple any document appears to describe something, the devil is always in the details. The PCE, not so many devils, but still..
I toyed with this issue when I was writing tutorials; should I go over 65x basics but use it as more of a stepping board to show how to use the assembler, rather than the architecture of the processor itself. I think it's a good approach, but I never really fleshed it out in the tutorials.
I mean... 8-bit limitations and memory mapping to circumvent address space limitation will not be obvious to modern users, unless they write operating systems.
If the students in my CS department are any indication (through out the undergrad range), they how no clue how any underlying stuff works. Even the ones that have take the "assembly" required course. In my Java class, they think using a dynamic ArrayList instead of an array, is faster than using an array simply because you don't have to manually copy the references to another array upon expansion. I mean, that's not even low level - it's just out of view. They think some sort of magic is happening behind the scenes, therefore is must be faster or more efficient. If someone from that level is delving into the PCE, and low level, for the first time.. may god have mercy on their soul(tm).
-
Funny. I remember first starting out on the PCE. Coming from the z80, and also the GB-z80, I couldn't figure out where the damn boot address was in the rom! I asked Dave (Dshadoff) on the ME forums, where it was - and he said it "could be anywhere". I didn't know if he was trolling me or not! I was use boot loader bios pointing to a constant address as the boot for the game code. It took me a week to realize that there was a vector in the rom that pointed to it. That was by far, the biggest hurdle I ever over came on the PCE - to this day. The frustration... ugh. I remember it to this day.
-
Funny. I remember first starting out on the PCE. Coming from the z80, and also the GB-z80, I couldn't figure out where the damn boot address was in the rom! I asked Dave (Dshadoff) on the ME forums, where it was - and he said it "could be anywhere". I didn't know if he was trolling me or not!
I honestly don't remember that.
But it wouldn't have been a troll - I try not to do that. Though, depending on how the question was phrased, we certainly might have misunderstood each other. (Though since Z-80 also uses a vector, it sounds like we shouldn't have had a communication issue...)
In any case, I'm sorry that I unwittingly contributed to the frustration.
-Dave
-
Funny. I remember first starting out on the PCE. Coming from the z80, and also the GB-z80, I couldn't figure out where the damn boot address was in the rom! I asked Dave (Dshadoff) on the ME forums, where it was - and he said it "could be anywhere". I didn't know if he was trolling me or not!
I honestly don't remember that.
But it wouldn't have been a troll - I try not to do that. Though, depending on how the question was phrased, we certainly might have misunderstood each other. (Though since Z-80 also uses a vector, it sounds like we shouldn't have had a communication issue...)
In any case, I'm sorry that I unwittingly contributed to the frustration.
-Dave
Well, I didn't know you then.. so I wasn't sure. :lol: Obviously you weren't a troll and I just probably phrased the question in a weird way. All the z80 systems I worked with had a boot rom where when the rom check passed, it'd jump to a specific rom offset to start user code (I don't remember, but this was a fixed address). I mean, it's not fixed on the z80 or gb-z80, but the bios does jump to a fixed point when the rom checks out/passes. That's what I was looking for on the PCE; a fixed boot address.
I didn't have any tutorials. While there were some magickit demos, they used library stuff and mkit had terrible documentation in relation to how to use it - I avoided them. So I learned everything from documents, and writing everything from scratch - and there was this really ancient PCE emu with a debugger (it was obscure and japanese; not the PCE one that turned into Ootake. This was a couple of years before that one). Really. crappy. inaccurate. debugger. But it did the job. I was still pretty "new" to assembly, and not too experienced with assemblers. Getting my first h-int code with screen effects working for the first time on PCE, was a pretty amazing feeling. If I managed without tutorials and examples, I'm sure people new to low level can manage just fine with tutorials and examples.
-
In building them, I had to learn the hard way what was necessary (and why), and it was my way of sharing that hard-fought knowledge.
Hi Dave,
I'm getting more familiar with all the hard work that went into the libraries now that I'm converting them over to the new register convention that I'm trying to implement.
There's a lot of code in there! 8)
May I ask you one quick question?
Do you have any idea of why the libraries keep a reference copy of the VDC registers in RAM in the __vdc array?
It is only done if "HUC" is defined.
Is there some reason that you can think of why the "getvdc" function in huc.asm shouldn't just read the contents of the VDC registers directly?
-
Do you have any idea of why the libraries keep a reference copy of the VDC registers in RAM in the __vdc array?
It is only done if "HUC" is defined.
Is there some reason that you can think of why the "getvdc" function in huc.asm shouldn't just read the contents of the VDC registers directly?
If I recall correctly, it's because the registers can't be read from the hardware.
Or at least not all of them can.
If that's not true, then you can probably remove the RAM references safely.
-Dave
-
If I recall correctly, it's because the registers can't be read from the hardware.
Or at least not all of them can.
+1. I know the read data can't be (ie,vdc register 2.) Think about how it works.
And, if I remember correctly, most of the others are read only, accordingto the vdc doc in the docs/pce directory.
-
If I recall correctly, it's because the registers can't be read from the hardware.
Or at least not all of them can.
+1. I know the read data can't be (ie,vdc register 2.) Think about how it works.
Yep, that's true ... but do you actually read these register values?
The only reason that the __vdc array exists is to support reading VDC registers with ...
int a;
a = vdc[4];
BUT the contents of the array aren't consistently updated when you actually use functions like disp_on()/disp_off()/set_screen_size()/scroll().
It *feels* like it's all left-over from an early version of HuC that was created before the guys started working with the CDROM and making things compatible with how the System Card does things.
So ...
Do you *read* values from the vdc[] array in HuC?
If so, why? What are you trying to achieve?
Do you *write* values to the vdc[] array in HuC?
If so, why? What are you trying to achieve?
Do you use vreg(reg,val) to *write* values to the VDC in HuC?
If so, why? What are you trying to achieve?
BTW ... those questions are for ALL HuC programmers ... I need to know what is important to keep from a compatibility POV, and what I can ditch during spring-cleaning.
And why-oh-why are the register numbers that are passed into these functions double the 16-bit VDC register number (i.e. address in bytes vs. address in words) ... but the VRAM address numbers that are passed into the vram[] array are given (sensibly) as the address-in-words???
Are there #defines for the VDC register names anywhere in HuC ... I can't seem to find them?
-
If I recall correctly, it's because the registers can't be read from the hardware.
Or at least not all of them can.
+1. I know the read data can't be (ie,vdc register 2.) Think about how it works.
Yep, that's true ... but do you actually read these register values?
The only reason that the __vdc array exists is to support reading VDC registers with ...
int a;
a = vdc[4];
BUT the contents of the array aren't consistently updated when you actually use functions like disp_on()/disp_off()/set_screen_size()/scroll().
It *feels* like it's all left-over from an early version of HuC that was created before the guys started working with the CDROM and making things compatible with how the System Card does things.
Well, if you look at the "whats.new" file, you'll see that several layers of changes went in from 3.03 to 3.13.
Sometimes, new things were cleaner - but we couldn't remove the old things because it would break peoples' code.
Around 3.10 to 3.12, it seems that somebody went to the trouble of having direct access to the VRAM registers as though they were an array ( vram[] = val), same as the vdc[] array you mention above. This wasn't me, so I can't comment much on it. I wasn't a big fan of arrays because they really can't be made fast on this machine, even if there is some elegance to the idea.
-
Sometimes, new things were cleaner - but we couldn't remove the old things because it would break peoples' code.
Since I'm already going to be breaking 100% backwards-compatibility with the change in register assignments, then I think that it's an opporuntity to do some other cleanup.
The idea would be to create a new branch of the project with the changes and so avoid breaking the compatibility that's in my current version of Uli's improvements.
My desire would be to make minimal (if any) changes that would break *current* HuC code usage, but have a little more flexibility with assembly coders (who should be experienced-enough to cope with a few simple changes).
Around 3.10 to 3.12, it seems that somebody went to the trouble of having direct access to the VRAM registers as though they were an array ( vram[] = val), same as the vdc[] array you mention above. This wasn't me, so I can't comment much on it. I wasn't a big fan of arrays because they really can't be made fast on this machine, even if there is some elegance to the idea.
I quite like the idea of the vram array from an "isn't-that-a-clever-idea" POV, but having it as a deliberate function call does make it a bit clearer that there's some underlying cost involved.
There's also the implication that if they are arrays, then you can create a pointer to that array.
IMHO there's not much *reason* that I can really see for keeping either the vdc[] or the vram[] semantics.
At the end-of-the-day, they both just come down to subroutine calls in assembly language, and the duplication of the code (because of the different interfaces) is a bit offensive.
So, if they're not used by current HuC users, then they'll be removed.
*****************
I have another question ...
Does anyone know why there's special-handling for bank $FE in this HuC code?
What is in bank $FE? I've never heard of anything being in that bank before. :-k
; ----
; map_data
; ----
; map data in page 3-4 ($6000-$9FFF)
; ----
; IN : _BL = data bank
; _SI = data address
; ----
; OUT: _BX = old banks
; _SI = remapped data address
; ----
map_data: ldx <__bl
; ----
; save current bank mapping
;
tma #3
sta <__bl
tma #4
sta <__bh
; --
cpx #$FE
bne .l1
; --
stx <__bp
rts
; ----
; map new bank
;
.l1: stz <__bp
; --
txa
tam #3
inc A
tam #4
; ----
; remap data address to page 3
;
lda <__si+1
and #$1F
ora #$60
sta <__si+1
rts
-
Does anyone know why there's special-handling for bank $FE in this HuC code?
Not certain about this, by any means, but...
Huc generates a 'hidden' bank for subroutine calls, so that they can be mapped in if required.
I think that may be why HuC subroutines have to be 'call' ed, so they can be mapped in.
I've run into situations where HuC/Pceas will place subroutines from the same file into
different banks. If those routines happen to be all assembler (Yes, I do that), you can't do
a jsr to call the routines. You need to use the HuC call.
Also, I use the vram[] syntax quite a bit for 'quick and dirty' access to sprite/bat information,
especially if I'm using vram as a map. Never used the vdc[] syntax, though.
-
I quite like the idea of the vram array from an "isn't-that-a-clever-idea" POV, but having it as a deliberate function call does make it a bit clearer that there's some underlying cost involved.
This was also my opinion.
I have another question ...
Does anyone know why there's special-handling for bank $FE in this HuC code?
What is in bank $FE? I've never heard of anything being in that bank before. :-k
; ----
; map_data
; ----
; map data in page 3-4 ($6000-$9FFF)
; ----
; IN : _BL = data bank
; _SI = data address
; ----
; OUT: _BX = old banks
; _SI = remapped data address
; ----
map_data: ldx <__bl
; ----
; save current bank mapping
;
tma #3
sta <__bl
tma #4
sta <__bh
; --
cpx #$FE
bne .l1
; --
stx <__bp
rts
; ----
; map new bank
;
.l1: stz <__bp
; --
txa
tam #3
inc A
tam #4
; ----
; remap data address to page 3
;
lda <__si+1
and #$1F
ora #$60
sta <__si+1
rts
Well, looking at that code, I don't think that there's anything special about bank $FE per se.
As the banks are assigned as two sequential banks at the same time, this looks like:
a) an attempt to protect people from mapping the I/O Bank ($FF) as data, and
b) a secret way to get the bank mappings back, without actually changing them.
Again, not my code, so I can't comment any further about specific intent.
Dave
-
Just another quick question for developers ...
I've rewritten HuC's standard string "strcpy/cmp/..." and "memcpy/cmp/..." to be a bit more respectable for a 6502-platform.
From what I can see, the old HuC didn't actually return the ANSI-standard pointer values from those functions, so I doubt that people are relying on them ... but I thought that I'd better check if anyone was actually looking at the zero-page locations themselves for the pointers.
Now Uli had actually changed the functions to return the ANSI-standard values, which is almost-always just a copy of the original pointer that's passed into the function ... which is great from the POV of standards-compliance, but is absolutely useless in practice (in my experience).
That ANSI definition has annoyed me for decades, so would anyone object if I just have the functions return a pointer to the end of the string/memory, which is something that is actually useful information? :-k
-
I have another question ...
Does anyone know why there's special-handling for bank $FE in this HuC code?
What is in bank $FE? I've never heard of anything being in that bank before. :-k
; ----
; map_data
; ----
; map data in page 3-4 ($6000-$9FFF)
; ----
; IN : _BL = data bank
; _SI = data address
; ----
; OUT: _BX = old banks
; _SI = remapped data address
; ----
map_data: ldx <__bl
; ----
; save current bank mapping
;
tma #3
sta <__bl
tma #4
sta <__bh
; --
cpx #$FE
bne .l1
; --
stx <__bp
rts
; ----
; map new bank
;
.l1: stz <__bp
; --
txa
tam #3
inc A
tam #4
; ----
; remap data address to page 3
;
lda <__si+1
and #$1F
ora #$60
sta <__si+1
rts
Looks like a runtime check to me. Which shouldn't be there, unless you believe you can physically damage the PCE by writing to some unknown or known bits of the VDC regs. It's $fe because the routine is mapping a bank in as 16k code; so $fe/$ff.
-
Now Uli had actually changed the functions to return the ANSI-standard values, which is almost-always just a copy of the original pointer that's passed into the function ... which is great from the POV of standards-compliance, but is absolutely useless in practice (in my experience).
That ANSI definition has annoyed me for decades, so would anyone object if I just have the functions return a pointer to the end of the string/memory, which is something that is actually useful information? :-k
I've never used/assigned the value returned from those functions, so it doesn't matter to me personally either way.
-Dave
-
That ANSI definition has annoyed me for decades, so would anyone object if I just have the functions return a pointer to the end of the string/memory, which is something that is actually useful information? :-k
I've never used/assigned the value returned from those functions, so it doesn't matter to me personally either way.
I agree, I've never found the "standard" return values to be useful.
But I can't count the number of times that I've had to do ...
strcpy(ptr, string);
ptr += strlen(ptr);
It would be much nicer (and faster) to say ...
ptr = strcpy(ptr, string);
I think that I'll take advantage of the fact that the "classic" HuC didn't set the return values at all in order to make the change.
I've actually done that already, and checked-in the new str/mem functions into github.
The new functions are approx 60% of the size of the old functions, but run 2 or 3 times faster (depending upon which function).
That's 230 bytes for the package vs 398 bytes in the old HuC.
It leads me into a bit of a "rant" about the dangers of using macros in assembly language.
**************************************
Macros are great ... they're useful for inlcuding common little sequences of code in a single instruction that can make code easier to write, and easier to read.
But it's easy to get lazy and not really think about what is going on inside them, and end up writing sloppy code if you're not careful.
This isn't so bad in a function that gets called once in a game ... but it's not good practice in library functions that are supposed to be small and fast, especially if you're thinking that new programmers might look at them as examples of how-to-program.
For instance, here the old HuC/MagicKit library function for memcpy() ...
_memcpy.3: __stw <_ax
.cpylp: lda [_si]
sta [_di]
incw <_si
incw <_di
decw <_ax
tstw <_ax
bne .cpylp
rts
It looks nice-and-simple, and it's easy to read, and it's so short that it must be fast, right?
Well ... no!
There are a whole bunch of macros in there, which expand the code out into ...
_memcpy.3: stx <__ax
sta <__ax+1
.cpylp: lda [__si]
sta [__di]
inc <__si
bne .l1
inc <__si+1
.l1: inc <__di
bne .l2
inc <__di+1
.l2: sec
lda <__ax
sbc #1
sta <__ax
lda <__ax+1
sbc #0
sta <__ax+1
lda <__ax
ora <__ax+1
bne .cpylp
.done: rts
That's a *huge* and *slow* inner-loop, taking 68 cycles per byte that's copied.
If you get rid of all of those macros and just write it carefully in optimized assembly language, you get ...
_memcpy.3: stx <__temp
tax
beq .done_pages
cly
.copy_page: lda [__si],y
sta [__di],y
iny
bne .copy_page
inc <__si+1
inc <__di+1
dex
bne .copy_page
.done_pages: ldx <__temp
beq .done_bytes
.copy_byte: lda [__si],y
sta [__di],y
iny
dex
bne .copy_byte
.done_bytes: rts
The function is both smaller, and a lot faster, taking 22 cycles per byte that's copied. :D
That's a 3x improvement in speed, and just about as good as you can get on the classic 6502 architecture.
You can do a little loop-unrolling to make it a tiny bit faster ... but it's not a huge improvement.
This version trades that little bit of speed in favor of staying smaller since it's a rarely-used function in a PCE game.
As bonknuts and touko will point out, the way to do it more efficiently on the PCE is to use a TII instruction, which runs at 6 cycles per byte.
I'm just not convinced (yet) that these functions are used often-enough that it's worth the increase in code-size for making a general-purpose TII version of the routine.
-
Minus the overhead, isn't that 20 cycles a byte? Just 6 more bytes to unroll and drop it down to 17 cycles a byte (minus overhead).
Maybe it's not used because it was so slow? Get it down to 9cycles a byte with self-modifying Txx (16 bytes) code, and maybe it'll be more valuable.
So.. what is the function anyway.. memcpy()? Is there a fmemcpy()?
-
Minus the overhead, isn't that 20 cycles a byte? Just 6 more bytes to unroll and drop it down to 17 cycles a byte (minus overhead).
Maybe it's not used because it was so slow? Get it down to 9cycles a byte with self-modifying Txx (16 bytes) code, and maybe it'll be more valuable.
Yep, 20 cycles-per-byte for the upper loop, but 22 cycles-per-byte for the lower loop.
6-bytes more for 17-cycles-per-byte? I'd be interested in seeing that!
The best (simple change) that I can do is this ...
_mempcpy.3:
_memcpy.3: stx <__temp
cly
tax
beq .done_pages
.copy_page: lda [__si],y
sta [__di],y
iny
lda [__si],y
sta [__di],y
iny
bne .copy_page
inc <__si+1
inc <__di+1
dex
bne .copy_page
.done_pages: lsr <__temp
ldx <__temp
beq memstr_finish
bcs .copy_1byte
dex
.copy_2bytes: lda [__si],y
sta [__di],y
iny
.copy_1byte: lda [__si],y
sta [__di],y
iny
dex
bpl .copy_2bytes
.done_bytes: rts
That costs 15 bytes ... and it only gets me down to 18-cycles-per-byte on the upper loop, and 19 cycles-per-byte on the lower loop,
These strxxx/memxxx routines are located in the permanent LIB1 bank, and I'm trying to free up space in there.
At this point they're 2..3 times faster than before, and so small that (IMHO) they're just not good candidates for moving into the LIB2 bank.
Maybe it's not used because it was so slow?
I just don't see memcpy() as being one of those functions that gets called a lot during each cycle of a game's main loop, and so I don't think that it's something that would benefit from being much faster.
If someone deserately needs a *fast* memcpy(), then they're better-off with an inline TII instruction.
It's a cost-vs-benefit tradeoff for the most-likely usage of the functions.
"Yes" ... it can be made faster. But would anyone care?
So.. what is the function anyway.. memcpy()? Is there a fmemcpy()?
Plain-old memcpy(). It's at the bottom of the include/pce/library.asm file.
-
"Yes" ... it can be made faster. But would anyone care?
Probably not me, haha :D I have used memcpy() a grand total of once in all my years of coding in HuC... it's used in Mysterious Song, in the battle program, once. :lol:
-
6-bytes more for 17-cycles-per-byte? I'd be interested in seeing that!
Doh! I meant 6 more load/stores (unrolled). Haha, yeah not bytes.
_memcpy.3:
stx <__temp
tax
beq .done_pages
cly
.upper_loop
lda [__si],y
sta [__di],y
iny
lda [__si],y
sta [__di],y
iny
lda [__si],y
sta [__di],y
iny
lda [__si],y
sta [__di],y
iny
bne .upper_loop
inc <__si+1
inc <__di+1
dex
bne .upper_loop
.done_pages
lda <_temp
beq .out
and #$fc
beq .left_overs
tax
.lower_loop
lda [__si],y
sta [__di],y
iny
lda [__si],y
sta [__di],y
iny
lda [__si],y
sta [__di],y
iny
lda [__si],y
sta [__di],y
iny
dex
bne .lower_loop
.left_overs
lda <_temp
and #$03
beq .out
tax
.loop_lastbytes
lda [__si],y
sta [__di],y
iny
dex
bne .loop_lastbytes
.out
rts
(I remember doing something similar in x86 asm, where bulk was done as 32bit copies, and the remaining bytes were byte copies)
"Yes" ... it can be made faster. But would anyone care?
I try to think outside of my own perspective. Of course the solution would be simply with a little bit of ASM, but not every one whats to learn or use ASM. Plus, I dunno - I have no idea what some higher level programmers have in mind when they design stuffs - haha. The only think I can think of is copying far data to near memory, in an HuC scenario (since no direct bank control).
I just don't see memcpy() as being one of those functions that gets called a lot during each cycle of a game's main loop, and so I don't think that it's something that would benefit from being much faster.
Maybe. But I'm thinking worse case scenario; where it might get called every so many frames. Then it becomes part of max resource profile. But you've already improved performance by a lot, so I guess a couple of cycles per byte savings isn't something to sweat.
-
So (to lazy as the moment to look at memcpy() arguments. The ".3" tells me there's argument overloading), but how fast is peek()? In other words, if you want to only copy a handful of bytes (say you have a large area for a stage, but you want to move "objects" in and out of active window area).
-
So (to lazy as the moment to look at memcpy() arguments.
"fastcall memcpy(word di, word si, word acc)",
The ".3" tells me there's argument overloading), but how fast is peek()?
Do you mean this? It's the version with the new register layout ...
_peekw: sta <__ptr+0
sty <__ptr+1
ldy #1
lda [__ptr],y
tay
lda [__ptr]
rts
In other words, if you want to only copy a handful of bytes (say you have a large area for a stage, but you want to move "objects" in and out of active window area).
IMHO, HuC's large overhead in doing anything is going to dwarf any small 1-or-2-cycle-per-byte inefficiency in memcpy().
As The Old Rover pointed out ... he's not using memcpy() in Henshin Engine or in Lucretia, and DK isn't using it anywhere in Catastrophy.
It's a case of the classic optimization "truth" in programming ... 90% of the CPU time is spent executing 10% of the code.
There's little point in making stuff-that-isn't-used bigger in order to make it faster, when that memory could be better-used by optimizing things that do get used all the time ... like the horrible load_vram() function that desperately needs to be rewritten to use TIA instructions.
-
like the horrible load_vram() function that desperately needs to be rewritten to use TIA instructions.
This, absolutely this. Our final level currently has a hardware only (not in emulator) glitch when doing a relatively small load_vram() set. Yeah, I could divide it into different frames, but that is extra code.
Also, I'm confused on #includes.
Lets say we load a 32x64 sprite:
#incspr(Plug, "spr/example.pcx", 0,0,2,4);
load_vram(0x4000, Plug, 0x200);
This works fine.
#incspr(Plug1, "spr/example.pcx", 0,0,2,2);
#incspr(Plug2, "spr/example.pcx", 0,32,2,2);
load_vram(0x4000, Plug1, 0x200);
This makes a garbage sprite. What is the extra stuff between sprites in ROM?
-
.code
.data
.dw $0
_plats:
.incspr "sprites/plats2.pcx",0,0,2,1Just an example from the current sourcecode I'm working with. I'm guessing that this .dw $0 is messing ya up. I guess it puts a 0 between each sprite block?
-
Just an example from the current sourcecode I'm working with. I'm guessing that this .dw $0 is messing ya up. I guess it puts a 0 between each sprite block?
I've looked at the Catastrophy source, and I don't think that it's always a "0" that's actually assembled in there by PCEAS.
I'd love to know *why* HuC/PCEAS is putting *anything* in there???
At some point I'll probably find the time to track it down, but I'd sure love someone to save me that time and just tell me is going on! :-s
-
I see this too, same source code:
.code
.data
.dw $0800
_font:
.incchr "tiles/gamefont.pcx",0,0,32,3
-
I see this too, same source code:
.code
.data
.dw $0800
_font:
.incchr "tiles/gamefont.pcx",0,0,32,3
That looks like the size (in words) of the graphic data.
-
Hrm... I am not sure, as 32x3 8x8 tiles comes out to 0x600 words, not 0x800 words... unless the compiler is assuming 32x4 for some odd reason?
-
I see this too, same source code:
.code
.data
.dw $0800
_font:
.incchr "tiles/gamefont.pcx",0,0,32,3
That looks like the size (in words) of the graphic data.
Isn't 32x3 (i.e. the standard 96 character ASCII font) times 32-byte characters = $0C00 bytes, $0600 words?
<EDIT>
Hrm... I am not sure, as 32x3 8x8 tiles comes out to 0x600 words, not 0x800 words... unless the compiler is assuming 32x4 for some odd reason?
Hahaha ... you beat me to it! :wink:
-
Hrm... I am not sure, as 32x3 8x8 tiles comes out to 0x600 words, not 0x800 words... unless the compiler is assuming 32x4 for some odd reason?
IIRC, the pcx->pce conversion routine works in 16x16 pixel blocks. (ie, sprite-sized).
I prefer to use an external converter and a #incbin() nowadays, due to stuff likethis,
-
I see this too, same source code:
.code
.data
.dw $0800
_font:
.incchr "tiles/gamefont.pcx",0,0,32,3
That looks like the size (in words) of the graphic data.
Isn't 32x3 (i.e. the standard 96 character ASCII font) times 32-byte characters = $0C00 bytes, $0600 words?
I was thinking 0 to 3 as four rows, but then 0 to 32 still didn't make sense. I dunno. It's the closest number I could think in relation to it. Maybe vram address?
-
It probably is size. HuC is probably setting aside 0x800 because 32x3 isn't a multiple of 16 but 32x4 would be. I've noticed that the compiler crashes if I use an image with a width that isn't a multiple of 16 but is still otherwise technically valid (like 31 8x8 tiles wide).
-
So, its inserting a random zero into the rom, in between incspr? That seems lame.
Also, a faster load_vram would be amazing. wink wink nudge nudge say no more.
-
A less-glitchy scroll() would be amaze. :D But I understand how difficult this is to do.
-
It probably is size. HuC is probably setting aside 0x800 because 32x3 isn't a multiple of 16 but 32x4 would be.
I've found it in the HuC source, and it does sort-of look like something to do with size.
It's set to $0000 for .incpal, .incbat and .incspr, $0800 for .incchr and $1000 for .inctile.
It's used by the set_tile_data() function when used with 3 parameters.
If you use the set_tile_data() function with 1 parameter, then the the tile size is read from the data itself.
You can always override the tile size with set_map_tile_type().
Basically ... it's an ill-concveived way to tag the format of the data.
It will be removed.
So, its inserting a random zero into the rom, in between incspr? That seems lame.
Very lame.
A less-glitchy scroll() would be amaze. :D But I understand how difficult this is to do.
What's wrong with scroll()?
Remember ... I don't use this stuff, I'd need a good explanation of the problem before it could be looked at.
-
What's wrong with scroll()?
Remember ... I don't use this stuff, I'd need a good explanation of the problem before it could be looked at.
IIRC, Rover had this issue where it's slow, so doing other things (like using Squirrel) can cause flicker/line spazzery.
It also only lets you have 4 regions by default.
-
IIRC, Rover had this issue where it's slow, so doing other things (like using Squirrel) can cause flicker/line spazzery.
scroll() is hooked into the hsync irq. It has to monitor the raster-hit irq bit.
One problem with that is, I think, that it re-sorts it's list (at least thats what I think it's doing) during this process.
Which leads to the problem; if something is already in an irq (be it vsync or timer), the hsync routine can get delayed, causing the scroll area adjustment to be delayed a line.
I'm not entirely sure why/when it happens, but it does happen. Especially is squirrel is running at a high timer rate, or if lots of small regions are being constantly scrolled.
I think this could be solved if the code maintained a dual-buffer setup; the current list could be used for the irq (and it could be really fast) and the 'new' list could be updated/sorted as needed, and moved to the current list during vsync.
But thats all only a wild guess, and I'm not sure it would actually fix the problem.
-
If the problem is because Squirrel is running on the TIRQ instead of V-INT, then just simply add two small bits of logic at the very start of the TIRQ routine; check flag if TIRQ already in progress; if so skip it (return out). There's no need to buffer anything. If the next TIRQ call is "open", it'll get handled there (and so on). Secondly, if the check flag is clear - set it and immediately re-enable interrupts. Just make sure to clear it on TIRQ exit. This logic should be fast/tight at the beginning of the TIRQ; stz $1403, don't even bother pushing Acc on the stack - use a BBRx opcode to check flag and branch out (to an RTI).
If you're already doing this AND it's still delaying H-int routine - then you need to seriously look at both to find out what's going on. Because you have 455cycles to set X/Y regs - they're buffered. I.e. If the H-int routine got delayed and ends up setting X/Y 3/4 way into the routine, it should still work.
-
It also only lets you have 4 regions by default.
What-on-earth do you want more than 4 regions for??? :-k
I was thinking about reducing it to 3 regions in order to speed-up the sorting time!
A 3-region sort can be done in 3 compares.
A 4-region sort can be done in 5 compares (HuC uses a bubble-sort with up to 6 compares).
A 5-region sort can be done in 9 compares (the bubble-sort would take up to 10 compares).
I can see the *potential* use for 4 regions in a split-screen game with status bars at the top and bottom ... but who-on-earth would write that in HuC, and if they did, why wouldn't they just use sprites for the top and bottom status bars???
If the problem is because Squirrel is running on the TIRQ instead of V-INT, then just simply add two small bits of logic at the very start of the TIRQ routine
...
If you're already doing this AND it's still delaying H-int routine - then you need to seriously look at both to find out what's going on.
scroll() is hooked into the hsync irq. It has to monitor the raster-hit irq bit.
One problem with that is, I think, that it re-sorts it's list (at least thats what I think it's doing) during this process.
Which leads to the problem; if something is already in an irq (be it vsync or timer), the hsync routine can get delayed, causing the scroll area adjustment to be delayed a line.
I'm not entirely sure why/when it happens, but it does happen. Especially is squirrel is running at a high timer rate, or if lots of small regions are being constantly scrolled.
From what I've seen, the scroll() does it's sorting and preparation during the vblank interrupt.
The stuff that's done in the hsync interrupt isn't particularly slow.
As Bonkuts said, this sounds more like an interrupt-handling issue, or someone is using Txx instructions with larger than 32-byte transfers which are delaying the interrupt.
And for gawd's sake ... why run Squirrel in a timer-interrupt anyway???
I find it highly-unlikely that anyone is currently creating music complicated-enough that a 120Hz or 240Hz timer-interrupt would make an substantial quality-difference to the stepping in the envelopes/sweeps.
IMHO, part of the "sound" of these old consoles is that the music drivers ran at 60Hz.
And if anyone is using Squirrel on a 60Hz timer interrupt instead of the vsync interrupt, then they need to be slapped around the face with a wet kipper.
Is there a list anywhere of HuCard games that ran music drivers at 120Hz with a timer interrupt???
-
IMHO, part of the "sound" of these old consoles is that the music drivers ran at 60Hz.
i agree and it's difficult with that to play PCM with timer interrupt .
-
I very frequently use all four scroll regions.... both Henshin Engine and Lucretia do this. Henshin Engine's stage 00 actually needed five, but I found a way to work around that with dynamic tiles and sprite tricky-trickies. :lol:
-
What-on-earth do you want more than 4 regions for??? :-k
(faked) multi-layer parallax. Say, 3 sky sections and 3 ground sections.
why wouldn't they just use sprites for the top and bottom status bars???
Because they're in use for enemies/shots/etc. Not to mention, it's easier to update the BAT than it is to re-load the sprite data (especially for scoring).
From what I've seen, the scroll() does it's sorting and preparation during the vblank interrupt.
What version of scroll are you looking at?
I don't see how this would be possible (ie, only sort/prepare during v-blank) without some kind of buffer....
why run Squirrel in a timer-interrupt anyway???
Because we would like to speed the sound up during boss battles. And tempo adjustments are only available using the timer irq.
I find it highly-unlikely that anyone is currently creating music complicated-enough that a 120Hz or 240Hz timer-interrupt would make an substantial quality-difference to the stepping in the envelopes/sweeps.
Take it up with Arkhan. He had a 135 BPM song with 32'nd notes for an arpeggio using faked adsr envelopes. It made a difference to him.
And if anyone is using Squirrel on a 60Hz timer interrupt instead of the vsync interrupt, then they need to be slapped around the face with a wet kipper
...where's that wet kipper. I owe him a few, I guess....
.........................................
As Bonkuts said, this sounds more like an interrupt-handling issue
I agree. I just don't know which irq is actually causing the problem, or why.
The bios guys were pretty good, imo. Vsync/HSync/Timer already have lockouts to prevent multiple nested calls (ie, if you get a hsync and are already servicing one, it will return right away). The bios player also has a sound lockout (ie, if it's in use, and an irq occurs, the sound part of the irq returns immediately).
It's been a while since I looked at all this, though. And I never was good with irq code.
I very frequently use all four scroll regions.
Rover: We did 5 or 6 on the pp title screen. You just have to adjust some sizes for the scroll list.
Not something I'd want to do in a high-speed game (unless scroll became way faster), but definately fixable. Without sprite/tile trickery.
-
Is there a list anywhere of HuCard games that ran music drivers at 120Hz with a timer interrupt???
Not that I know of, but anecdotally, Keith Courage & Neutopia (though the former only needs it for sound effects). Out Live runs its music routine at around 108Hz.
-
Well.. the whole 60hz vs something higher is a never ending debat. I personally think anything higher than 60hz is a waste for what it offers and what it requires. And that's personal preference, but more to the point, only note parsing needs to be done at TIRQ rate. Doing anything else at that rate is lazy and resource wasteful (you're not going to hear the difference in drop of an envelope at a rate higher than a 60hz tick - simply because such things are always in the LF range, like vibrato and everything else in the real world of music). Also, you can do increased tempo on 60hz tick with fixed point system, but purists scuff at the idea.
The only thing I really take issue with (if you want to eat the additional resource for higher than 60hz, than fine), is when people let the TRIQ drift out of sync. The max resource for parsing all channels and having to do something, mixed at an inopportune time - sucks. Anchor that bitch in every v-int call so it doesn't drift.
Though I think a better compromise is 120hz, re-sync'd TIRQ, and fixed point system for tempo control (as well as note length). But the programmer in me says 60hz or GTFO... damn ass musicians always wanting the world lol.
If the PCE actually had a real PAL system (that unreleased TG doesn't count - not official), then using the Timer could make sense in that respect; music runs the same regardless of the system. Though that's being pretty lazy.
What-on-earth do you want more than 4 regions for??? :-k
AirZonk clone.
Normally, I'd suggest emulating HDMA setup of the snes. An array for; x.lsb, x.msb, y.lsb, y.msb, bit flag for sprites on/off;bg on/off, color #0 updating, and finally one for RCR. Since H-INT uses a jump indirection, you could limit what features to use. Let the programmer build the table each vblank. The problem, is trying to manage those tables via C code. This is where the idea fails. I wrote one for someone using HuC.. then when I wrote some demo code to update the arrays in C - I was horrified by the performance hit.
-
As Bonkuts said, this sounds more like an interrupt-handling issue, or someone is using Txx instructions with larger than 32-byte transfers which are delaying the interrupt.
I just looked at Squirrel 3.0 hucard code, and it's setting a flag and reenabling interrupts at the start of the call, so I'm not sure what Rov was experiencing. Made an older version?
-
Please forgive my ignorance but what is the sort all about? Is there a specific way the scroll() regions should be used? I've always done them top-to-bottom, but if there's a faster/better way, then spill the beans, yo :D
-
....what is the sort all about?
My understanding is that the scroll regions are sorted by display lines. Then, when an hsync occurs, you don't have to look for the region to see if things need changed. Because they are sorted, you can check the current region, and if its the correct line, update the scroll registers and move to the next region.
Sorting is needed because the scroll regions aren't fixed in place. You can move region 1 to any (valid) spot on the screen; you can also expand/contract them, from frame to frame. So the regions need to be sorted before being used. IIRC, something like this happens in some example code on how to use them.
The problem comes in because of that; iirc, when you update a scroll region, it re-sorts them (at least in the code I was looking at). Which causes problems.
(ie, what if they are being sorted and an hysnc occurs, for a matching line? for one example)
....................
...damn ass musicians always wanting the world lol.
+1. Though in fairness, Arkhan does manage some really nice sounding stuff in a small space...
-
The problem comes in because of that; iirc, when you update a scroll region, it re-sorts them (at least in the code I was looking at). Which causes problems.
(ie, what if they are being sorted and an hysnc occurs, for a matching line? for one example)
Yeah, good point. If your code that's making these changes to the scroll are at the very edge of vblank's end, then it's possible something in vblank code is pushing it over.
Rov: You're not trying to fit all game logic inside vblank time, right? I.e. the time between vsync() and the start of active display.
-
Rov: You're not trying to fit all game logic inside vblank time, right? I.e. the time between vsync() and the start of active display.
Hell if I know. :lol:
-
Yeah, good point. If your code that's making these changes to the scroll are at the very edge of vblank's end, then it's possible something in vblank code is pushing it over.
It's not even that. Consider the following:
You have 2 scroll regions, each taking half the screen.
You also have the player playing, on the timer. It just so happens that when you start the music, the timer irq kicks off it's countdown at just before that same spot, due to initialization operations.
Now, during active display, you update the scroll areas, and they get re-sorted. The player doesn't have much to do, so its okay.
Until you hit a point in the music where a lot has to happen (for example, we need to change waves). Now the player will update. It takes longer than 'normal' because of the extra things it has to do. So your game code is delayed a little bit more than normal. And you end up (eventually) changing the parameters for the bottom scroll region. Unfortunately, because of the sorting that happens, the scroll update is delayed.
By one friggin scanline. Which means the bottom region bounces up and down.
Yes, it really does happen.
In fact, it can happen with small scroll regions near the top, and the player on vsync also.
-
Yeah, but.. why would you make changes to the scroll layout during active display? I mean, calculate your offsets during active display, sure, but stash them in a buffer, and then when vblank happens - call scroll() function over whatever iterations from the buffer. Unless I'm missing something. I don't use scroll() with HuC (I use my own h-int routine).
-
It also only lets you have 4 regions by default.
What-on-earth do you want more than 4 regions for??? :-k
https://www.youtube.com/watch?v=34PIDiVHv6g&t=54s
Status bar w/ Radar = 1 region. The f*ck if that's going to be done with sprites with that radar. Hell to the nope.
Blue area = 1 region
back row of buildings = 1 region
second row of buildings = 1 region with sprites on the roofs
floor = 4 regions, so you can create a nice line scroll parallax effect.
That's 8 regions, along with sprites to create more layering.
And for gawd's sake ... why run Squirrel in a timer-interrupt anyway???
I find it highly-unlikely that anyone is currently creating music complicated-enough that a 120Hz or 240Hz timer-interrupt would make an substantial quality-difference to the stepping in the envelopes/sweeps.
IMHO, part of the "sound" of these old consoles is that the music drivers ran at 60Hz.
And if anyone is using Squirrel on a 60Hz timer interrupt instead of the vsync interrupt, then they need to be slapped around the face with a wet kipper.
Is there a list anywhere of HuCard games that ran music drivers at 120Hz with a timer interrupt???
Something I was f*cking around with at one point with arps and dicking around required the timer.
When I started Atlantean, songs I had made were already in that environment, and code I was using was setup for it already.
I never changed it, because it didn't impact anything in the game, and I had thought about speeding up songs as mentioned, but never actually did it.
Since it doesn't hurt anything, works perfectly fine, and everyone likes the end result, I can't say I feel bad about not bothering.
Though I think a better compromise is 120hz, re-sync'd TIRQ, and fixed point system for tempo control (as well as note length). But the programmer in me says 60hz or GTFO... damn ass musicians always wanting the world lol.
The irony of this statement is quite hilarious. lol.
If the PCE actually had a real PAL system (that unreleased TG doesn't count - not official), then using the Timer could make sense in that respect; music runs the same regardless of the system. Though that's being pretty lazy.
How is that being lazy? Would you rather the music run all doofy on the wrong system?
-
Though I think a better compromise is 120hz, re-sync'd TIRQ, and fixed point system for tempo control (as well as note length). But the programmer in me says 60hz or GTFO... damn ass musicians always wanting the world lol.
Ouch, that sounds a bit expensive for a feature that I don't remember ever hearing being used.
Sure ... a slow tempo change is sometimes nice in a pop song, but you really don't hear it in classic-era videogames, do you? :-k
That's 8 regions, along with sprites to create more layering.
Doh! Pretty stupid of me to forget about parallax! #-o :oops:
OK, so more-is-better.
The problem comes down to the sort-time, and the double-buffering or whatever-other scheme that you come up with to ensure that scroll-regions don't suffer from this "instability-bounce" that The Old Rover is seeing.
Since it doesn't hurt anything, works perfectly fine, and everyone likes the end result, I can't say I feel bad about not bothering.
There's definitely the case of "if it isn't broken, then don't fix it.".
The problem is one of drift, interrupt-priority, and the desire to use the timer interrupt for sample playback.
If the interrupt-handlers are written properly so that sound driver running-on-the-timer is smart-enough to avoid delaying the handling of a vblank-interrupt, then it's not too bad ... just rather pointless when running the sound driver at 60Hz.
The question is ... is the System Card Player, and the IRQ handling in both the System Card and HuC smart enough to handle not only timer-followed-by-vblank, but also vblank-follow-by-timer???
The vblank processing MUST always have priority over the sound driver's update logic.
Would you rather the music run all doofy on the wrong system?
Well, BITD, everyone used to just change the equates for how many ticks were in a 1/16th note depending upon the PAL or NTSC target, and then *maybe* change the envelopes.
Not a huge deal, and far less of a problem than the poor European programmers that had to make their games run in a 1/60th second frame time instead of 1/50th second (20% less time per frame).
-
Though I think a better compromise is 120hz, re-sync'd TIRQ, and fixed point system for tempo control (as well as note length). But the programmer in me says 60hz or GTFO... damn ass musicians always wanting the world lol.
Ouch, that sounds a bit expensive for a feature that I don't remember ever hearing being used.
Sure ... a slow tempo change is sometimes nice in a pop song, but you really don't hear it in classic-era videogames, do you? :-k
Full disclaimer: I've never actually used a fixed point tick system for 60hz. I've only read over at nesdev forum. Actually, maybe that's not true. I've done the "mod" trick.. switching between base tick and tick+1, or tick-1, ever other frame to get in between ranges. It works. In trackers, you just increment or decrement the base tick if you want fine tempo shifts. It's not any different than doing it with the TIMER unit down counter, just that the steps are obviously larger. But again, it works. I have MODs and XMs that do this.
-
Actually, maybe that's not true. I've done the "mod" trick.. switching between base tick and tick+1, or tick-1, ever other frame to get in between ranges. It works.
I'm still trying to get my head around this ... do you mean changing the mod's base tick setting every 1/60th of a second, or on every row of the mod's pattern? :-k
In trackers, you just increment or decrement the base tick if you want fine tempo shifts. It's not any different than doing it with the TIMER unit down counter, just that the steps are obviously larger. But again, it works. I have MODs and XMs that do this.
Yes, this is what I'm more-familiar with.
Something like deflemask has "base" timings for even and odd rows of the pattern.
That allows him (for example) to set an even time of 4, and an odd time of 3, and basically have 1/16th note time be 7/60, and have 1/32nd note time be either 3/60 or 4/60 depending upon which row it is on.
Then you can change the base time for either row to speed up or slow down the tempo.
That's effectively the same thing that the System Card player is doing by encoding notes with a duration in 1/16th note increments, and then multiplying that by a base value (say 7).
In either system you're basically allowing a variable tempo, but in coarse steps:
Base Tempo = 5/60s = 180 bpm
Base Tempo = 6/60s = 150 bpm
Base Tempo = 7/60s = 128 bpm
Base Tempo = 8/60s = 112 bpm
Base Tempo = 9/60s = 100 bpm
That was good-enough BITD, and I just don't see that using a timer interrupt to provide a finely-tunable tempo is going to allow previously unheard-of streams of creativity that would outweigh the practical costs. But that's just my opinion.
-
Actually, maybe that's not true. I've done the "mod" trick.. switching between base tick and tick+1, or tick-1, ever other frame to get in between ranges. It works.
I'm still trying to get my head around this ... do you mean changing the mod's base tick setting every 1/60th of a second, or on every row of the mod's pattern? :-k
Like this:
;// Pattern line read every <n> ticks
dec RegPlayerTick
beq .FetchPatternEntry
rts
.FetchPatternEntry
lda PlayerTick.flt
eor TickMode
sta PlayerTick.flt
lda PlayerTick
sec
sbc PlayerTick.flt
sta RegPlayerTick
So if the BPM is based on down count of 3 (1/60 ticks), when that expires refill the downcount to 3-1, then on expire back to 3 - and repeat. You'd think this would get you 'warbly' sounds, but it doesn't. It gets you a BPM that's in between a 3 tick and a 2 tick. In MOD or XM files, you can set the tick on every pattern line, and a pattern line is read once the tick down count reaches 0. So it's not uncommon to see something like tick defines as 3,2,3,2,3,2,3,2 going all the way down the pattern - etc. Of course, you could do this on the player side too.
-
The problem comes down to the sort-time, and the double-buffering or whatever-other scheme that you come up with to ensure that scroll-regions don't suffer from this "instability-bounce" that The Old Rover is seeing.
Yeah, I am really curious what is going on there, since Atlantean is quite a busy game, with music, sprites, and scrolling. I never see this bounce.
The question is ... is the System Card Player, and the IRQ handling in both the System Card and HuC smart enough to handle not only timer-followed-by-vblank, but also vblank-follow-by-timer???
The vblank processing MUST always have priority over the sound driver's update logic.
AFAIK, the vsync always gets priority. I've not seen or had issues where it did not.
Also, I recall now (and OldMan reminded me), that Squirrel with vsync doesn't support tempo changing because it was a PITA, and the timer mode was not.
vsync has a fixed tempo, so you must set note durations accordingly. It kind of sucks, and I forgot about it until all of this came up.
Well, BITD, everyone used to just change the equates for how many ticks were in a 1/16th note depending upon the PAL or NTSC target, and then *maybe* change the envelopes.
lol, tell that to Shadow of the Beast for Genesis.
-
So if the BPM is based on down count of 3 (1/60 ticks), when that expires refill the downcount to 3-1, then on expire back to 3 - and repeat. You'd think this would get you 'warbly' sounds, but it doesn't. It gets you a BPM that's in between a 3 tick and a 2 tick. In MOD or XM files, you can set the tick on every pattern line, and a pattern line is read once the tick down count reaches 0. So it's not uncommon to see something like tick defines as 3,2,3,2,3,2,3,2 going all the way down the pattern - etc. Of course, you could do this on the player side too.
Well, when modules do alternating speed changes it is not to simulate an in-between tempo, it is to create a rhythmical feel where every other note is longer/shorter. If they wanted to change tempo they would just change the BPM.
Of course you could do this to simulate a different tempo but to me that would change the musical impression of the song.
60 Hz is always going to be 125 BPM in a tracker, so I would avoid creating modules in other tempos.
Anyway, back to topic perhaps.
-
Anyway, back to topic perhaps.
Good point, I'll reply to these last few messages in the MML topic where this stuff belongs. :wink:
-
Well, when modules do alternating speed changes it is not to simulate an in-between tempo, it is to create a rhythmical feel where every other note is longer/shorter. If they wanted to change tempo they would just change the BPM.
The original MOD spec doesn't allow you to change the 'BPM' setting. That's a later thing, in other trackers. And it has nothing to do with rhythmical feel. Because artists have told me what they were trying to do. I don't know about you, but I can't distinguish between a tick difference every other frame in relation to note lengths; I can only perceive it as change in tempo.
60 Hz is always going to be 125 BPM in a tracker, so I would avoid creating modules in other tempos.
No, 50hz is 125BPM. 60hz is 150BPM in trackers. Hz * 60 / 4 / 6. (The default tracker setting)
-
The original MOD spec doesn't allow you to change the 'BPM' setting. That's a later thing, in other trackers. And it has nothing to do with rhythmical feel. Because artists have told me what they were trying to do. I don't know about you, but I can't distinguish between a tick difference every other frame in relation to note lengths; I can only perceive it as change in tempo.
I was mainly talking about more advanced module formats though, like S3M, XM and IT. But for MOD this is probably true, but the same can be seen in XM songs which always had tempo control. The original MOD format is near useless as a intermediate music format.
To me it's very apparent in drum sequences. But usually it's at least a 2+ tick alternation and probably in a different BPM as well.
I recently fixed a "bug" in my replayer for PC that was causing each tick to be +-2.9 ms off (rounded to nearest audio frame of 128 samples). When I fixed this to be sample accurate there was a night and day difference, especially when you used the retrig command.
No, 50hz is 125BPM. 60hz is 150BPM in trackers. Hz * 60 / 4 / 6.
Yeah of course. I mixed up PAL and NTSC, I'm too used with PAL.
-
Ok. Elmer.. I was looking through HuC scroll handling routine and I see that the sorting is called via vblank handler. So it pretty much sets up hscroll sections immediate on vsync int.
My question to you is, should this be moved to the first hsync call - giving more time before the list gets sorted? Or leave it but provide some explanation as to how to properly layout main code in relation to a frame setup? I mean, the whole SATB happening on specifically right at vblank and NOT at the start of the display - kinda means you need to structure your frame logic differently than other systems of the era anyway. This probably isn't apparent to people dev'ing on the PCE until you try to sync sprites with the BG layer (even some professional PCE games get this wrong!).
I'm not sure if my question is clear. I can elaborate more if needed (I'll post pics!).
-
why does the list get sorted, anyways?
-
I'm guessing that because scroll() defines a "window" rather than just changes to a specific scanline, that you can have a window region inside another region? So if you define one window region from top to bottom of y1 = 128 and y2=192, but then have another window with a definition of y1=150 and y2=160. That, and one window's start position could be another window's end position, etc. It's gotta do some sort of.. sorting to figure out what to do on a specific scanline in the case of overlaps?
-
why does the list get sorted, anyways?
I'm guessing that because scroll() defines a "window" rather than just changes to a specific scanline, that you can have a window region inside another region?
It's so that you can move windows on the screen ... look at this example in Sapphire (at 7:38) ...
https://www.youtube.com/watch?v=q3bOjMekDCY
Ok. Elmer.. I was looking through HuC scroll handling routine and I see that the sorting is called via vblank handler. So it pretty much sets up hscroll sections immediate on vsync int.
My question to you is, should this be moved to the first hsync call - giving more time before the list gets sorted? Or leave it but provide some explanation as to how to properly layout main code in relation to a frame setup?
I'd recommend just documenting it and getting programmers to use it properly, but perhaps you're thinking of something that I'm failing to see.
-
So, its inserting a random zero into the rom, in between incspr? That seems lame.
Also, a faster load_vram would be amazing. wink wink nudge nudge say no more.
OK, here you go, it's an early Christmas! :wink:
https://www.dropbox.com/s/b5c2mjhof9m98h7/huc-2016-12-20.zip?dl=0
This is the cumulative changelog for the current version ...
New in version 3.99:
--------------------
2016-12-20
- Imported Uli's v3.98 version of HuC (https://github.com/uli/huc)
See README for all the changes that Uli made
- Applied changes from Artemio Urbina's fork of HuC
- Applied changes from Markus Buretorp's fork of HuC
- Fixed compilation on Windows with mingw-w64
- Fixed a few bugs related to Uli's improvements
- Changed System Card parameter equates to have a "__" prefix
- Changed startup.asm to allow a sound driver to use macros to integrate
- Removed Uli's support for interrupt handlers in HuC (they're too slow)
- New str/mem package to replace the old code
Note 1 : Strings are 255 bytes maximum (+ trailing null)
Note 2 : When a ptr is returned, it points to the end of the str/mem
This breaks ANSI/ISO compatibility, but is more useful
Note 3 : strncpy handing of the 'length' is the same as strncat
This breaks ANSI/ISO compatibility, but reduces code size
- Bumping version number for all the current changes
- Stop HuC adding an extra ".dw" to usage of .incchr/.incspr/.incpal/etc
- Add extra parameter to set_tile_data() to set the tile type (8 or 16)
set_tile_data(char *tile, int nb_tile, char *ptable, char type);
- Rewrite load_vram to use 32-byte TIA instructions (3x speed improvement)
Please note the change in the set_tile_data() function call!!! :-k
Everything is in github for those folks that want to make their own build.
-
Christmas came early!!
(https://cdn1.vox-cdn.com/thumbor/6sOIw9duFWedqBJNZr8T_FmrPmw=/1600x0/filters:no_upscale()/cdn0.vox-cdn.com/uploads/chorus_asset/file/4249419/dancerivers.0.gif)
-
Woot!
-
Woot!
Sorry, but I didn't update the load_vram in your SuperGrafx support package. :oops:
I don't think that anyone out there *currently* needs it, and I'd like to handle the SuperGrafx a bit differently when it comes to the exciting-next-gen version of HuC that I'll eventually get back to working on.
Too many projects, too little time in the day. ](*,)
-
I'm super excited for this!!!
Hopefully it will clean up some glitches, without me having to become a better programmer!
:D
-
I'm guessing that because scroll() defines a "window" rather than just changes to a specific scanline, that you can have a window region inside another region? So if you define one window region from top to bottom of y1 = 128 and y2=192, but then have another window with a definition of y1=150 and y2=160. That, and one window's start position could be another window's end position, etc. It's gotta do some sort of.. sorting to figure out what to do on a specific scanline in the case of overlaps?
I didn't even know that this was possible, honestly... the way I have it set up, each zone is set up from top to bottom with absolutely no overlap. For example... scroll region 0 might be 0 to 95, scroll region 1 might be 96 to 127, etc. I am not sure if this direction is correct or not, but the one thing I never do is something like scroll region 0 from 0 to 180 and then scroll region 1 from 90 to 120... that doesn't seem right. If my order is backwards and I should start from the bottom and go up, then that'd be ok... if it doesn't have to sort at all because the order is already sorted by hand, that'd be good. :)
-
That, and one window's start position could be another window's end position, etc. It's gotta do some sort of.. sorting to figure out what to do on a specific scanline in the case of overlaps?
I didn't even know that this was possible, honestly... the way I have it set up, each zone is set up from top to bottom with absolutely no overlap.
Yep, the sort is needed to allow for things to move on the screen ... there's the Sapphire example that I linked to. But it's not a common effect.
HuC is using a bubble-sort that exits early if there are no changes, so it's not *horribly* slow.
You're doing a good job by giving it a pre-sorted list of areas to deal with.
The classic causes for instability in an hsync split like that are ...
1) Running some code that delays the hsync interrupt for too long.
2) Having the interrupt-driven sorting code run at the same time that you're actually calling scroll() to change the screen position, and seeing a partially-written 16-bit value.
3) Letting something else interrupt the sorting code in the middle of its job.
I have no idea which of those situations you're hitting.
I forgot ... did you say whether you were using Squirrel or the System Card Player in timer mode instead of vsync mode?
I'll look at all of this stuff in detail, at some point, but I'll probably only be doing it for the even-newer HuC with the zero-page stack.
-
Elmer, I gots a question....
First, I haven't grabbed the latest version of Huc. I'm still working with the last one.
In startup.asm. line 139 (by my editor), you have a check for NEED_SOUND_BANK.
If that's true, you set PSG_BANK. (presumably to 4, but I could be wrong there)
Is that supposed to be the bank for the psg player?
If so, there's a problem. system.inc uses PSG_BANK for the bios function number.
And if you are using HuC, won't that overlap with either CONST_BANK or DATA_BANK?
Also, is LIB3_BANK used by default? My first test program compiles/runs fine as a cd with the old Huc, but complains about the banks being full when I compile as cd with the new Huc. Any ideas there?
-
In startup.asm. line 139 (by my editor), you have a check for NEED_SOUND_BANK.
If that's true, you set PSG_BANK. (presumably to 4, but I could be wrong there)
Is that supposed to be the bank for the psg player?
If so, there's a problem. system.inc uses PSG_BANK for the bios function number.
And if you are using HuC, won't that overlap with either CONST_BANK or DATA_BANK?
Good catch! :clap:
I hadn't seen the usage of PSG_BANK as a BIOS call in system.inc, and it was stupid of me not to search. :oops:
OTOH ... it's also stupid of HuC/PCEAS not to raise an error at the redefinition!!! :evil:
To-be-honest, it was a label that I copied from your startup.asm in Squirrel 3.0 ... so you've got the same bug in there! :shock:
You'd have to tell me what it is that you guys are using it for.
I just changed how the bank number itself was calculated, under the assumption that you needed a free bank for some reason.
Looks like you guys are setting it to bank 2 in HuCard builds, and the new startup.asm is setting it to 2 or 3 depending upon whether LIB3_BANK is needed.
I changed to code to set things more flexibly using .rsset and .rs instead of the tangled mess of conditionals that it was using previously, and I'm not really sure under *what* circumstances LIB3_BANK is used.
Isn't that the bank for the Arcade Card and SuperGrafx add-on libraries?
The .rs directives should change the CONST_BANK and DATA_BANK numbers depending upon how many other banks are defined/used earlier.
It's working for Catastrophy, which uses Squirrel, and for the HuC example HuCard programs, which don't.
Anyway ... since there's a conflict, it should probably be renamed to something like "SOUND_BANK".
BTW, what are you guys using it for? :-k
Also, is LIB3_BANK used by default? My first test program compiles/runs fine as a cd with the old Huc, but complains about the banks being full when I compile as cd with the new Huc. Any ideas there?
If you can send me the source to the test program, then I can find out what's going on and fix it.
The HuC example CD programs are compiling fine, so I wasn't aware of any problems.
-
To-be-honest, it was a label that I copied from your startup.asm in Squirrel 3.0 ... so you've got the same bug in there!
You'd have to tell me what it is that you guys are using it for.
Nope. I renamed the bios function numbers to PSGF_xxx.
It's used to make calls to the bios, for things like setting up wave table, envelopes, etc. And for starting playback
Look at the actual bios stuff; there's a table of functions, and those are the indexes.
And in any case, it's set to 3 explicitly in the old Huc...both places, iirc.
Which should kick up a "redefinition" warning, but since the values are the same, not an error.
...I'm not really sure under *what* circumstances LIB3_BANK is used
Yeah, I figure thats what the problem with bank overflow is.
I *think* they may be included by default.
I'll sit down tonight and figure out how the banks are being used.
But overall, I'm probably gonna have to change more than sound.inc/sound.asm to get it straightened out.
The program I'm testing with is test1.c from the squirrel 3.0 zip on aetherbyte. It uses the HuC bios
interface (a bunch of simple asm routines to call the bios functions). Most programs I've seen don't use it, other than possibly the play function.
-
To-be-honest, it was a label that I copied from your startup.asm in Squirrel 3.0 ... so you've got the same bug in there!
You'd have to tell me what it is that you guys are using it for.
Nope. I renamed the bios function numbers to PSGF_xxx.
It's used to make calls to the bios, for things like setting up wave table, envelopes, etc. And for starting playback
Look at the actual bios stuff; there's a table of functions, and those are the indexes.
And in any case, it's set to 3 explicitly in the old Huc...both places, iirc.
Which should kick up a "redefinition" warning, but since the values are the same, not an error.
This is from system.inc in the old HuC 3.21 from zeograd's lair, and it is unchanged in Uli's HuC, or in my fork of Uli's HuC ...
; --------
; This block defines PSG BIOS function
; number.
;
PSG_ON = 0
PSG_OFF = 1
PSG_INIT = 2
PSG_BANK = 3
PSG_TRACK = 4
...
This is from the customized startup.asm in Squirrel 3.0 that I downloaded a few hours ago from the Aetherbyte site ...
; ----
; setup flexible boundaries for startup code
; and user program's "main".
;
START_BANK .equ 0
LIB1_BANK .equ START_BANK
LIB2_BANK .equ START_BANK+1
.ifdef HUC
FONT_BANK .equ START_BANK+1
.if (CDROM)
CONST_BANK .equ START_BANK+2
DATA_BANK .equ START_BANK+3
.else
PSG_BANK .equ START_BANK+2
CONST_BANK .equ START_BANK+3
DATA_BANK .equ START_BANK+4
.endif
.else
; HuC (because of .proc/.endp) does not use MAIN_BANK
MAIN_BANK .equ START_BANK+2
.endif ; HUC
So, unless I'm having a terrible senior-moment, the default system.inc is setting PSG_BANK to 3, and then your customized startup.asm is setting PSG_BANK to 2.
You are setting your new PSGF_* equates in squirrel.s
Did I change those PSGF_* equates in the "fixed (or not)" version that I sent you (I'm dog-sitting and don't have access to those files right now)?
And whatever ... why-on-earth did you guys create PSGF_* aliases for the BIOS function numbers instead of using the one already defined in system.inc, and why did you create the PSG_BANK define in your startup.asm that conflicts with the defines in the old HuC system.inc ???
The program I'm testing with is test1.c from the squirrel 3.0 zip on aetherbyte.
Thanks!
I can look at it later on tomorrow.
-
If you look at the original startup.asm for the old huc,
you will find (line 33) that -we- did not define PSG_BANK.
The original HuC had the problem.
We used (and defined) the PSGF_ versions because of it.
I didn't want to break anything else that may have used them
(like the included psg player), so I left them alone. I tried to
isolate the PSGF_versions, so they were only used by
the card bios setup; I may have failed there, but it didn't
hurt anything.
I still don't understand *why* the original bank setup works...but it
does, so I left it alone.
And no, I don't think the PSGF_ equates got changed. No real
reason to do so. I think the PSG_ function equates should be
removed myself (they are only applicable for the bios player),
but I can also see where it might cause other problems.
So, unless I'm having a terrible senior-moment,....
You too? I have them all the time...:)
You are setting your new PSGF_* equates in squirrel.s
?? afaik there is no squirrel.c to generate a .s file.
And .s is a generated file, so it has to be somewhere else.
(psgdefs.h)
Okay, I'm gonna start looking now....
We -will- get this sorted out :)
-
The bank overflow problem for cds I *think* I got figured out.
..................................................................................................
I've been using bank 6 to hold the MML song codes.
Apparently, that kicks the heap to page 7. That means
there isn't enough space for the interface functions.
So: How do I disable the heap?
And any other code that got added?
I'm putting in my feature request now...Can we get an equ/define for the last page used by the system? So i don't have to go hunt for a place to put music :)
-
And the PSG_BANK problem?
The original HuC only defined PSG_BANK as START_BANK+2 if you were not compiling for a CD
(startup.asm, line 34.)
It was defined as 3 (in system.inc), which is included only if you are building a CD.
(startup.asm, line 65)
I understand why there was no conflict now.
I do think it's misleading to re-use the name that way, though.
The way you have the bank definitions set up, PSG_BANK gets set whenever NEED_SOUND_BANK is defined. If you are not building a cd, (ie, you're building a card), then
there is no problem; system.inc won't be included, and things are fine.
If you are building a CD, however, system.inc -will- be included, and you get the name clash.
Note that if you are building a CD, PSG_BANK should be 2 - that's where the bios expects the cd driver routine to be.
Personally, I'm not sure how you would fix it. I think I'd just change the name, and search for uses (if any).
..................................................................
As an aside (and I could be wrong about this). I believe PSG_BANK is where the player routine should reside. There is actually a call somewhere in the original startup that maps that in, calls it, and maps it back out iirc. One of the things I vaguely remember from doing squirrel was that the psg_bios functions may also be in in that page. I remember thinking it was stupid to do the mapping, because the page was already mapped in. That may be something else I have to look further into.
-
And the PSG_BANK problem?
The original HuC only defined PSG_BANK as START_BANK+2 if you were not compiling for a CD
(startup.asm, line 34.)
It was defined as 3 (in system.inc), which is included only if you are building a CD.
(startup.asm, line 65)
I understand why there was no conflict now.
I do think it's misleading to re-use the name that way, though.
The way you have the bank definitions set up, PSG_BANK gets set whenever NEED_SOUND_BANK is defined. If you are not building a cd, (ie, you're building a card), then
there is no problem; system.inc won't be included, and things are fine.
If you are building a CD, however, system.inc -will- be included, and you get the name clash.
Note that if you are building a CD, PSG_BANK should be 2 - that's where the bios expects the cd driver routine to be.
Personally, I'm not sure how you would fix it. I think I'd just change the name, and search for uses (if any).
..................................................................
As an aside (and I could be wrong about this). I believe PSG_BANK is where the player routine should reside. There is actually a call somewhere in the original startup that maps that in, calls it, and maps it back out iirc. One of the things I vaguely remember from doing squirrel was that the psg_bios functions may also be in in that page. I remember thinking it was stupid to do the mapping, because the page was already mapped in. That may be something else I have to look further into.
OK, looks like you guys have found a bug (yes of course they existed in HuC before - you should see some of the bugs in some of the professional games too !).
So the original PSG_BANK in startup.asm was intended to declare where the System-card-compatible-but-never-properly-working PSG code was intended to be located.
There was a conflict because the DEVELO assembler book declared this to be a subfunction type for the PSG BIOS routine (which the HuC code was intended to mimic). The assembler, as I recall, doesn't flag redefinitions of EQU values, so this never showed up as a problem during compiles, but it seems that this could be a contributing factor to why the sound driver never worked. I ran out of time to debug just as I finished the code, and left it in, in the hopes that somebody else would help debug. In the end, everybody targeted CDROM so it was never examined.
The idea about mapping is that the sound driver occupies a considerable amount of memory and should not be kept mapped. Only map it in during the interrupt, and then hide it as soon as it is no longer needed. If other code occupies the same bank, it is a coincidence. Same goes for the tune that it's playing.
-Dave
-
So the original PSG_BANK in startup.asm was intended to declare where the System-card-compatible-but-never-properly-working PSG code was intended to be located.
There was a conflict because the DEVELO assembler book declared this to be a subfunction type for the PSG BIOS routine (which the HuC code was intended to mimic). The assembler, as I recall, doesn't flag redefinitions of EQU values, so this never showed up as a problem during compiles, but it seems that this could be a contributing factor to why the sound driver never worked. I ran out of time to debug just as I finished the code, and left it in, in the hopes that somebody else would help debug. In the end, everybody targeted CDROM so it was never examined.
Thanks, Dave!
The way you have the bank definitions set up, PSG_BANK gets set whenever NEED_SOUND_BANK is defined. If you are not building a cd, (ie, you're building a card), then there is no problem; system.inc won't be included, and things are fine.
If you are building a CD, however, system.inc -will- be included, and you get the name clash.
Note that if you are building a CD, PSG_BANK should be 2 - that's where the bios expects the cd driver routine to be.
Personally, I'm not sure how you would fix it. I think I'd just change the name, and search for uses (if any).
..................................................................
As an aside (and I could be wrong about this). I believe PSG_BANK is where the player routine should reside. There is actually a call somewhere in the original startup that maps that in, calls it, and maps it back out iirc. One of the things I vaguely remember from doing squirrel was that the psg_bios functions may also be in in that page. I remember thinking it was stupid to do the mapping, because the page was already mapped in. That may be something else I have to look further into.
Hahaha ... OK, I *was* having a senior-moment, but it wasn't your code that was doing something strange, you were just trying to work around stuff in the old HuC. :oops:
I was under the impression that you'd disassembled the original System Card Player to the point where it could live somewhere other than bank 2, but I guess that I was wrong.
I was trying to engineer a solution where any new sound driver could say that it needed it's own bank, even *if* you were building for CD.
I suspect that the easiest solution (to one of the problems) is to rename that equate to SCP_BANK or SOUND_BANK, and for me to rearrange the new startup.asm to make sure that it is always in bank 2, if it is invoked. And then to document *WHY* it is that way!!!
Then I guess that we need some way to decide where the music data actually goes.
Do you know if HuC actually starts putting program data in the DATA_BANK? :-k
In Catastrophy, it doesn't *seem* to start putting data in until it reaches bank 8.
-
I was trying to engineer a solution where any new sound driver could say that it needed it's own bank, even *if* you were building for CD.
Discovery of the problem was entirely due to regression testing the compiler before I started bringing in Huc. I wanted to know it was going to work for cds before I started on the card stuff.
That's on the agenda for the rest of the week.
...easiest solution (to one of the problems) is to rename that equate to SCP_BANK or SOUND_BANK, and for me to rearrange the new startup.asm to make sure that it is always in bank 2, if it is invoked.
Got it. I can change it to SOUND_BANK here.
I believe the player part is moveable to any bank. It's the psg_bios stuff I have to check on.
Even if it currently has to reside in a specific bank, that can easily be fixed, provided we know where
it is.
I, too would like to have the player/interface moveable to any bank. Not only for cards, but for cds as well; it's the only way we are going to be able to extend the player.
Then I guess that we need some way to decide where the music data actually goes.
...
In Catastrophy, it doesn't *seem* to start putting data in until it reaches bank 8.
We left that open to the user.
The MML compiler defaults to bank 9, I believe. There is a switch to move things to a user-selectable bank(s) however. Assuming Catastrophy is using the generated snginit.c, you can look at the very end of the file to determine where the song data is placed.
Be aware that there are problems with how we do it, however. AFAIK there is no way to preserve the current bank number (in either Huc or pceasm), or even find out what it is. Thus, there is no way to return to the last bank in use. Thats a big problem, since once the song data is processed, anything after it will be in the next bank(s). That's why we say put the snginit() include at the end of the file.
The problem is compounded by the fact that HuC doesn't fill pages; things either fit or they don't, and it moves to a new page. So a small re-arrangement of code (or adding something to the program) can cause things to shrink (leaving a gap) or expand (potentially being overwritten). Bank 9 seemed to be generally available, and we had to pick some default :)
-
Okay, I looked over the psg-player code.
There are 2 routines (psg_bios and psg_driver) that *must* be in an always-mapped page.
I -believe- they were originally in START_PAGE.
psg_bios maps in the bios functions, does an indirect call, and then restores the original mapping.
psg_driver maps in the player code and music, steps the player along, and then restores things.
The actual bios functions and the player code can reside in any page that is available. Together,
they do a good job of filling a page, though. It would probably be possible to split them (since they have seperate map-in functions), but I wouldn't recommend it.
Next step is to get psg_bios and psg_driver seperated out into start.asm, and to make sure they load into the correct bank. After that, it should be easy to set the psg_xxx functions and the psg_driver into SOUND_BANK. Then, I have to setup the macros for the interrputs.
That should create a setup that is compatible across the board for the bios MML player. Cards should use the compiled-in code, and cds should use the bios code.
-
I'm putting in my feature request now...Can we get an equ/define for the last page used by the system? So i don't have to go hunt for a place to put music :)
That would be a good idea!
****************
OK, I'm back at my main computer today with the latest HuC and the copy of the working Squirrel that I sent you guys.
And I'm having trouble replicating the problem that you're seeing. :-k
The program I'm testing with is test1.c from the squirrel 3.0 zip on aetherbyte. It uses the HuC bios
interface (a bunch of simple asm routines to call the bios functions). Most programs I've seen don't use it, other than possibly the play function.
I can't find "test1.c" in the Aetherbyte_Squirrel3.zip that I just downloaded (again) from Aetherbyte.
Can you please tell me where to find it?
Can you also let me know the command line that you're using to build it?
Yeah, I figure thats what the problem with bank overflow is.
I *think* they may be included by default.
I'll sit down tonight and figure out how the banks are being used.
But overall, I'm probably gonna have to change more than sound.inc/sound.asm to get it straightened out.
My test-build makes both HuCard and SCD builds of your Squirrel.c example program, and they both run fine with no problems at all.
A build for regular CD fails with ...
966 03:60C8 .bank 9
Bank index out of range!
# 1 error(s)
But it fails in the same way on the old HuC as well.
The "sound.inc" that I sent you guys protects itself from inclusion on CDROM builds, and doesn't set NEED_SOUND_BANK on a CD build ... and so PSG_BANK doesn't get overridden, and there is no problem.
There is no conflict!!!
The only thing that I'm seeing that would be sensible to add to the sound.asm that I sent you is to add ".bank START_BANK" above the psg_bios function.
It goes in that bank anyway in the current HuC startup.asm, but it doesn't hurt to be safe.
Okay, I'm gonna start looking now....
We -will- get this sorted out :)
I really need to see that test1.c file, and whatever command line you're using ... because from where I'm standing right now, it looks like it is already sorted out in the code that I sent you.
The bank overflow problem for cds I *think* I got figured out.
..................................................................................................
I've been using bank 6 to hold the MML song codes.
Apparently, that kicks the heap to page 7. That means
there isn't enough space for the interface functions.
So: How do I disable the heap?
And any other code that got added?
Errr ... I *think* that is is all disabled by default.
You have to add a "-lmalloc" to your build line in order to get the malloc/heap added.
I'm not seeing anything at all in bank 6, I have no idea why you're seeing code in there.
I *really* need a copy of your test setup in order to replicate whatever you're seeing.
******************
Squirrel.c built as a HuCard ...
USED/FREE
ZP $2000-$2015 [ 22] 22/ 234
BSS $2200-$2985 [1926] 1926/6266
BANK 0 Base Library 1 6995/1197
CODE $E010-$FB58 [6985]
CODE $FFF6-$FFFF [ 10]
BANK 1 Base Library 2/Font 5815/2377
DATA $6000-$65FF [1536]
CODE $A600-$B6B6 [4279]
BANK 2 PSG Driver 7892/ 300
CODE $C000-$C029 [ 42]
CODE $C043-$DEEC [7850]
BANK 3 Constants 180/8012
DATA $4000-$40B3 [ 180]
BANK 4 User Program 200/7992
DATA $6000-$60C7 [ 200]
BANK 5 0/8192
BANK 6 0/8192
BANK 7 0/8192
BANK 8 0/8192
BANK 9 1227/6965
DATA $8000-$84CA [1227]
BANK A 2441/5751
CODE $A000-$A988 [2441]
BANK B 18/8174
CODE $8000-$8011 [ 18]
---- ----
25K 71K
TOTAL SIZE = 96K
******************
Squirrel.c built as an SCD ...
USED/FREE
ZP $2000-$2015 [ 22] 22/ 234
BSS $2200-$29CC [1997] 1997/6195
BANK 0 Base Library 1 7509/ 683
CODE $C000-$C027 [ 40]
CODE $402F-$406D [ 63]
CODE $4070-$4127 [ 184]
CODE $C130-$DD65 [7222]
BANK 1 Base Library 2/Font 5955/2237
DATA $6000-$65FF [1536]
CODE $A600-$B742 [4419]
BANK 2 Constants 180/8012
DATA $4000-$40B3 [ 180]
BANK 3 User Program 200/7992
DATA $6000-$60C7 [ 200]
BANK 4 0/8192
BANK 5 0/8192
BANK 6 0/8192
BANK 7 0/8192
BANK 8 0/8192
BANK 9 1227/6965
DATA $8000-$84CA [1227]
BANK A 2441/5751
CODE $A000-$A988 [2441]
BANK B 18/8174
CODE $8000-$8011 [ 18]
---- ----
18K 78K
TOTAL SIZE = 96K
<edit>
Just for reference, I'm using the latest version of HuC, and the same version of Squirrel that I sent you guys back on November 21st (the download link is still the same).
-
Finally, here's a version of squirrel.c built with the SuperGrafx library so that LIB3 is invoked, and the main Squirrel Player gets bumped into bank 3 instead of bank 2.
"huc -v -v -msmall -fno-recursive -sgx squirrel.c -lmalloc"
USED/FREE
ZP $2000-$2022 [ 35] 35/ 221
BSS $2200-$2BD6 [2519] 2519/5673
BANK 0 Base Library 1 7482/ 710
CODE $E010-$FD3F [7472]
CODE $FFF6-$FFFF [ 10]
BANK 1 Base Library 2/Font 7876/ 316
DATA $6000-$65FF [1536]
CODE $A600-$BEC3 [6340]
BANK 2 Base Library 3 405/7787
CODE $A000-$A194 [ 405]
BANK 3 PSG Driver 7892/ 300
CODE $C000-$C029 [ 42]
CODE $C043-$DEEC [7850]
BANK 4 Constants 180/8012
DATA $4000-$40B3 [ 180]
BANK 5 User Program 200/7992
DATA $6000-$60C7 [ 200]
BANK 6 0/8192
BANK 7 0/8192
BANK 8 0/8192
BANK 9 1227/6965
DATA $8000-$84CA [1227]
BANK A 2441/5751
CODE $A000-$A988 [2441]
BANK B 18/8174
CODE $8000-$8011 [ 18]
---- ----
28K 68K
TOTAL SIZE = 96K
And again, it all works!
I also tried it without the "-msmall -fno-recursive" and that works, too.
-
I *really* need a copy of your test setup in order to replicate whatever you're seeing.
I'll be mailing it in a few minutes. It's a .zip, you have to re-name it. Google won't mail zips.
I can't find "test1.c" in the Aetherbyte_Squirrel3.zip that I just downloaded (again) from Aetherbyte.
My bad. I re-named it in the test directory. It's squirrel.c
And I'm having trouble replicating the problem that you're seeing.
I didn't see you trying to build a cd version, with the mml in the right place. Bank 9 doesn't exist on a 2.0 card, and you don't appear to be re-building the mml....
Just for reference, I'm using the latest version of HuC, and the same version of Squirrel that I sent you guys back on November 21st (the download link is still the same).
Nobody sent me anything. And I don't run Java unless absolutely required, so sropbox is out.
Luckily I have friends who send me things - that's how I grabbed the compiler. But it took a couple of weeks.
.............................
FYI. This includes the new version of the mml compiler. Not for public consumption, yet.
-
I'll be mailing it in a few minutes. It's a .zip, you have to re-name it. Google won't mail zips.
OK, thanks I've got it.
My bad. I re-named it in the test directory. It's squirrel.c
OK, so it is the same file that I've been working with, and compiling successfully.
I didn't see you trying to build a cd version, with the mml in the right place. Bank 9 doesn't exist on a 2.0 card, and you don't appear to be re-building the mml....
Nope, I didn't rebuild the MML because I didn't need to ... there's already a working MML file.
And you already know that I need you guys to change mml2pce in order to add the "__" to the variable names.
So ... with your new version of mml2pce, I've built a working CD of squirrel.c, and I can see that "yes", there's a problem when you try to put the sound data in bank 6 ... but everything is happy if you change it to put the sound data in bank 5.
Err ... I'm not seeing any problem with that. The new HuC is a bit more strict about where it puts the trampoline code for banking in the .proc functions.
It now goes in the last bank in the ROM/ISO.
So if you build a regular CD, and put the sound data in bank 6 ... then the game code starts in bank 7 ... and the trampoline code goes into bank 8, which doesn't exist, and so everything fails.
The big question is why-on-earth put the sound data into bank 6???
You've got multiple wasted-banks with nothing in them much lower than that.
You should be putting the sound data into bank 4.
HuC puts all of its data first, bank-by-bank, and then it puts its code after the data banks.
By declaring that the sound data starts in bank 6 (or 5, or 9), you're just pushing all of the code into later banks and wasting space.
Nobody sent me anything. And I don't run Java unless absolutely required, so sropbox is out.
Luckily I have friends who send me things - that's how I grabbed the compiler. But it took a couple of weeks.
I sent you and Arkhan a link to the files on dropbox as part of our PM'd conversation at the time.
That seemed to be good-enough for Arkhan, and I didn't hear any complaint from you, or a request to have them sent by email instead.
Dropbox doesn't use Java (the programming language), it uses Javascript (aka ECMAscript), which is built into all web browsers. They are totally different technologies.
Now, if you choose to avoid all websites which use Javascript, then good-for-you ... but it would be helpful to know that.
BTW ... you can just install noscript or something like that to gain control over the execution of Javascript in your web browser.
****************
Anyway, I've emailed you the fully-working version of Squirrel (for both the old and new HuC).
It includes the latest change to use SOUND_BANK instead of PSG_BANK.
-
Nope, I didn't rebuild the MML because I didn't need to ... there's already a working MML file.
Yes, but it was built for an SCD. You need to re-build it for a CD, which involves specifying a cd-useable bank number.
And you already know that I need you guys to change mml2pce in order to add the "__" to the variable names.
Already in there, with the -p flag.
So ... with your new version of mml2pce, I've built a working CD of squirrel.c, and I can see that "yes", there's a problem when you try to put the sound data in bank 6 ... but everything is happy if you change it to put the sound data in bank 5.
Err ... I'm not seeing any problem with that. The new HuC is a bit more strict about where it puts the trampoline code for banking in the .proc functions.
So, if I understand this right....
It uses the entire last page for the trampoline code?
The big question is why-on-earth put the sound data into bank 6???
Because it was the highest unused bank. That way, we didn't have to keep going back and moving it
everytime we added something.
You should be putting the sound data into bank 4.
And have it over-written when we added new graphics and stuff?
(which is why we picked bank 6, after about the third time it happened...)
By declaring that the sound data starts in bank 6 (or 5, or 9), you're just pushing all of the code into later banks and wasting space.
Understood. But there's no reliable way to know the last-used bank ahead of time, that we have found. Of course, its been a few years since I looked at, and I've learned some things since then, so maybe I'll find a better way.
Keep in mind, this is a test program. Good tests highlight the problem only.
Dropbox doesn't use Java (the programming language), it uses Javascript (aka ECMAscript), which is built into all web browsers. They are totally different technologies.
Now, if you choose to avoid all websites which use Javascript, then good-for-you ... but it would be helpful to know that.
Same basic technology - the website wants to run a program on my computer. Sorry you didn't know.
Yes, I'm paranoid like that.
BTW ... you can just install noscript or something like that to gain control over the execution of Javascript in your web browser.
So i should install and run someone elses (possibly buggy, possibly invasive) program when I can just turn Java and it's variants off? And lose the added bonus of no more forced ads and tons of spam? <sarc>
Also, keep in mind I'm on XP. Does firefox 34 even support plug-ins?
Anyway, I've emailed you the fully-working version of Squirrel (for both the old and new HuC).
I'll pick it up tomorrow. E-mail me the latest compiler, too, when you get a chance, so I can check to see if I've broken anything else.
-
The web is a highly customizable experience. Let us not condescend on the web browsing choices of others.
-
I'll pick it up tomorrow. E-mail me the latest compiler, too, when you get a chance, so I can check to see if I've broken anything else.
OK, I've checked in the SOUND_BANK change into github, made a build and emailed it to you.
So i should install and run someone elses (possibly buggy, possibly invasive) program when I can just turn Java and it's variants off? And lose the added bonus of no more forced ads and tons of spam? <sarc>
Also, keep in mind I'm on XP. Does firefox 34 even support plug-ins?
You can choose to live with whatever level of paranoia you like, especially if you wish to keep on accessing the internet with an out-of-date version of Firefox on an unsupported version of Windows. :wink:
Nope, I didn't rebuild the MML because I didn't need to ... there's already a working MML file.
Yes, but it was built for an SCD. You need to re-build it for a CD, which involves specifying a cd-useable bank number.
And it all runs quite happily on HuCard, SCD, and now on CD, too.
And you already know that I need you guys to change mml2pce in order to add the "__" to the variable names.
Already in there, with the -p flag.
Thanks for adding that, and for finally making it available to me, yesterday, for testing.
Err ... I'm not seeing any problem with that. The new HuC is a bit more strict about where it puts the trampoline code for banking in the .proc functions.
So, if I understand this right....
It uses the entire last page for the trampoline code?
Well, the last "bank" not "page", but yes, that's what it appears (to me) to be doing, and then it maps it into MPR4 ($8000-$9FFF).
By declaring that the sound data starts in bank 6 (or 5, or 9), you're just pushing all of the code into later banks and wasting space.
Understood. But there's no reliable way to know the last-used bank ahead of time, that we have found. Of course, its been a few years since I looked at, and I've learned some things since then, so maybe I'll find a better way.
Keep in mind, this is a test program. Good tests highlight the problem only.
Well, it's up to you how you choose to organize your example code, but from where I'm sitting, you're just creating an artificial problem for HuC users by effectively-recommending a setup that forces all their HuC data and code into a smaller area.
Now I see why Catastrophy is sitting there with banks 5,6,7 and 8 completely empty, and with bank 4 just containing a totally-unused 200-byte table for program overlays.
I can only imagine that it all came about from the time that you guys were moving code/data from C into assembly.
-
emailed it to you.
Got it. Thx.
Well, the last "bank" not "page", but yes, that's what it appears (to me) to be doing, and then it maps it into MPR4 ($8000-$9FFF).
Right, bank. (That's the 24-bit address in the card. I still get them confused.)
I assume its not going to be a problem with the MML being mapped into pages 4 and 5, then.
...if you wish to keep on accessing the internet with an out-of-date version of Firefox on an unsupported version of Windows. :wink:
Hey, if it isn't broke, don't fix it :)
Thanks for adding that, and for finally making it available to me, yesterday, for testing.
It's been done for a couple of weeks. Was just waiting until I got the rest to be compatible.
I figured you'd get tired of fixing snginit(), though.
Now I see why Catastrophy is sitting there with banks 5,6,7 and 8 completely empty, and with bank 4 just containing a totally-unused 200-byte table for program overlays.
Feel free to move the mml into bank 5. It's simple enough to re-build the snginit() with a different page.
-
The point is to avoid new developers tripping over some black-magic problem and getting stuck by it.
This is exactly it, and I think it needs a special warning coming of PCEAS, at the end - "WARNING: Unstable ROM size - add data to 392k to fix corrupted mirroring " for exactly this fixed number of banks.
I've put a fix into the new HuC so that it always pads out a HuCard to the nearest power-of-2 ROM size (64KB, 128KB, 256KB, 512KB, 1024KB) so that nobody using it will ever hit this problem again.
For assembly-language users, there's a flag to PCEAS to invoke the option, and you'll get a warning message whenever you make a 384KB HuCard ROM without using that option ... which is a perfectly sensible thing to do if you're working on a translation patch for a 384KB Japanese game.
Now, to me, the simplest "fix" for this would be to add an optional flag to PCEAS to make it automatically pad HuCard ROMs to the nearest power-of-2, i.e. 64KB/128KB/256KB/512KB/1024KB.
Lol. <snort>. Changing HuC/PCEAS is probably going to be a pain.
Not really! :lol:
31 lines of changes, and 13 of those were just adding the warning message. :wink:
***********************
Here it is ...
http://www.dropbox.com/s/r5qbcz4xapapgye/huc-2017-02-21.zip?dl=0
And this is the changelog for the new version ...
New in version 3.99:
2017-02-21
- Fix writing of instructions/data that cross a bank boundary.
- Add "-pad" to PCEAS to pad out HuCard ROM images to next power-of-2 size.
- Change HuC to use "-raw" and "-pad" options to avoid 384KB HuCard problem.
- Add warning whenever a 384KB HuCard image is created to highlight problem.
Everything is in github for those folks that want to make their own build.
-
http://www.dropbox.com/s/r5qbcz4xapapgye/huc-2017-02-21.zip?dl=0
C:\Huc\catastrophy>pass 1
#[3] sound.asm
00:FA3B .bank PSG_BANK,"PSG Driver"
Different bank names not allowed!
(Warning. Opcode crossing page boundary $E000, bank $01)
# 1 error(s)
looks like it doesn't like squirrel anymore?
-
Well, that's odd. Especially since that's the same bank name that PSG_BANK is given by the regular magic kit code.
-
C:\Huc\catastrophy>pass 1
#[3] sound.asm
00:FA3B .bank PSG_BANK,"PSG Driver"
Different bank names not allowed!
(Warning. Opcode crossing page boundary $E000, bank $01)
# 1 error(s)
looks like it doesn't like squirrel anymore?
Have you changed the version of Squirrel from the one that I sent you a few months ago? :-k
If you remember, I had to make a bunch of changes to Squirrel to make it compatible with both the old HuC and the new HuC.
I'm having no trouble building the recent version of Catastrophy that you sent me, with the latest HuC build, and the modified Squirrel.
But if I change to the old sound.asm, then I get the same error that you're seeing.
Well, that's odd. Especially since that's the same bank name that PSG_BANK is given by the regular magic kit code.
Errrr ... we went through this one page ago in this thread, starting with this post from TheOldMan ...
http://www.pcenginefx.com/forums/index.php?topic=21350.msg480600#msg480600
... and we both agreed to change that PSG_BANK to SOUND_BANK ...
http://www.pcenginefx.com/forums/index.php?topic=21350.msg480851#msg480851
I sent you guys the changes for using Squirrel with both the old HuC and the new HuC a few months ago, which included the change to SOUND_BANK.
-
Oh right. I remember skimming/almost committing the SOUND_BANK rename to memory/getting sidetracked and forgetting about that bit.
I thought DK had already been utilizing the new Squirrel, hence more confusion.
but, I also thought he mentioned he was switching to using Huzak?
-
Oh right. I remember skimming/almost committing the SOUND_BANK rename to memory/getting sidetracked and forgetting about that bit.
Yep, it's so easy for stuff to just drop out of "current memory" when we switch between lots of different projects.
I'm back on the LoX translations at the moment, and it's taken me a while to remember where-on-earth I left off. #-o
I thought DK had already been utilizing the new Squirrel, hence more confusion.
Yep ... me too. I have no idea what's up with his local build setup. :-k
but, I also thought he mentioned he was switching to using Huzak?
I think that they're wanting to do that at some point ... but I'm still not ready to give Huzak out to people, it's just not stable-enough yet.
Michirin9801 has found a bunch of new "compatibility" problems for me to fix. :clap: ](*,)
-
I've mostly got PCE on the backburners while I finish MSX. I try to focus on one thing at a time so they get done sometime soon.
-
Hello, I'm trying to get my game up and running in this new version of HuC (previously used a fork of Uli's) but I'm having problems. I'm trying one commit at the time.
The following commit introduces this compile error:
commit: Fix arg_to_fptr() usage of magic numbers for argument types. 11/14/2016 08:16 John Brandwood
1> ;error: pce/pce.c(479)
1> ; case 0: map_data = pce_ep1_map00; pce_map_banks = bank( pce_ep1_map00); set_map_data( pce_ep1_map00 + 4, 32, 32); break;
1> ; ^
1> ;****** can't get farptr ******
Which is later fixed by this commit:
commit: Hack to fix Uli's fake-symbol kludge that was breaking arg_to_fptr(). That whole fake-symbol klud... 11/15/2016 09:43 John Brandwood
The game however is just completely broken when running in Mednafen. I guess I will have to try all commits in-between (which doesn't compile due to the farptr error above) to find which commit is actually breaking my game.
And finally this commit introduces an assemble error that is still present in the HEAD commit:
commit: Change System Card variables in "equ.inc" to use a "__" prefix. 11/16/2016 08:15 John Brandwood
1> #[1] game.s
1> 2073 16:A8FF stx __ax
1> Undefined symbol in operand field!
1> 2073 16:A902 sta __ax+1
1> Undefined symbol in operand field!
1> 2075 16:A909 stx __cl
1> Undefined symbol in operand field!
1> 2082 16:A91A stx __dl
1> Undefined symbol in operand field!
1> 2084 16:A921 stx __di
1> Undefined symbol in operand field!
1> 2084 16:A924 sta __di+1
1> Undefined symbol in operand field!
1> 2096 16:A934 stx __al
1> Undefined symbol in operand field!
1> 2097 16:A939 sty __bl
1> Undefined symbol in operand field!
1> 2097 16:A93E sty __si
1> Undefined symbol in operand field!
1> 2097 16:A943 sty __si+1
1> Undefined symbol in operand field!
1> 2099 16:A94A stx __cl
1> Undefined symbol in operand field!
1> 2103 16:A954 stx __al
Not sure what the last one is about. Any pointers?
-
Hello, I'm trying to get my game up and running in this new version of HuC (previously used a fork of Uli's) but I'm having problems. I'm trying one commit at the time.
...
The game however is just completely broken when running in Mednafen. I guess I will have to try all commits in-between (which doesn't compile due to the farptr error above) to find which commit is actually breaking my game.
Thanks for giving the new compiler a try!
To be honest ... I don't think that you're going to have much luck going commit-by-commit and looking for a problem.
farptrs were horribly broken in Uli's HuC because of his excellent "symbol + offset" optimization, which you're invoking there with your "set_map_data( pce_ep1_map00 + 4, 32, 32);" line.
My early attempts to understand the code and figure out what was wrong sometimes caused other problems.
As far as I know, things are fixed now, but if you've found another corner-case that I'm not correctly dealing with, then I'll need to see some kind of example so that I can track down the problem.
And finally this commit introduces an assemble error that is still present in the HEAD commit:
commit: Change System Card variables in "equ.inc" to use a "__" prefix. 11/16/2016 08:15 John Brandwood
1> #[1] game.s
1> 2073 16:A8FF stx __ax
1> Undefined symbol in operand field!
1> 2073 16:A902 sta __ax+1
1> Undefined symbol in operand field!
1> 2075 16:A909 stx __cl
1> Undefined symbol in operand field!
1> 2082 16:A91A stx __dl
1> Undefined symbol in operand field!
1> 2084 16:A921 stx __di
1> Undefined symbol in operand field!
1> 2084 16:A924 sta __di+1
1> Undefined symbol in operand field!
1> 2096 16:A934 stx __al
1> Undefined symbol in operand field!
1> 2097 16:A939 sty __bl
1> Undefined symbol in operand field!
1> 2097 16:A93E sty __si
1> Undefined symbol in operand field!
1> 2097 16:A943 sty __si+1
1> Undefined symbol in operand field!
1> 2099 16:A94A stx __cl
1> Undefined symbol in operand field!
1> 2103 16:A954 stx __al
Not sure what the last one is about. Any pointers?
Errrr ... yes.
Uli changed the names of the system variables from the old HuC's single underscore "_ax" to just "ax".
He did that so that the system variables don't conflict with variables that you create in HuC (which automatically have a single underscore added to them in C).
But in doing that, he just made them conflict with variable names that you declare assembly code, and made them inaccessible to C code.
What I did was to rename them all with a double_underscore, which follows standard C practice of using a leading underscore in C for system/compiler variables, so "_ax" in C code becomes "__ax" in PCEAS after the C compiler has added its extra underscore to it.
Then in any assembly code, you use the "__ax" name.
If you're getting compiler errors like that, then it sounds like you're not using the complete new HuC package, and you're missing the variable declarations in equ.inc
Are you writing in pure HuC, or are you including your own assembly-language source files?
Are you using in-line assembly in the HuC source?
Are you providing your own headers?
-
The game however is just completely broken when running in Mednafen.
Darn ... the bottom of my previous message got chopped-off ... what I wanted to add was ...
If you are willing to do what the Catastrophy guys did, and provide me with your HuC project (or a small-but-working subset of it), that compiles correctly on Uli's version of HuC, and fails on my version, then I'll track down what the problem is and fix it.
If it's something to do with the map data, that could be a side-effect of the change that I checked-in to stop HuC looking *before* the pointer for tile information. Perhaps the map does that, too.
TheOldRover mentioned something about a map data bug existing in Uli's HuC, but I've not seen any examples of it.
(If I can't see an example of a problem, I can't fix it.)
-
Gah, you are right! #-o
I only recompiled the exes and completely forgot to copy the include directory. Game compiles and works fine with the latest HuC when I copied that direcrory, except for sound obviously (I was using Ulis IRQ).
I don't mind sharing the project source if you need more regression tests. I should fix some stuff first though, like sound.
-
Gah, you are right! #-o
I only recompiled the exes and completely forgot to copy the include directory. Game compiles and works fine with the latest HuC when I copied that direcrory, except for sound obviously (I was using Ulis IRQ).
Excellent, I'm happy that you've got it working! :D
Sorry about breaking Uli's sound system, but I had to make a bunch of changes to get Squirrel working, and also allow for using Huzak (or any other sound player) in the future, without people having to change HuC or provide customized startup files.
From what I could see, Uli's SimpleTracker and sound stuff were works-in-progress, and not production-ready.
Are you using those, or doing something else for your sound? :-k
I'll send you a link to my Squirrel modifications so that you can see how stuff is supposed to be integrated now (it's just a few macros in one file).
I don't mind sharing the project source if you need more regression tests. I should fix some stuff first though, like sound.
I'd love to have more tests to make sure that I don't break things in the future. 8)
Anything that you send me will be kept private.
-
So, its inserting a random zero into the rom, in between incspr? That seems lame.
Also, a faster load_vram would be amazing. wink wink nudge nudge say no more.
OK, here you go, it's an early Christmas! :wink:
https://www.dropbox.com/s/b5c2mjhof9m98h7/huc-2016-12-20.zip?dl=0
This is the cumulative changelog for the current version ...
New in version 3.99:
--------------------
2016-12-20
- Imported Uli's v3.98 version of HuC (https://github.com/uli/huc)
See README for all the changes that Uli made
- Applied changes from Artemio Urbina's fork of HuC
- Applied changes from Markus Buretorp's fork of HuC
- Fixed compilation on Windows with mingw-w64
- Fixed a few bugs related to Uli's improvements
- Changed System Card parameter equates to have a "__" prefix
- Changed startup.asm to allow a sound driver to use macros to integrate
- Removed Uli's support for interrupt handlers in HuC (they're too slow)
- New str/mem package to replace the old code
Note 1 : Strings are 255 bytes maximum (+ trailing null)
Note 2 : When a ptr is returned, it points to the end of the str/mem
This breaks ANSI/ISO compatibility, but is more useful
Note 3 : strncpy handing of the 'length' is the same as strncat
This breaks ANSI/ISO compatibility, but reduces code size
- Bumping version number for all the current changes
- Stop HuC adding an extra ".dw" to usage of .incchr/.incspr/.incpal/etc
- Add extra parameter to set_tile_data() to set the tile type (8 or 16)
set_tile_data(char *tile, int nb_tile, char *ptable, char type);
- Rewrite load_vram to use 32-byte TIA instructions (3x speed improvement)
Pleafse note the change in the set_tile_data() function call!!! :-k
Everything is in github for those folks that want to make their own build.
Link is broken! Elmer?
-
Link is broken! Elmer?
That's an old version. See this post ...
http://www.pcenginefx.com/forums/index.php?topic=21350.msg487200#msg487200