Registered: Dec 2002
Location: Chicago, IL
Posts: 17

A few questions (please be kind ) :

What's the entry point for the PSY-Q devkit?
I've seen a BOOT.C/H for several demos (and the source to those demos don't seem to have a main), a source that came
with it used main, but that wouldn't compile. It seems that
everything except main will compile. So then what function
runs first (entry point) ?

The result of linking seems to give a ROM with no header.
As the linker seems to output what it calls a "pure binary output file", even without the command-line switch. How do I add a correct header for running on an emulator? I've used the command:

copy HEADER /B +a.n64 a.n64

To add the binary header file I found in a demo to the binary image, but it doesn't seem like it works (or my troubles with
the entry point is messing it up). So to sum up this question:

How do I add a correct header for running on an emulator?

One last one:
What's the algorithm for the calls I have to make to get
a blank (black) screen with basic gfx set up?

Many(x10) thanks,
- Mike

Report this post to a moderator | IP: Logged

Registered: Oct 2001
Location: NJ, USA
Posts: 81

I can't really help you on the C side, but here's some basic startup code in ASM:

code:

        org  $80000400 ; entry point (the (standard) header loads your
                                  ; code to $80000400)


        ; always do this first thing, otherwise the N64
        ; crashes in approx. 5 seconds
        li   t1,8
        lui    t0,$bfc0
        sw   t1,$07fc(t0)

        ; Initialize video (I won't go into what all the
        ; values mean, but it initializes the screen to
        ; 320x240 16 bit color mode)
        lui   t0,$a440 ; VI register base
        li   t1, $103002
        sw   t1,0(t0)
        la   t1,0xa0200000 ; the frame buffer address
        sw   t1,4(t0)
        li   t1,320
        sw   t1,8(t0)
        li   t1,$2
        sw   t1,12(t0)
        li   t1,$0
        sw   t1,16(t0)
        li   t1,$3e52239
        sw   t1,20(t0)
        li   t1,$0000020d
        sw   t1,24(t0)
        li   t1,$00000c15
        sw   t1,28(t0)
        li   t1,$0c150c15
        sw   t1,32(t0)
        li   t1,$006c02ec
        sw   t1,36(t0)
        li   t1,$002501ff
        sw   t1,40(t0)
        li   t1,$000e0204
        sw   t1,44(t0)
        li   t1,$200
        sw   t1,48(t0)
        li   t1,$400
        sw   t1,52(t0)

        ; clear the screen
        la   t0,0xa0200000
        li   t1,320*240*2-2
        li   t2,0 ; black
loopclear:
        sh   t2,0(t0)
        add  t0,2
        bnez t1,loopclear
        sub  t1,2

deadend
        j   deadend
        nop

__________________
-hcs

Last edited by hcs on 05-13-2003 at 06:04 AM

Report this post to a moderator | IP: Logged

Registered: Dec 2002
Location: Chicago, IL
Posts: 17

I had a few problems with that code :

The first assembler that I tried accepted the code with minimal
changes, but Nemu's debugger showed what seemed to be
the code in an infinite loop on 0x80000400, I'd suppose that's
why the VI registers didn't show up as anything either.

As it turned out, the other assembler I tried doesn't support LA and BNEZ, but it does add a header automatically (sort of). Here's
my conversion of last part of the code:

li t0,0xa0200000
li t1,153598
li t3,2
li t2,0x0
loopclear:
sw t1,0(t0)
add t0,t0,t3
nop
jal loopclear

(I just changed LAs to LIs which I'd hope works pretty much
the same with immediate values)
I just made it infinitely fill in memory instead of seeing if the
loop is done just for the heck of it. The assembly didn't like
the ADD either so I just expanded it.

With the code I have now (the above), the VI regs. get set
and I can see the infinite mem. fill in the debugger, but Nemu
gives no output, why is that?

(If anyone has the answer to the C question, please help)

Thanks for your help,
- Mike

P.S. One big configurable bitmap mode, who would have guessed? (Is that right?)

Edit: I probably should mention that the assembler that didn't
work for me is the one from PSY-Q, and the one that did is
Anarko's assembler.

Last edited by ASMGuy on 05-14-2003 at 12:12 AM

Report this post to a moderator | IP: Logged

Registered: Oct 2001
Location: NJ, USA
Posts: 81

Whoops, I neglected to point out that Nemu doesn't have working framebuffer support (just now), you have to get a plugin for it. This should do the trick. No game (that i know of) directly writes to the framebuffer, so most ignore it and only deal with the high level RSP/RDP stuff.

As for the PSY-Q assembler not working, I don't know why. I used to use it consistantly until I learned it doesn't run in DOS and wrote my own (one of the biggest mistakes I've ever made, now I'm chained to the thing). I remember getting fed up with anarko's because something or other wouldn't work to my liking, it was probably due to my own stupidity, though.

