VU Harness, Creating Eratosthenes Demo

modman · Post by **modman** » Wed Mar 09, 2005 3:56 am

Hi all,

I have attempted to create the first demo on Eratosthenes site:

http://paulsmith.is-a-geek.net/vututs/

Mirror:

http://www.pcs.uklinux.net/id19.htm

Here is the code that I have put together:

http://staff.philau.edu/barberej/stuff/ ... emo.tar.gz Link not valid anymore... see later posts

I'm thinking the code I wrote to create the VU data is not working correctly.

I copied and pasted the VU VCL code straight into vi from Eratosthenes website, so I doubt there is a problem there.

I used the OpenVCL compiler from:

http://ps2dev.org/kb.x?T=1110

All source/documentation/makefiles are included in the tarball on my homepage. If anyone has any suggestions, I'd appreciate them.

Thanks!

mharris · Post by **mharris** » Wed Mar 09, 2005 4:41 am

The only C code in the tarball is ggp.c -- in it, you're dumping the GIF packet to a file, but never sending it to VU1. The vu code looks OK, assuming you send the GIF data to VU1 address 0. I didn't disassemble your GIF packet to see it's correct or not.

modman · Post by **modman** » Thu Mar 10, 2005 1:17 am

Hi mharris,

Thanks for the reply!

I'm using adresd's VU harness so I havn't thought about creating any c code to load the data into the VU....

i just run:

Code: Select all

ps2client -h &#91;ip&#93; execee host&#58;VUharness.elf

I put my demo.bin, demo.dat, and demo.hlp in /bin/bin/demodata

I also changed the demodata.ini so that it would load the demo. I've done this before so I know it works ok from this end.

If anyone has any code to simply pass the code/data to the VU without the use of the harness I would appreciate it.

I could just check out the source of the VUharness... but I'm not sure if its out there, the only code I've seen is for the PS2Linux version.

Anyone out there want to check my data file ?? :-) I don't have the ability to generate one using Eratosthenes generator because I don't have the PS2Linux kit :-(

Saotome · Post by **Saotome** » Thu Mar 10, 2005 2:25 am

modman wrote:If anyone has any code to simply pass the code/data to the VU without the use of the harness I would appreciate it.

I think I might have what you're looking for :)
I've just written it a week ago: vu-lib.
It has some functions to transfer code or data via DMA to VU0 or VU1 and start a microprogram.
Already tested it with some simple MPGs - seems to work fine. But feel free to report any bugs ;)

carlosn · Post by **carlosn** » Thu Mar 10, 2005 2:43 am

Hello modman,

I checked your demo.dat file and realized is wrong.

Here is a hexdump of your file:
# hexdump demo.dat
0000000 0000 0000 0051 0000 eaaa 2005 8003 aaaa
0000010 0000 0000 0000 0000 0000 0000 00ff 0000
0000020 0000 0000 0001 0000 7ce0 0000 79c0 0000
0000030 0000 0000 0000 0000 00ff 0000 0000 0000
0000040 0000 0000 0001 0000 7ce0 0000 8640 0000
0000050 0000 0000 00ff 0000 0000 0000 0000 0000
0000060 0000 0000 0001 0000 8320 0000 8640 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
*
0004000

Here is a hexdump of data file that works:
# hexdump basic.dat
0000000 8003 0000 c000 2005 0051 0000 0000 0000
0000010 00ff 0000 0000 0000 0000 0000 0000 0000
0000020 79c0 0000 7ce0 0000 0001 0000 0001 0000
0000030 0000 0000 00ff 0000 0000 0000 0000 0000
0000040 8640 0000 7ce0 0000 0001 0000 0001 0000
0000050 0000 0000 0000 0000 00ff 0000 0000 0000
0000060 8640 0000 8320 0000 0001 0000 0001 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
*
0004000

