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

The link should work now (I thought there was something
strange about IE when I uploaded it...).

I noticed that sometimes the same problem happens with
asmn6432, so I should probably either start using the NOP in
Delay Slot switch or be more careful
(without that, I would have never figured out the delay slot,
thanks)
I've attached the code anyway, it may or may not be different
since then.

Also in U64ASM, it doesn't seem to like Notepad's tabs (often,
but not always maybe?), I have to replace them with spaces.

To CrowTRobo:
Could you explain the linker? It has to be the wierdest
linker I've ever seen!! (PSYLINK)

Attachment: pictest.zip
This has been downloaded 8 time(s).

Report this post to a moderator | IP: Logged

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

I'd like to suggest using The Tool for your BMP to N64 conversions, specifically you should use the binary output option. Or maybe BMP2N64 has that option, too, I've never used it. That 1 meg mk.s file is excessive. Instead you should just generate a binary file and use incbin (or whatever asmn64 has). That'll speed things up and save you space.

A really efficient way to display an image would be to simply point the frame buffer at where you have the image, no copying needed.

U64ASM was developed exclusively with edit.com, which uses spaces instead of tabs, so tabs might give it some trouble. Indeed, it appears that some lines with tabs get dropped entirely...

Might I also suggest using FTP to manage your website, as IE seems to be mismanaging a lot of your uploads.

__________________
-hcs

Report this post to a moderator | IP: Logged

Registered: Dec 1998
Location:
Posts: 850

quote:

---

Could you explain the linker? It has to be the wierdest
linker I've ever seen!! (PSYLINK)

---

I would suggest downloading Locke's Ultra Demo sources. This was the first N64 source code released and almost everything was based on it. It contains a well commented link file that explains what it's doing. Then you can just modify it to suit your program. All you most likely will have to change is the section where the obj modules are included.

Basically everything you need to know to get started programming the N64 in C is included in his source.

quote:

---

U64ASM was developed exclusively with edit.com

---

Like everything should. You got great taste in text editors. And I was starting to think I was the only one left who still consistently uses edit.com. Even just to view a text file in XP, I prefer starting a dos box and using edit then opening notepad.

CrowTRobo

Report this post to a moderator | IP: Logged

Registered: Sep 1999
Location: London, England
Posts: 329

quote:

---

Like everything should. You got great taste in text editors. And I was starting to think I was the only one left who still consistently uses edit.com. Even just to view a text file in XP, I prefer starting a dos box and using edit then opening notepad.

---

edit.com? Ewww. Nothing beats Vi and its variations when it comes to editors

Sorry to go off topic, please continue...

__________________
Look, it isn't even dented. Oh shit! What are we gonna do now?

Report this post to a moderator | IP: Logged

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

To DMA code for the RSP to execute, what actually causes the
transfer to happen?

Is it the "GO" bit in SP_IBIST_REG, that I see in N64OPS ?

Report this post to a moderator | IP: Logged

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

quote:

---

Originally posted by wicket64
edit.com? Ewww. Nothing beats Vi and its variations when it comes to editors

---

__________________
-hcs

Report this post to a moderator | IP: Logged

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

quote:

---

Originally posted by ASMGuy
To DMA code for the RSP to execute, what actually causes the
transfer to happen?

Is it the "GO" bit in SP_IBIST_REG, that I see in N64OPS ?

---

__________________
-hcs

Last edited by hcs on 05-25-2003 at 04:46 PM

Report this post to a moderator | IP: Logged

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

As it turns out, I was writing to the wrong length register.
So once I fixed that, the code actually shows up in Nemu's
debugger (the RSP part ).

Now that the code is there, what makes the RSP run the code and
should I write something to SP_PC_REG (maybe 0x0? I seem to
remember something about RSP code running from IMEM...) ?

This is getting more and more interesting every time I run the
assembler!

Last edited by ASMGuy on 05-25-2003 at 05:22 PM

Report this post to a moderator | IP: Logged

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

Write 0 to the RSP PC reg. You could write 0x1000, but it wouldn't be any different as the reg is only 12 bits. It does indeed specify the PC within the RSP IMEM. You probably read this, but you can ONLY run code from IMEM and ONLY access data in DMEM (at least directly from the RSP).
Then you have to clear two RSP status flags to start the processor. I don't remember what the exact value was... but it un-breaks and un-halts the processor.
Ok, I checked, and this is what I have:
li t0,%100101101
_tpa(sw,t0,0xa4040010)
Each one of those bits clears or sets a flag, I'm really not sure what does what. It should be sufficient for your needs, and anarko's doc describes all the flags anyway, I think.

And by the way, what does your SP code do?

__________________
-hcs

Last edited by hcs on 05-25-2003 at 06:35 PM

Report this post to a moderator | IP: Logged

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

The RSP code doesn't do anything that'll work yet.
I just wanted to get code onto the RSP and have it run it and
then write something that actually does something like puts
a picture on the screen.

Looking at the docs, doing the first 8 or 9 clears or so gives
a number identical to yours and it worked, so I suppose now
I'll have to DMA the picture to DMEM, and then DMA it from the
rsp code to the framebuffer. wow that's alot of DMA...

I took a look earlier today at the playstation, figured out how to
initialize graphics, but I'm still using someone elses code to
send Gfx command packets to the GPU. It's amazing how similar
it is to the N64, nearly same processor, GPU uses neat microcode
(but wierdly only 2D as far as I can tell). It was fun to play with,
but I still like the N64 better .

Report this post to a moderator | IP: Logged

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

when I try to DMA the picture to DMEM, I think for some reason
it's messing up the code in IMEM, I'd bet I'm fairly silly for thinking
that a whole picture will fit in DMEM. (I think DMEM's real purpose
is to store vertex data that'll be pointed to by microcode in the
RDP... ?)

