Jump to content

64DD IPLROM (J) stuff


Twili
 Share

Recommended Posts

Also, I just compared the unmodified BIOS to the one that works in Project64, and it's very different. The model data starts at 0x36B40 in the modified one stead of 0x37750. Lots of Assembly pointers changed. :P

 

ALSO PROOF THAT I FOUND MARIO'S HIERARCHY!

 

-image removed-

Here you see Mario before and after I zeroed the X translation for his torso (ADDIU A1, R0, 0x0044).

 

Hey is it possible we could do custom display lists like in zelda?

Like make a item in sketchup and replace mario head with something else?

Would it be possible to import cusom diplay lists like in zelda.Like after we make an item in sketchup and save it as a obj?

Edited by ZethN64
There is an edit button for a reason, please don't double post unless you are the topic author or have a very good reason to, which this wasn't.
Link to comment
Share on other sites

Looking good so far! I'm guessing the rainbow effect is cause of the vertex shading not being correct yet?

 

Not sure about that. Those are the only Display lists that I have been able to convert and view so far. I tried a shoulder and it didn't work.
Link to comment
Share on other sites

Keep up the good work Twili, its coming along real nicely! :P

 

Thanks, but I think I'm going to take a step back from this until I have an adequate understanding of object hierarchies. The limb connections still blow my mind, particularly the type with both a child limb and a next limb. I'm going to get back to documenting the IPLROM and editing the topic post with my discoveries, so you'll see no more unique post IDs from me in here.
Link to comment
Share on other sites

Ehh... I knew this would happen. Things always go under the wraps when I make a post stating that I'll only edit the topic post, so I had to break my vows. Nobody is going to check the topic post for updates, so...

 

I FOUND THE FONT!!!

 

Posted Image

 

0xA0000. Characters are 4-bit I, 16x16. The numbers here are actually 0x4900 bytes into the font, so they're characters 0x92 - 0x9B. Now we just need the text data.

Link to comment
Share on other sites

Posted Image

 

Good old Shift-JIS; two bytes per character. Not sure if there's any other text inside the ROM.

 

EDIT:

エラー:

 

取扱説明書をお読みください。

 

詳しくは、取扱説明書をお読みください。

リセットスイッチを押してください。

注意 アクセスランプ点滅中に 

ディスクを抜かないでください。

メモリー拡張パックが正しく

差し込んでありますか?

時刻を設定してください。

 

時刻設定

 

設定:十字キー、3Dスティックの上下

 

移動:十字キー、3Dスティックの左右

 

決定:Aボタン、スタートボタン

取消:Bボタン

年月日月火水木金土日午前午後時分():

Edited by xdaniel
Link to comment
Share on other sites

Ehh... I knew this would happen. Things always go under the wraps when I make a post stating that I'll only edit the topic post, so I had to break my vows. Nobody is going to check the topic post for updates, so...

 

I FOUND THE FONT!!!

 

-image removed-

 

0xA0000. Characters are 4-bit I, 16x16. The numbers here are actually 0x4900 bytes into the font, so they're characters 0x92 - 0x9B. Now we just need the text data.

 

One of the hardest part about trying to find Japanese text data, is if I am correct, is in Unicode which most hex editors don't support. Though great job on finding the font!
Link to comment
Share on other sites

Thanks, but I think I'm going to take a step back from this until I have an adequate understanding of object hierarchies. The limb connections still blow my mind, particularly the type with both a child limb and a next limb.

#3039 should give you a hand on understanding it. Next limbs are the ones that are straight below, child limbs are ones which branch to the right.
Link to comment
Share on other sites

*image with Japanese text*

 

Good old Shift-JIS; two bytes per character. Not sure if there's any other text inside the ROM.

 

EDIT:

エラー:

 

取扱説明書をお読みください。

 

詳しくは、取扱説明書をお読みください。

リセットスイッチを押してください。

注意 アクセスランプ点滅中に 

ディスクを抜かないでください。

メモリー拡張パックが正しく

差し込んでありますか?

時刻を設定してください。

 

時刻設定

 

設定:十字キー、3Dスティックの上下

 

移動:十字キー、3Dスティックの左右

 

決定:Aボタン、スタートボタン

取消:Bボタン

年月日月火水木金土日午前午後時分():

 

Excellent work there, xdan. I kinda already translated that for Zeth, but it would have been easier with it all in text format instead of going by a screenshot and initiating a grueling kanji search. lol
Link to comment
Share on other sites

Posted Image

 

Because text strings must be word-aligned, the buffer between a message and the next can be used when editing. "エラー:" -> "Error" is most certainly the only extreme case where this works without repointing, though, because of the Shift-JIS deal. The error number will have to be shifted over to prevent the overlap seen here.

Link to comment
Share on other sites