In your program ggp.c the qwords in your gspacket are backwards.
GIFtag_a32 -> GIFtag_d32
GIFtag_b32 -> GIFtag_c32
GIFtag_c32 -> GIFtag_b32
GIFtag_d32 -> GIFtag_a32

Swap the words for the rest of qwords in your gspacket and you will get it right.

modman · Post by **modman** » Thu Mar 10, 2005 3:20 am

carlosn:

thank you!

i remember reading that you have to watch your order on MIPS architecture, i guess i should have taken that section of the tutorial a little more seriously. when i get home from work today i will give it a shot...

Saotome:

looks like a nice set of basic calls for the VUs... i will give them a try with the Eratosthenes demo as well, thanks.

Shazz · Post by **Shazz** » Thu Mar 10, 2005 4:08 am

Ep Modman,

While I started to learn how to code the VUs, qs you did, I took a look at Erathostene's tutorials (and Dr HS Fortuna, great too).

But when I went to code, I started using the PbDemoLib examples (ps2dev CVS), using the lessons from the tuts and the PbDemolib framework I was able to quickly test my first VU apps ! Send matrices, kicking the GS, receive coords...

So if it can help....

By the way, I'm curious to look at Saotome's VU lib :D

modman · Post by **modman** » Thu Mar 10, 2005 5:03 am

Shazz

Thanks for the pointers.

Tonight should be fun to see how this whole vector unit thing works.

See you on IRC!

modman · Post by **modman** » Thu Mar 10, 2005 9:28 am

Well it didn't seem to work :-(

At first I just tried reversing the Qwords as carlosn suggested:

In your program ggp.c the qwords in your gspacket are backwards.
GIFtag_a32 -> GIFtag_d32
GIFtag_b32 -> GIFtag_c32
GIFtag_c32 -> GIFtag_b32
GIFtag_d32 -> GIFtag_a32

Swap the words for the rest of qwords in your gspacket and you will get it right.

This did not work so I looked over the demo.dat file and realized that the data I was entering in the ggp program was incorrect.

carlosn is basic.dat correct on your end?...

This is from Eratosthenes site:

00000000000000512005EAAAAAAA8003

That's a GIFtag that still says (at least as far as the PS2 is concerned) I'm going to send 3 set of RGBAQ and XYZ2 vertex information, and I expect a triangle to be drawn.

Then follows the colour and co-ordinates of the first vertex - remember the colour is specified in ABGR format, and the co-ordinates in ZYX format (see P153 of the EE User's Manual for more info on packed data)

000000000000000000000000000000FF
000000000000000100007CE0000079C0

0000000000000000000000FF00000000
000000000000000100007CE000008640

00000000000000FF0000000000000000
00000000000000010000832000008640

Put that all together, and you've got your GIFpacket, which could be typed into a hex editor without a C program in sight. Of course, I don't recommend you actually do this, I'm just trying to prove a point :)

After a couple quick changes in the ggp.c file I tried again. Still the same result in vuharness.elf... I see my demo.hlp displayed but I don't see the triangle and I loose control over the harness.

This is the updated code:

http://staff.philau.edu/barberej/stuff/ ... emo.tar.gz Link not valid anymore... see later posts

Now I'm left with either bad data or I am missing some configuration with vuharness. :-(

carlosn · Post by **carlosn** » Thu Mar 10, 2005 3:06 pm

The data file I provided is correct. I tested it under ps2linux and it works fine.
When I first looked at your vcl code, I realized it was correct, so I did not pay attention to your bin file. After reading your help file, I realized that the bin file is not properly built.
This is how you build the bin file:

dvp-as demo.vsm -o demo.o
dvp-objcopy -O binary demo.o demo.bin

Here is a hexdump of the correct demo.bin

0000000 0000 1001 02ff 0000 0efc 8000 02ff 0000
0000010 033c 8000 02ff 4000 033c 8000 02ff 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0000100

Now I tested this under VUharness in native PS2 and it works as well. Make sure you correct your help file.

Let me know how it works out...

mharris · Post by **mharris** » Fri Mar 11, 2005 8:55 am

carlosn wrote:Here is a hexdump of the correct demo.bin

0000000 0000 1001 02ff 0000 0efc 8000 02ff 0000
0000010 033c 8000 02ff 4000 033c 8000 02ff 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0000100

That's a little-endian hex dump, BTW ;-)
hexdump -C gives you a byte-by-byte dump.

carlosn is right, if you're going to send the compiled VU code directly to the VU, you will need to use objcopy or something similar to strip the ELF stuff out of the file. The .o output from dvp-as is a standard ELF object file, suitable for linking into an executable, but you can't send it directly to the VU in that format.

modman · Post by **modman** » Fri Mar 11, 2005 9:00 am

Hurray!!

Thanks carlosn! Everything worked this time... just required your magical compilation steps ;-)