I know that I probably should make sure that the DMA is done
before doing the next thing, but as you said before, the emulator
shouldn't mind .

Anyway, my code (a little messy):

org $80000400

jal OSCrashProtect
nop
jal VIInitialize
nop
jal CopyRCPCode
nop

always:
nop
j always

CopyRCPCode:
la t0,0xA4040000 ; SP_MEM_ADDR_REG
li t1,0x1000
sw t1,0(t0) ; SP memory address

la t0,0xA4040004 ; SP_DRAM_ADDR_REG
la t1,RCPCode
sw t1,0(t0)

la t0,0xA4040008 ; SP_RD_LEN_REG
li t1,160
sw t1,0(t0)

nop
nop ; time for the emulator,

; DMA the picture to DMEM

la t0,0xA4040000
li t1,0x0 ; DMEM this time
sw t1,0(t0)

la t1,MKImage
sw t1,4(t0)

li t1,320*240*2-2/2
sw t1,8(t0)

nop
nop

la t0,0xA4080000
la t1,0x00000000
sw t1,0(t0)

la t0,0xA4040010
li t1,%100101101 ; make the code run
sw t1,0(t0)

jr ra
nop

include MK.s

include OS.h
include VI.h

RCPCode:
obj 0x0

nop
la t0,0xA4040000
li t1,0x0
sw t1,0(t0)

li t1,0xA0200000
sw t1,4(t0)

la t0,0xA404000c
li t1,320*240*2-2
sw t1,0(t0)

infin:
nop
j infin
ENDRCPCode:
nop
objend

Report this post to a moderator | IP: Logged

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

First, do me a favor. STOP PUTTING NOPs INSIDE OF INFINITE LOOPS!

code:

always:
    nop
    j always

code:

always:
    j always
    nop

code:

; Parameters:
; s0: 0 to transfer from RAM->RSP
;       1 to transfer from RSP->RAM
; s1: length (as specified before)
; s2: rsp location
; s3: ram location

RSPinternalDMA:
                mfc0    s8,WIRED    ; wait
                nop
                bnez    s8,RSPinternalDMA
                nop
                mtc0    s2, INDEX
                mtc0    s3, RANDOM
                bnez    s0, not_entryl0
                nop
                mtc0    s1, ENTRYLO0
                jr      ra
                nop
not_entryl0
                mtc0    s1, ENTRYLO1
                jr      ra
                nop

__________________
-hcs

Last edited by hcs on 05-26-2003 at 04:50 PM

Report this post to a moderator | IP: Logged

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

Ok, I'll do the infinite loops your way .

I figured that the picture would be too big, but even if I was
doing something that wasn't too big (like a small letter), it
still wasn't going to work. Which (after looking at your demo
and the excerpt in your post) is:

Where are RANDOM/WIRED/ENTRYLOC0/ENTRYLOC1 defined?
and
Are the SP registers mapped to the RSP's Sx registers? I couldn't
find any other solution during my (admittedly quick) look through
your demo. If they are, it doesn't appear to be in order..

I made day 8 about getting code onto the RSP and only that.
It's fairly accurate and I only went as far as I could without being
too inaccurate with it.

Report this post to a moderator | IP: Logged

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

Those register names are actually from the normal R4000 COP0, they have no meaning whatsoever on the RSP.
You see, every R4000 processor is made up of one primary processor (which does the integer operations that you're mostly familiar with) and then several others, called coprocessors. COP0 is the system control processor, and I believe COP1 is the floating point processor, and there isn't a COP2 on the standard R4000 (though there is space in the instruction set for it, for "future expansion"). These are, by the way, only logical coprocessors, they are not seperate chips. The reason to have the additional processor is to have different classes of instructions (it affects the instruction encoding). Additionally, each coprocessor has its own set of registers. Most assemblers call the main registers r0-r31 (but its also not uncommon for t0-t8, a0-a3, and so on to be scattered in there), but the COP0 registers, because they are associated with specific aspects of system control, have names (like STATUS, RANDOM, WIRED). A lot of this has to do with TLB (Translation Lookaside Buffer) and exception handling. anarko defines the names of the COP0 registers in his N64OPS document, which is one of the primary uses I've had for it.

On the RSP this is switched around a bit. COP0 is a clone of the SP interface (the set of registers you access form the CPU, 0xa404...). Since COP0 registers are conventionally called RANDOM, WIRED, etc., we're stuck with those names. There is a direct correspondance between the COP0 registers and the SP registers, so yes they're in order. COP1 doesn't exist on the RSP and COP2 is the vector processor.

In case that was all a little obtuse:

RSP COP0 register to CPU RAM mapped equivalent

0x00 = Index = SP_MEM_ADDR_REG = 0x0404 0000
0x01 = Random = SP_DRAM_ADDR_REG = 0x0404 0004
0x02 = EntryLo0 = SP_RD_LEN_REG = 0x0404 0008
0x03 = EntryLo1 = SP_WR_LEN_REG = 0x0404 000C
0x04 = Context = SP_STATUS_REG = 0x0404 0010
0x05 = PageMask = SP_DMA_FULL_REG = 0x0404 0014
0x06 = Wired = SP_DMA_BUSY_REG = 0x0404 0018
0x07 = cop07 = SP_SEMAPHORE_REG = 0x0404 001C

__________________
-hcs

Last edited by hcs on 05-26-2003 at 04:48 PM

Report this post to a moderator | IP: Logged

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

That'll definitely teach me to read N64OPS more closely next
time! (I thought I had looked through every file and then I look
again, and it's in N64OPS#B.txt. )

MTC0 and MFC0 give illegal addressing mode errors in asmn64,
but work in your assembler. Any idea what the syntax is for
asmn64?

Report this post to a moderator | IP: Logged