Z64

Please login or register.

Login with username, password and session length
Advanced search  

News:

Check out and improve the wiki!

Pages: [1] 2

Author Topic: IPL4ROM  (Read 8012 times)

Zant

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
IPL4ROM
« on: May 12, 2011, 11:41:33 PM »

Hacked version of the 64DD BIOS that works in emulators. I'm creating a ROM/RAM map of it here with notes.

000079EC (802669EC): Mario bone structure function. Argument 0 is the Display List (bank and offset) to render. Arguments 1-3 are the X, Y, and Z translation values (int) AND variants of the Display List (Mario has three heads just for making his eyes blink, as well as a waving hand and fist, etc). If A1-A3 are used as variants of the Display List, function 80266494 (handles variants) is called following the arguments. If they are used as translation values, function 802665A4 (push matrix) is called. Function 802667EC is called for pop matrix.



00036B40 (80295B40): Model resource file. Bank 01. F3DEX microcode. Contains the N logo, Mario, etc.

More later!
« Last Edit: May 14, 2011, 05:23:44 PM by Zant »
Logged

Jimmy130

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: IPL4ROM
« Reply #1 on: May 13, 2011, 08:43:24 PM »

Can you find variable for error number and message?
Logged

originaLink

  • Wiki Contributor
  • Full Member
  • ***
  • Posts: 141
    • MSN Messenger - censored@msn.com
    • AOL Instant Messenger - censored
    • Yahoo Instant Messenger - censored
    • View Profile
    • censored
Re: IPL4ROM
« Reply #2 on: June 09, 2011, 05:59:27 PM »

Looks good so far, how much progress did you make?
Logged
"This account is active only for nostalgic purposes. I am off to bigger things but i may pop in once in a blue moon. I have no ill feelings but I'm just one individual."

spinout

  • Administrator
  • Sr. Member
  • *****
  • Posts: 309
    • View Profile
    • Email
Re: IPL4ROM
« Reply #3 on: July 02, 2011, 02:36:44 AM »

Something interesting I discovered today: The IPL4ROM is part of the N64 SDK 2.0.
Logged
biggrin.gif

Zeth

  • Full Member
  • ***
  • Posts: 161
    • View Profile
Re: IPL4ROM
« Reply #4 on: July 03, 2011, 04:25:54 AM »

How did you find this out? o.o
Logged

spinout

  • Administrator
  • Sr. Member
  • *****
  • Posts: 309
    • View Profile
    • Email
Re: IPL4ROM
« Reply #5 on: July 03, 2011, 07:36:21 AM »

I recently got a copy of the SDK. I managed to compile one of the demos (flash), it worked in mupen64plus and nemu64 but not on real hardware - either because of bad FlashRAM emulation on the backup device's end, or buffer alignment that emulators ignore.
Logged
biggrin.gif

Zeth

  • Full Member
  • ***
  • Posts: 161
    • View Profile
Re: IPL4ROM
« Reply #6 on: July 29, 2011, 06:00:18 AM »

Speaking of the IPL4ROM, does it work on the 64Drive flash cart?
Logged

spinout

  • Administrator
  • Sr. Member
  • *****
  • Posts: 309
    • View Profile
    • Email
Re: IPL4ROM
« Reply #7 on: July 29, 2011, 10:05:26 AM »

I cannot test it at the moment, but if I recall correctly ZZT32's old youtube had a video of it booting up on a console.
Logged
biggrin.gif

Jimmy130

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: IPL4ROM
« Reply #8 on: July 29, 2011, 10:32:40 AM »

Speaking of the IPL4ROM, does it work on the 64Drive flash cart?
It works on V64jr and Z64 so it should work on 64drive.
Logged

Zant

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: IPL4ROM
« Reply #9 on: October 02, 2011, 04:15:45 PM »

I have found the LEO functions in this screenshot:



I located the code shown in the disassembler window once. It was at 0xA39DD0 in the Expansion Kit. From there, I got these ram offsets for leoOSWritebackDCache, leoOSleoReadWrite+0, and leoOSRecvMesg+0:

8074BA30, 807560F0, and 80746000.

Today, I took it a step further and pinpointed the actual offsets in the disk image. They are at:

0xA80470, 0xA8AB30, and 0xA7AA40.

Epic win.
Logged

spinout

  • Administrator
  • Sr. Member
  • *****
  • Posts: 309
    • View Profile
    • Email