Final source for those who want to follow along with the tutorial.

This is just Example 1... more to follow.

http://staff.philau.edu/barberej/stuff/ ... ex1.tar.gz Link not valid anymore... see later posts
Thanks again for all those who helped.

modman · Post by **modman** » Sat Mar 12, 2005 12:52 am

mharris:

Thanks for going over why I needed to use dvp-objcopy. It makes a lot more sense to me now.

Also thanks for the tip about hexdump... I just assumed a hexdump was a hexdump. :-)

Sorry for not posting this sooner... for some reason I didn't see your post last night, prob since it was within 5 minutes of mine, and the server did not receive it till later.

Here's the next example if someone wants to try it out:
http://staff.philau.edu/barberej/stuff/ ... 1_2.tar.gz Link not valid anymore... see later posts

Happy coding!

mharris · Post by **mharris** » Sat Mar 12, 2005 1:07 am

modman wrote:Also thanks for the tip about hexdump... I just assumed a hexdump was a hexdump. :-)

A common misconception ;-)
hexdump w/ no options dumps it in 16-bit words, but how it determines the byte order is platform-dependent. Same way if you do something like:

Code: Select all

hexdump -e '"%08_ax&#58; " 4/4 "%08x " "\n"' foo.o

This will dump 32-bit words, but again, the byte order is platform dependent. The only platform-independent way to see it is by doing a byte-by-byte dump, then reversing the bytes yourself (since the EE is little endian). Especially when you're dealing with the big 128-bit words used by the GIF, it can be confusing. Unfortunately, hexdump doesn't support word sizes larger than 32 bits, and there's no way to override the endianness.

Since there's a parallel thread going on somewhere here about little-endian vs. big endian development platforms, it seemed appropriate to point that out... especially since I just switched my own dev environment from Linux/x86 (little endian) to Darwin/PPC (big endian).

modman · Post by **modman** » Sat Mar 12, 2005 1:16 am

since the EE is little endian

I thought MIPS was usually big-endian? I have heard that it can be little endian too though... is the EE a "special" MIPS processor?

mharris · Post by **mharris** » Sat Mar 12, 2005 1:36 am

From http://www.linux-mips.org/wiki/index.php/Endianess:

One of the special features of the MIPS architecture is that all processors except the R8000 can be configured to run either in big or in little endian mode.

But the R5900 core in Emotion Engine seems to be an exception to a lot of rules... I don't know if it can run in big-endian mode (nor how to tell it to do so). All EE code that I've seen (and IOP code as well) has been little-endian.

modman · Post by **modman** » Sat Mar 12, 2005 2:41 am

mharris: thanks for the clarification...

i just noticed eratosthenes had mentioned this too :-\

We have to write down numbers the opposite way to how we usually think about them. We usually write the most significant digit first, in this case starting with 127 and counting down, but we usually think of the bits of data as bit 0 being the first bit. Thankfully the PS2 is little endian, so all we have to do is remember to write our bits down backwards and we're OK, no matter if we're writing to a 64 or 128 bit register. If you don't understand endian-ness, don't ask!

