Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #301  
Old 12th June 2013, 07:00 PM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

Ah, that explains the message I would get when booting OoT. I was wondering if it was really making use of JPEG decompression during boot.

On another note, I really expected Rogue Squadron to give me a OStype.task message as well, but it does not. The menu screen only seems to work in some manner in Jabo's plugin, though.
Reply With Quote
  #302  
Old 12th June 2013, 08:00 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Oh cool. I didn't know it was used in OOT after the boot phase for mid-game decompression. I just thought the 00000004 task at OOT boot-up was like a peripheral thing, like store into SR $at and check an external value to see if some 64DD extension was installed or something. I thought it was just some hidden beta thing (and maybe it still is), but there really are (other) JPEG tasks used later on.

Like I said just haven't played with the HLE version of my plugin thoroughly enough to find that.

Quote:
Originally Posted by bsmiles32 View Post
*The only exception I know of is a small rsp task found during booting of OoT, which stores ve12 into dmem[0x10-0x1f].
And regarding that task, I did the deskwork for that SP task here.
http://dl.dropboxusercontent.com/u/1...64_startup.txt

The DMA stuff there I wrote might be wrong though.
That was back before I finished understanding SP DMA when I used to learn about the RSP by rewriting the z64 RSP plugin.

[Edit]
Now I get what you meant.
You were talking about this instruction as I wrote it out in my deskwork:
Code:
080 E80C2001 SQV     $v12, 16($0)
Stores the 128-bit quadword from general-purpose VR 12 to DMEM+0x010 .

Looking back at it now, I think this task is a lot less special than I make it sound.
It probably was just for initializing the JPEG decoder head of some field.

Quote:
Originally Posted by GPDP View Post
On another note, I really expected Rogue Squadron to give me a OStype.task message as well, but it does not. The menu screen only seems to work in some manner in Jabo's plugin, though.
Rogue Squadron is easy to emulate on the RSP.
It uses just basic task types and runs faster than many other games in LLE gfx.

It wouldn't work in HLE if you don't have proper HLE support for the custom graphics microcode tho.

Last edited by HatCat; 12th June 2013 at 08:08 PM.
Reply With Quote
  #303  
Old 12th June 2013, 08:12 PM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

Quote:
Originally Posted by FatCat View Post
Rogue Squadron is easy to emulate on the RSP.
It uses just basic task types and runs faster than many other games in LLE gfx.

It wouldn't work in HLE if you don't have proper HLE support for the custom graphics microcode tho.
I've tried it with Jabo's, z64gl, and SoftGraphic. The menu screen only works in Jabo's (although shifted downwards), but the in-game graphics are pretty screwy, whereas the graphics are great with z64gl, and good in SoftGraphic, although the latter does not seem to support the game's hi-res mode even when it's toggled. Strange, as Perfect Dark's hi-res mode does work, although the latter only seems to increase horizontal resolution, whereas RS increases both vertical and horizontal.
Reply With Quote
  #304  
Old 12th June 2013, 08:19 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Different games are harder than others to emulate on the RDP, but there really is nothing that complex relatively about Rogue Squadron on the RSP.
I have worked through many bugs or reversions of the RSP where many other games would have bugs and not Rogue Squadron.
Reply With Quote
  #305  
Old 12th June 2013, 08:42 PM
bsmiles32 bsmiles32 is offline
Junior Member
 
Join Date: Jun 2013
Posts: 10
Default

Quote:
Stores the 128-bit quadword from general-purpose VR 12 to DMEM+0x010 .
^ This. In all honesty I don't know the real purpose of this ucode, by I guess it is security related.
Reply With Quote
  #306  
Old 16th June 2013, 12:01 PM
angrylion angrylion is offline
Member
 
Join Date: Oct 2008
Location: Moscow, Russia
Posts: 36
Default

Funnelcube demo by marshallh spams with message boxes sayng something about MTC0.
Reply With Quote
  #307  
Old 16th June 2013, 11:23 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by angrylion View Post
Funnelcube demo by marshallh spams with message boxes sayng something about MTC0.
Just had a look into this finally.

You had me worried there for a second.
At first I thought you might have meant MTC0 system control CPU loop updates on the status register (specifically the special bits like HALT).