Because text strings must be word-aligned, the buffer between a message and the next can be used when editing. "エラー:" -> "Error" is most certainly the only extreme case where this works without repointing, though, because of the Shift-JIS deal. The error number will have to be shifted over to prevent the overlap seen here.

 

Is that some kind of error message from japenese n64's?
Link to comment
Share on other sites

I realized that the image in this post on page 1, the disassembly is from the F-Zero Expansion Kit.

 

OR A1,S3,R0

JAL 0x80757850

OR A2,S6,R0

JAL 0x80747ED0

OR A0,S4,R0

OR A0,V0,R0

JAL <leoOSWritebackDCache>

LW A1,0x0000(S6)

LW A0,0x0040(SP)

LW A1,0x0044(SP)

OR A2,S2,R0

OR A3,S4,R0

SW S3,0x0010(SP)

JAL <leoOSleoReadWrite+0>

SW S7,0x0014(SP)

OR A0,S7,R0

OR A1,S1,R0

JAL <leoOSRecvMesg+0>

ADDIU A2,R0,0x0001

 

If you assemble the first six instructions shown and search for them in the EK, you will find them at 0xA39DD0 (you obviously can't assemble a JAL with a label unless you define it first). Identifying these leoOS function calls in the machine code, though, you will discover that they map to 8074BA30, 807560F0, and 80746000. You will never find the functions themselves, because they are internal to the 64DD and Kammedo is reverse engineering them.

 

Now I wonder what LEO stands for... maybe L for Laser.

Link to comment
Share on other sites

  • 2 weeks later...

This screenshot is apparently taken from the 64DD emulator (not Project Unreality):

 

Posted Image

 

「F-ZEROX〠ã¯, ã“ã®ディスクã ã‘ã§ã¯プレイ

ã§ãÂÂã¾ã›ん.

NINTENDO64ソフト 「F-ZEROX〠ã®カセット

ã‚’64本体ã«セットã—ã¦, é›»æºÂを入れ直ã—ã¦ãÂÂã 

ã•ã„.

 

Could I get a proper translation of this? And did I make any mistake transcribing the text above?

Link to comment
Share on other sites

Mario's full hierarchy:

 

Posted Image

 

Now I completely understand how object hierarchies work from a non-matrix point of view. Let's use our good ol' friend object_oB1 for example:

 

06|05AA 0000 0000 070A 00000000

07|04E2 0000 0000 0809 00000000

08|0000 0000 0000 FFFF 060008E8

09|0000 0000 0000 FFFF 06000750

0A|0000 0000 0000 FFFF 06000448

 

This is one of his legs. Here's how it "actually" works:

 

Limb 06's connection type is 070A. We're going to ignore the second byte for now. The first byte says that limb 07 will inherit this limb's translation (1,450 on the X, 0 on the Y, and 0 on the Z).

 

Now we're in limb 07. Its translation is 2,700 on the X, 0 on the Y, and 0 on the Z because it inherited the translation from the previous limb PLUS its translation of 1,250 (1,250 + 1,450 = 2,700). Its connection type is 0809. We're going to ignore the second byte again. As you may have guessed, limb 08 is going to inherit this limb's translation (2,700 on the X, 0 on the Y, and 0 on the Z).

 

Limb 08. Its translation is 2,700 on the X, 0 on the Y, and 0 on the Z because it inherited the translation of the previous limb PLUS its translation of 0 (2,700 + 0 = 2,700). Its connection type is FFFF! This means that we've reached the end of a full connection. Like I said, we're not going to deal with any pushes or pops here because we're doing this from a non-matrix point of view.

 

Here's where the second byte of a connection type comes in. This is the "next limb", the first byte was the "child limb". The next limb will inherit the translation of its grandparent, AKA the limb that is two limbs back in a full connection. Here's how this plays out with object_oB1:

 

I said that limb 06's connection type was 070A. The second byte being 0A means that limb 0A is the next limb. The next limb's translation will be 0 on the X, 0 on the Y, and 0 on the Z because it doesn't have a grandparent.

 

Limb 07's connection type was 0809. The second byte being 09 means that limb 09 is the next limb. The next limb's translation will be 1,450 on the X, 0 on the Y, and 0 on the Z because its grandparent is limb 06.

 

SO! The final translation of all of the limbs will be:

 

06: X=1,450 Y=0 Z=0

07: X=2,700 Y=0 Z=0

08: X=2,700 Y=0 Z=0

09: X=1,450 Y=0 Z=0

0A: X=0 Y=0 Z=0

 

Limb 08 has a Display List, 060008E8. This is a brown boot. Limb 09 has a Display List, 06000750. This is a green pant leg. Limb 0A has a Display List, 06000448. This is a green thigh (actually the upper part of the pant leg, but I use thigh/leg and shoulder/forearm for distinction). This is what it looks like translated properly:

 

Posted Image

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.