seems as if i need to read a little more carefully next time.

thanks again, i think i will be able to write my own demo at some point in the near future thanks to all the responses here in the forums.

long live vector units and micro coding!

Post by **pixel** » Sat Mar 12, 2005 11:31 pm

The EE and the IOP run by default in Little Endian. The COP0 should have a function that reverses the endianess, but I've never tried it, and I think it would lock up basically immediately, since it would require rewriting the kernel for big endian...

Saotome · Post by **Saotome** » Sun Mar 13, 2005 1:33 am

Just wanted to say that i found a bug in my vu-lib (mentioned above in this thread). hope no one tried it and was wondering why it doesnt work when transfering MPGs (micro-programs) bigger than 2040 bytes and data chunks bigger than 4080 bytes ;)
Allready idenified the bug. You can transfer a max of 256 qwords with VIF-UNPACK-code and 256 dwords with the MPG-code. so i'll have to split up bigger chunks in a DMA chain. will fix that tomorrow.

EDIT: fixed :)

modman · Post by **modman** » Mon Mar 14, 2005 4:02 pm

hi all,

ok... new link at my site... should make it easier to find stuff now.

http://staff.philau.edu/barberej/ps2dev/

i should be compiling the demo harness from cvs in the next day or two, the vuharness.elf that i recieved on IRC seems to be giving me display problems... i'm hoping the cvs version will fix that...

anyone else get a 1 inch offset from the top? another words my top left pixel starts an inch below the tv screen... someone said the harness might be running in PAL mode... but i'm not sure how to do this as i only have the binary.

a

Code: Select all

hexdump -c vuharness.elf

tells me that adresd wrote it... but not much in the way of usage/options

Code: Select all

hexdump -c vuharness.elf | grep 'U   s   a'

returns nothing... so i'm left to compile from cvs... probably what i should have done from the beginning :-)

urchin · Post by **urchin** » Mon Jun 13, 2005 7:30 am

I've been having problems getting this to work on my mac too (I'm guessing endian issues are maybe to blame)

I got the vuharness demos to display and then tried to compile the "basic" sample which I believe is supposed to just display a red/green/blue triangle. I just get the black screen with the "help" text.

Here is my basic.bin:
00000000 00 00 01 10 ff 02 00 00 fc 0e 00 80 ff 02 00 00
00000010 3c 03 00 80 ff 02 00 40 3c 03 00 80 ff 02 00 00
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00000100

and my basic.dat:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 05 80 03
00000010 00 00 00 51 00 00 00 ff 00 00 79 c0 00 00 00 00
00000020 00 00 86 40 00 00 00 00 00 00 86 40 00 00 00 00
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00001000

any help much appreciated!...

urchin · Post by **urchin** » Mon Jun 13, 2005 7:39 am

My basic.dat is knackered isn't it? It looks nothing like the eratosthene's example. I wonder if I've somehow borked gen_data.c (it wouldn't build properly on os x, but I thought I'd got it working)

urchin · Post by **urchin** » Mon Jun 13, 2005 11:42 pm

modman> I couldn't get the link to your site to work... this one does though:

http://staff.philau.edu/barberej/ps2dev.htm

Looks like your port might help me out. I'll give it a try tonight.

urchin · Post by **urchin** » Tue Jun 14, 2005 7:25 am

Yay! I unbigendianised (technical term) the data file and it works!

Many thanks to modman for providing ex1.dat on his website, so I could compare hexdumps and fix my code.

ph33r my multicoloured triangle!...

Saotome · Post by **Saotome** » Tue Jun 14, 2005 7:38 am

*ph33rs people having 4-post-monologues* ;)

modman · Post by **modman** » Tue Jun 14, 2005 11:14 pm

Glad I could help urchin!

Now if I could only get motivated to do some VU coding instead of waiting for a PSP 1.5 Homebrew loader. :-\