Re: IPL4ROM
« Reply #10 on: October 03, 2011, 04:51:24 AM »

I have found the LEO functions in this screenshot:

http://www.yntproject.net/sitenews/data/upimages/64DDRaise.JPG

I located the code shown in the disassembler window once. It was at 0xA39DD0 in the Expansion Kit. From there, I got these ram offsets for leoOSWritebackDCache, leoOSleoReadWrite+0, and leoOSRecvMesg+0:

8074BA30, 807560F0, and 80746000.

Today, I took it a step further and pinpointed the actual offsets in the disk image. They are at:

0xA80470, 0xA8AB30, and 0xA7AA40.

Epic win.
Funny that those are in the expansion - I would imagine that they would be in the ROM. Did you use LFE or something of the sort?
Logged
biggrin.gif

Zant

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: IPL4ROM
« Reply #11 on: October 03, 2011, 09:28:19 PM »

Funny that those are in the expansion - I would imagine that they would be in the ROM. Did you use LFE or something of the sort?
Bear with me here. If you really want to know how I got the offsets, you have to read my steps.

I only used renegade64, a hex editor, and lemasm. I first typed the MIPS instructions preceding the call to leoOSWritebackDCache from the screenshot into renegade64:

OR A1,S3,R0
JAL 80757850
OR A2,S6,R0
JAL 80747ED0
OR A0,S4,R0
OR A0,V0,R0

And assembled them:

02602825 0C1D5E14 02C03025 0C1D1FB4 02802025 00402025

Then, I searched for the assembled code in the F-Zero Expansion with a hex editor. The only occurrence was at 0xA39DD0. I then picked out the three JALs in the machine code past the search result:

0C 1D 2E 8C (JAL 8074BA30)
0C 1D 58 3C (JAL 807560F0)
0C 1D 18 00 (JAL 80746000)

This correlated leoOSWritebackDCache, leoOSleoReadWrite+0, and leoOSRecvMesg+0 to those ram offsets. This was as close as I could get to finding the exact offsets of the functions for a couple of months. Yesterday, however, I recalled xdaniel stating on The-GCN that the IPL4ROM had Shift JIS encoded Japanese text.

So, I ran a search for hex string 83 66 83 42 83 58 83 4E (ディスク), Katakana for disk, in Japanese F-Zero X (not the expansion). I found it at 0x675F8. I went back from there, to 0x675B4 and grabbed this message:

8E E6 82 E8 88 B5 82 A2 90 E0 96 BE 8F 91 82 F0 82 A8 93 C7 82 DD 82 AD 82 BE 82 B3 82 A2 81 42

I knew where to stop because there was a pair of 00 bytes after the end. I saved this hex string as a new file and loaded it in Mozilla Firefox (I don't have hex workshop, so I couldn't view Shift JIS text in my hex editor). I went to View > Character Encoding > More Encodings > East Asian > Japanese (Shift_JIS). And ta-da:

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

Later, I was watching the hard4games review of the F-Zero Expansion Kit, and an error message came up for them when trying to load Port Town:

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

This is identical to the message I found in regular F-Zero X, with the absence of two characters: りand い. These are the second and fourth characters. I took the hex data for this text string and removed the corresponding 16-bit values to those characters, and it ended up as:

8E E6 88 B5 90 E0 96 BE 8F 91 82 F0 82 A8 93 C7 82 DD 82 AD 82 BE 82 B3 82 A2 81 42

I searched for this in the F-Zero EXPANSION and found it at 0xAA1A84. Scrolling past it, I shortly came to this table at 0xAA1D84:

8076D010 8076D014 8076D018 8076D01C etc.

These are pointers to all of the Japanese text in this part of the disk. The start of the text was at 0xAA1A50:

82 4F 00 00 82 50 00 00 82 51 00 00 82 52 00 00

These are Shift JIS for numbers 0, 1, 2, and 3. 00 00 bytes here are padding. The distance from value 82 4F to value 82 50 is four bytes. Same for the distance from 82 50 to 82 51. This confirmed that the ram pointers 8076D010, 8076D014, and 8076D018 in the table point to these.

I thought, "8076D010... This isn't too far away from 807560F0! One of the LEO functions in ram." I subtracted:

0x8076D010 - 0x807560F0 = 0x16F20

So 0xAA1A50 in the disk image equates to 8076D010 in ram. 0x16F20 bytes back from there could potentially be the LEO function leoOSleoReadWrite+0, if all of this data is loaded into ram exactly how it's laid out here.