Yes, the framebuffer is a simple bitmap. The only real reason I have it in 256x240 mode is so that calculating the address of a row is easier. In the 16-bit mode I initialized it to in the code I posted it the upper 5 bits are red, next 5 bits are green, nest 5 bits are blue, and the last bit should be zero unless you want the graphics messed up. I still don't know exactly what that does.

By the way, why use jal in your endless loop? j would work just fine and wouldn't carry the connotation of jumping to a subroutine.

__________________
-hcs

Report this post to a moderator | IP: Logged

Registered: Dec 2002
Location: Chicago, IL
Posts: 17

Thanks for the plugin, now I can see the output

The PSY-Q assembler seems to end up writing code that
starts at 8000017C (or near there) and if I look at 80000400
I see:

? (COP 0)
J 0x80000400

As for the JAL for the loop, Anarko's assembler keeps giving me
the error: Cannot use JAL (or J) in delay slot. So I either switch
the instruction or add a NOP before the jump and for some reason
it works.

And lastly, where can I find info on how the RSP works? and
may I see those sources you mentioned?

I really appreciate your help ,
- Mike

Report this post to a moderator | IP: Logged

Registered: Oct 2001
Location: NJ, USA
Posts: 81

Here's the source I mentioned. Unfortuately it was written for my assembler, which has some quirky syntax and stuff. The ZIP contains every file you'll need to build the program, and the code itself is somewhat documented. I just updated it for the newest version of U64ASM, and I tested it out and it does indeed work on the N64. It looks like there's some glitchiness on Nemu, but it gets the point across. Direct questions at me!

As for RSP info, there really wasn't much available. I learned how to interface the RSP from Heavy 64 and disassembling some microcode. If you need any help with the registers...

__________________
-hcs

Last edited by hcs on 05-14-2003 at 11:55 PM

Report this post to a moderator | IP: Logged

Registered: Dec 2002
Location: Chicago, IL
Posts: 17

The source is great! You're a great commenter. I love the
assembler too.
It'll just take me a day or 2 until I digest all of the code.

So the RSP is like another processor that has it's own mem.
too and can execute code seperate from the main processor
like another "thread" and can DMA to the main mem? (That's how
it appeared to me from your code.)

You said:
No game (that i know of) directly writes to the framebuffer, so most ignore it and only deal with the high level RSP/RDP stuff.

What is the "high level RSP/RDP" stuff?

I don't think I can thank you enough for the code,help,and
assembler!,
- Mike

Edit: With your assembler, I get an Illegal Instruction error on
li t0, 0x0FFF ; and
li t1,$a0200000

Does your assembler support both $ and 0x ? and what spacing
is required for instructions vs. operands vs. labels?
It also tends to call an instruction such as the above a symbol
sometimes, what am I doing wrong that I should know about?

Last edited by ASMGuy on 05-16-2003 at 01:17 AM

Report this post to a moderator | IP: Logged

Registered: Oct 2001
Location: NJ, USA
Posts: 81

An artifact of my assembler is that instruction sizes must be fixed. This means that li cannot be used to load 32-bit values, I use the la instruction exclusively for that. Well, it can be used, I threw out the checker because it didn't always work. Perhaps I misunderstand, I'm not really sure what you're asking here.

Either 0x or $ are acceptable prefixes for hexadecimal.

I have the suspicion that you are not leaving whitespace before the instructions. If the first character of a line is not whitespace the first word on the line is assumed to be a label and the rest of the line is taken as the instruction. Thus if you tried to assemble
li t0,0x0FFF
li would be interpereted as a label, and the assembler would try to match t0,0x0FFF with a mnemonic. Of course it will fail.

By higher level RSP/RDP stuff, I mean using the official Nintendo microcode to interperet "display lists", which are sets of graphical instructions, the ucode does geometric transformations and sends the results to the RDP, which does the 3D rendering. Many emulators provide the microcode interface, recognize what style of display list is used, and then convert the display list into graphics by drawing whatever was meant to be drawn. This is one form of High Level Emulation, not directly pretending to be the hardware but making it look close enough to the software that it usually won't notice.

__________________
-hcs

Last edited by hcs on 05-19-2003 at 02:07 AM

Report this post to a moderator | IP: Logged

Registered: Dec 2002
Location: Chicago, IL
Posts: 17

Just a few last things:

I should have thought of tabbing in instructions, because the
NES assembler I use requires it also .

