Like all VCL code files, we have a --enter--endenter block, and a --exit--endexit block. These can do handy things for us when we integrate VU microcode into a larger program. However, I don't think there's anything clever they can do for us in this competition, so I'll leave them for now. Just use them to mark the start and end of your code.
Wich got me thinking.. I currently do things like this:
.vsm --(dvp-as)--> .o --(dvp-objcopy)--> .bin --(bin2c)--> .c --(ee-gcc)--> .o
and link that into my project.
I played around a bit and found that dvd-as's .o will happily link with ee-gcc into the final .elf since everything lives within the .vu section, so that's fine.
My problem is, how do I find this memory when running the elf? I assume it's some .PROVIDE in the linker script which I can then use as extern pointers, but am clueless on how to do that.
And it displays fine (just the simple triangle demo) but the loop only happens 2 (sometimes 3) times. After chucking printf's around everything, i found that the vu1wait() never returns.
this also happens with/without various combinations of the clear screen and vsyng functions...
cheriff wrote:...Also, it was your vulib that even got me this far in the first place, so thanks!
always nice to hear that people find it usefull :)
cheriff wrote:...but the loop only happens 2 (sometimes 3) times. After chucking printf's around everything, i found that the vu1wait() never returns.
Are you sure that it's not something else (for example the vu program)? I don't know that triangle demo you're talking about, but I have tested some vu1 mpg's and it seems to run fine. One of them was processing some particles and putting them as "points" on the screen. There was no problems with the vu1Wait() (only once with the vu0Wait but I fixed that some months ago).
All vu1Wait() does is doing a loop using the "BC2T" instruction (branches if COP2 conditional signal is TRUE, i.e. VU1 is activated).
here is one working demo with vu1Wait() : the elf, and the source.
It does draw a blue rectangle for me (the red is leftover from when this was a coloured triangle)
But both times around, it hangs after only 2 frames. (but in your code i cant even see the sprite)
cheriff wrote:...but in your code i cant even see the sprite
You mean you can't see anything when you start it? Hmm, did you try the already compiled elf? It runs fine on my PS2. It's a PAL, don't know if this could be a problem (?), it should detect and set everything to ntsc automaticaly. Ok, it's my own gs-lib and didn't test it on NTSC so... ;P
But back to your sample/problem:
Shouldn't you set the EOP flag in the GIF tag?
I guess the second xgkick might be stalled (so the VU1-MPG doesn't return), because the first transfer is not finished correctly (because of the EOP). EOP=0 means after the first GIF tag and data comes another GIF tag, but you're just sending one GIF tag + data. I'm not realy sure, but give it a try ;)
Sorry, I meant that your elf and compiled source runs perfect (very nice, btw!) but when i splice in my vu data/code it craps out, same as mine... Am gonna try EOF in the tag now... stay tuned!
EDIT (2 mins later): woo-hoo! that did it. How annoying that simply flipping one bit, and it look me 3 days to figure out :)
Well thanks for all your help, and sample code too! Now it's time to see if maybe I can't get something a little more prettier outta this thing..