The exact message I'm getting with funnelcube is "MTC0\nCMD_START".

You can find that print code at `$rsp/su/cop0/mtc0.h` at line 126:
Code:
        case 0x8:
            if (*RSP.DPC_BUFBUSY_REG) /* lock hazards not implemented */
                message("MTC0\nCMD_START", 3);
            *RSP.DPC_START_REG = SR[rt];
            *RSP.DPC_CURRENT_REG = SR[rt];
            *RSP.DPC_END_REG = SR[rt]; /* NEW, not in PJ64/MAME */
            if (SR[rt] & 07) /* All DMA transfers must be 64-bit-aligned. */
            {
                message("MTC0\nCMD_START", 1);
                *RSP.DPC_START_REG &= 0xFFFFFFF8;
                *RSP.DPC_CURRENT_REG &= 0xFFFFFFF8;
                *RSP.DPC_END_REG &= 0xFFFFFFF8;
            }
            return;
Simply remove the error message printer line of code I highlighted in red, and you should be all set.

the message("$any string", 1); means it is not really an error, just an extremely unusual thing to execute on the RSP.
message(x, 0) means it's debug only,
message(x, 1) means it's very unusual/unseen but most likely correct
message(x, 2) means I was not able to test it, but I *think* it's correct
message(x, 3) means I have no idea what to do (things like reserved opcodes).

The second parameter of my `message` call is what I call the priority level, and you can control which messages are ignored / not compiled in to the dll by raising/lowering the `MINIMUM_MESSAGE_PRIORITY` macro in `$rsp/config.h`, or simply removing the error line like I said.

zilmar's method of emulating MTC0 on CMD_STATUS:
Code:
	case 8: 
		*RSPInfo.DPC_START_REG = RSP_GPR[RSPOpC.rt].UW; 
		*RSPInfo.DPC_CURRENT_REG = RSP_GPR[RSPOpC.rt].UW; 
		break;
My method is more stable than that!
RSP 1.7.0.9 interpreter for PJ64 only unconditionally updates the DPC START and CURRENT reg's. My method uses the documented algorithm and updates DPC_END_REG as well as forcing 64-bit DMA alignment. (My RSP interpreter is not only the fastest but the most accurate to my knowledge. )

So do let me know if the fcube demo runs any better/worse on either RSP plugin, once the error message is voided.
Reply With Quote
  #308  
Old 16th June 2013, 11:26 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Sorry to not post a binary update.

There is nothing to update to the plugin in this thread yet apart from angrylion's find that a game uses 64-bit DWORD-unaligned DMA addressing for DPC CMD_START, which I will now comment in the source code that funnelcube demo uses this problem (as well as remove the error).

Before I post an updated binary with only one change I was thinking I would re-interpret some of MarathonMan's wisdom and figure out some branch-free ways to static-condition-code clamp signed accumulator elements for VMAD* etc. When I update at least one other thing I update the binary; until then make source changes locally.
Reply With Quote
  #309  
Old 17th June 2013, 03:04 AM
angrylion angrylion is offline
Member
 
Join Date: Oct 2008
Location: Moscow, Russia
Posts: 36
Default

How do you know that writes to DPC_START_REG also update DPC_END_REG? From hardware tests? How do you know that the RSP forces 64-bit alignment for data written to DPC_START_REG? I have a testrom that shows that the CPU writes data to DPC_START_REG without forcing alignment, so writing an unaligned address crashes the RDP.
Reply With Quote
  #310  
Old 17th June 2013, 03:15 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by angrylion View Post
I have a testrom that shows that the CPU writes data to DPC_START_REG without forcing alignment, so writing an unaligned address crashes the RDP.
Strictly the MIPS CPU its self, or the RSP CPU?

With the RSP CPU the documented algorithm (however not legally re-publishable that one can type on here) indicates that the value read from SR[rt] is forced to & ~07 (zero the low 3 addressing bits) before being read out to DPC_START, DPC_CURRENT, DPC_END.

However, no, I have no other test resources nor any way of testing on the actual ROM, so any information like one of the test ROMs breaking on the actual machine but not this RSP virtual machine is appreciated.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 10:58 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.