0xAA1A50 - 0x16F20 = 0xA8AB30...

I went there in my hex editor, and saw:

3C 0E 80 78 8D CE AC D0 27 BD FF E8 AF BF 00 14

I knew that 27 BD FF E8 was machine code that did something to the stack pointer because of the 27 BD part. I saw it a lot in OoT at or near the start of functions. The 0x10 bytes of data before the above data were all 00's, and before that was 03 E0 00 08, which I knew meant JR RA.

I was pretty convinced at that point that 0xA8AB30 was the start of a function.

0x807560F0 - 0x80746000 = 0x100F0.

Subtracting 0x100F0 from 0xA8AB30 should take me to the start of leoOSRecvMesg+0.

0xA8AB30 - 0x100F0 = 0xA7AA40...

There, I saw:

27 BD FF D8 AF BF 00 1C AF A4 00 28 AF A5 00 2C

And adding 0x5A30 to 0xA7AA40:

0xA7AA40 + 0x5A30 = 0xA80470 (0x80746000 + 0x5A30 = 0x8074BA30)

There:

18 A0 00 1F 00 00 00 00 24 0B 20 00 00 AB 08 2B

Didn't look like the start of a function to me, because I assume that they must start with 27 BD XX XX. However, looking 0x10 bytes back from 0xA80470:

AC 86 00 10 03 E0 00 08 AC 85 00 14 00 00 00 00

I see a JR RA as the second instruction here. Beyond reasonable doubt, I decided that I had found the start of leoOSWritebackDCache. To check the "integrity" of these offsets:

0xA8AB30 + 0x7FCCB5C0 = 0x807560F0!
0xA7AA40 + 0x7FCCB5C0 = 0x80746000!
0xA80470 + 0x7FCCB5C0 = 0x8074BA30!

The final thing that I did to confirm that these offsets in the F-Zero Expansion Kit equated to those ram offsets was open the disk image in LemASM and check out the disassembly view of 0xA7AA40. Six instructions in, at 0xA7AA58 was:

JAL $0074CD20

0x8074CD20 - 0x8074BA30 = 0x12F0
0xA80470 + 0x12F0 = 0xA81760

So ram address 8074CD20 should equate to 0xA81760 here. I go there and am brought to a LUI T2, $8077. The four instructions before this:

JR RA
NOP
NOP
NOP

Completely convinced by this point that I correctly identified the LEO functions. There's my long-winded explanation.

On a closing note, 0x10 bytes before 0xAA1A50 (the start of the Shift JIS Japanese text), I saw this:

00 19 99 12 31 23 59 59

Header file leo.h has this:

typedef struct
{
  u8   pad;
  u8   yearhi;
  u8   yearlo;
  u8   month;
  u8   day;
  u8   hour;
  u8   minute;
  u8   second;
} LEODiskTime;

Let's see here. pad=00, yearhi=19, yearlo=99, month=12, day=31, hour=23, minute=59, second=59. If I didn't know any better, I'd say that I found a time!

December 31, 1999 23:59:59

Perhaps the date the disk was written?
Logged

Jimmy130

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: IPL4ROM
« Reply #12 on: October 03, 2011, 10:55:10 PM »

very interesting

Date that you found is a date, but not production time. I think, this is a date from Nintendo mfs (filesystem).
Pruduction time is in the complete identifiant of disk.
from my blog: http://blog.gamekult.com/blog/jimmy130/145133/identifiants-complets-64dd-final.html

production time : 5 april 2000 10:52:25


« Last Edit: October 03, 2011, 10:58:49 PM by Jimmy130 »
Logged

Zant

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: IPL4ROM
« Reply #13 on: October 03, 2011, 11:10:12 PM »

very interesting

Date that you found is a date, but not production time. I think, this is a date from Nintendo mfs (filesystem).
Pruduction time is in the complete identifiant of disk.
from my blog: http://blog.gamekult.com/blog/jimmy130/145133/identifiants-complets-64dd-final.html

production time : 5 april 2000 10:52:25



Now I'm wondering why I can't find that hex string for the production time in a hex editor...
Logged

Jimmy130

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: IPL4ROM
« Reply #14 on: October 03, 2011, 11:36:41 PM »

Me too, but I read the ID with a gameshark + combo game (Mario Party jap).
When Mario Party read ID disk, It stores the hex string in ram (picture).
Logged
Pages: [1] 2