Technical Specifications
General Criteria

The object of the competition is to create the most graphically impressive and unique demo program just using Vector Unit 1.  There are infinite things that can be done graphically, but squeezing it all into the VU memory and making it appealing to your peers who will judge it will be the trick.

Sponsor will supply the harness for entrant's Demo code to execute from.  Technical specifications are provided to comply with the harness.

Code, data, and a help file are stored as binary on disk.  The data and help files are loaded at the start of the demo and the code is executed every frame until the next demo is loaded.

As all the demos have to cooperate with the host program, no changes to the host program are permitted.

Submission Materials

All entrants submitting a Demo must provide 3 files and a string.  

Data File

A data file to be loaded into the vector unit at address 0.  This is not loaded by DMA but rather by a direct copy operation so no dma or vif information should be embedded in the data.
The data file can fill VU1 memory except for the last qword.  This qword is updated every frame by the host program and provides the address of the current and previous frame buffers.  It also provides a random number every frame and digital pad input from controller 1.

Code File

A code file to be loaded into the vector unit at address 0.

The code file can be made using VCL (encouraged), hand written vu microcode or any other means.  Object files made from VU assembly code using ee-dvp-as should be converted to a binary using ee-objcopy that can be loaded at run time.  An example showing how to do this under Linux is provided in the submission distribution.

The code file can fill the micro memory entirely.

Help File

A help file to be loaded into main ram and displayed whenever the user presses the Select button.  This should be a plain text file with up to 20 lines of text, each line being 75 characters or less.  If the demo is non-interactive, the first line of the help file should read "This demo is non-interactive".  If the demo is interactive, it should display help text in the following format:

Pad:  <control description>
X:  <control description>
Triangle: <control description>
Circle: <control description>
Square: <control description>
Start: <control description>
R1: <control description>
R2: <control description>
R3: <control description>
L3: <control description>
Left Stick: <control description>
Right Stick: <control description>

The remaining lines may be used for any useful information such as flavor text/description of technique used/etc.

Text String

The text string can be up to 50 characters in length and should contain the name of the demo as well as the name of the author.

When the demo is running it will display this string as well as the entry number it was assigned at the bottom of the screen.  This information will be used to distinguish between demos in the judging process.

Notes on the Host Program

The host program sets up a display environment in much the same manner as the SCEI sample code.  Four 640 x 224 buffers are allocated in VRAM for use by the host.  The first three buffers are for the frame buffer and z buffer.  The fourth 640 x 224 buffer is allocated for the help menu, which is created once at load time and rendered via the pcrtc merge circuit.  Since the fourth buffer is considered part of the host program, any changes or uploads to vram such as screen effects/texture uploads should be done outside of this memory area.

The host program should be relatively self-explanatory.  It parses an ini file which provides a list of all the demo entries.  These are then loaded into memory.

Notes on using the pad in Demos

Please note that the following pad buttons are reserved for the host program and should not be used in the application:  Select, L1, and L2.


DevStation 2003 VU Coding Contest