From some of the documents I've read, (RSP/RDPINFO.TXTs and
the N64OPS#H.TXT) , the RSP and RDP are on the same chip(?),
(Do they share the same memory?) , the docs infer that the RSP's
results in vector calculations are transformed into rather high-level
instructions and sent to the RDP for outputting to the screen.
That may be wrong, but if it is right and the RSP gives the RDP it's
commands, what is the purpose of the DP command registers
starting at 0xa4100000 (N64OPS#H.TXT) that I would assume
are only accessible without a DMA from the main code?

Lastly, what format does sound data take?

If I'm asking too many questions, feel free to tell me to go away
Thank you for what you've given me so far,
- Mike

Report this post to a moderator | IP: Logged

Registered: Oct 2001
Location: NJ, USA
Posts: 81

I don't know anything about the RDP, so I won't pretend to. If you figure it out let me know!

Sound is encoded as a series of values representing the displacement of the speaker membrane for a certain period of time, aka PCM (Pulse Coded Modulation). This is about the most basic form of sound data. The N64 can be configured for 4, 8, or 16 bits per sample (or so I seem to remember, I think anarko's doc goes into specifics). There is actually a pair of values for each period in time, one for the right channel and one for the left, but I don't remember which comes first. I'm pretty sure it is a signed representation but I'm not sure. As you might be able to tell, I've used the AI (Audio Interface) but only enough to get it to play some samples.

Looking back, what I've written doesn't look too helpful...

__________________
-hcs

Report this post to a moderator | IP: Logged

Registered: Dec 2002
Location: Chicago, IL
Posts: 17

This program seems to crash any emulator I try it on...
(The relavent parts):

la t0,$A4500014 ; Bit rate, whatever that means
li t1,3 ; what is a good value for here?
sw t1,0(t0)

la t0,$A4500000 ; Location of sample
la t1,Sample1
sw t1,0(t0)

la t0,$A4500004 ; length
li t1,$AAAAAA ; Don't care, just want it to play once.
sw t1,0(t0)

la t0,$A4500010 ; DAC Sample Rate
li t1,8000 ; What should this be?
sw t1,0(t0)

la t0,$A4500008 ; Control register
li t1,1 ; 1 == start sound ?
sw t1,0(t0)

; later on:

Sample1:
incbin Sample.PCM

Just wondering if you have any ideas to give it a better chance
of working? (It seems that I'm cursed on sound programming,
I can't get NES and GBA sample playing to work either )

PS: What does those 3 lines do that stop the N64 from crashing?
(Just wondering )

Report this post to a moderator | IP: Logged

Registered: Oct 2001
Location: NJ, USA
Posts: 81

The upper limit for sound buffer length is 262144 bytes, which your value is greater than, but that shouldn't crash anything. I assume you're not trying to execute the audio you're trying to play. The sound code I'm looking at has a Dac rate in the ballpark of yours. By the way, the DAC rate tells you how long the AI waits between getting samples (I don't remember the exact calculations involved, though). The bit rate in this situation is the size (in bits) of a sample, minus one, so if each sample was 4 bits you would write a 3. What is "good" depends entirely on what format the sound is in.

I don't see anything crash-worthy, though. Could you send me (or attach) the entire source and I'll take a look through it? Does just the program within the emulator crash or does the emulator itself crash? Have you been able to get, say, my Super Fighter demo to work in these emulators (as it uses the AI the same way you seem to be trying to)? I can give you my source code for that demo, but it was written back when I was using asmn64 so you'll have to do some porting if you're using U64ASM.

__________________
-hcs

Report this post to a moderator | IP: Logged

Registered: Dec 2002
Location: Chicago, IL
Posts: 17

Your Super Fighter demo causes a "DS Lock 6" error like mine does, but only freezes Nemu.

Neither Super Fighter nor my program work in UltraHLE 2064
(emulator crash), but I don't know how accurate that one is.

My code can be downloaded from:
http://k2pts.home.attbi.com/gbaguy/sampletest.zip

(It's probably too big to attach)

(This code is written for asmn6432, but there's nothing that is
(as far I as I know incompatable with your assembler.)
((I had some wierd JAL happenings with your assembler...) )

Edit: Don't laugh at it if the sample does work for you.

Last edited by ASMGuy on 05-20-2003 at 11:28 PM

Report this post to a moderator | IP: Logged

Registered: Dec 1998
Location:
Posts: 850

quote:

---

What's the entry point for the PSY-Q devkit?
I've seen a BOOT.C/H for several demos (and the source to those demos don't seem to have a main), a source that came
with it used main, but that wouldn't compile. It seems that
everything except main will compile. So then what function
runs first (entry point) ?

---

Report this post to a moderator | IP: Logged

Registered: Oct 2001
Location: NJ, USA
Posts: 81

That's odd, the Super Fighter demo used to run just fine in Nemu. And if you get the same error then I've no idea what the problem could be, but its definately a bug in the emulator. UltraHLE is, as its name suggests, a High Level Emulator, whereas you and I are working at about the lowest level possible. I've never tried running any of my programs in UltraHLE or any of its successors.

I couldn't get your link to work...

Could you possibly give an example of problems with U64ASM? I know it has a few bugs and a demonstration might help me find them.

I looked at your N64 ASM tutorial, and it seems that you're not familiar with the concept of a 'delay slot'. This is the instruction immediately after a jump or branch instruction. It is executed during the jump (actually, while the instruction at the target is being fetched). For example, if we have

code:

    jal dest
    addi t0,t0,1

code:

    li   t0,7
loop:
    ; something to be done 8 times
    bnez t0, loop
    addi t0,-1

__________________
-hcs

Last edited by hcs on 05-21-2003 at 05:43 PM

Report this post to a moderator | IP: Logged