+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Phoenix Wright NDS Script to GBA: Last Updated Sept. 11, 2008
Pages: 1 2 [3] 4 5 ... 10
Author Topic: Phoenix Wright NDS Script to GBA: Last Updated Sept. 11, 2008  (Read 5 times)
andwhyisit
Guest
« Reply #30 on: March 09, 2008, 02:41:13 am »

Quote from: akadewboy on March 09, 2008, 12:37:24 am
It looks like there's only 3,864 bytes of free space at the end of GS3, so I really hope you don't run out of space.  Shocked Maybe this is one reason why it wasn't localized?
The people who localise these games have the original source code, so I doubt that would be an issue for them.

Quote from: cocomonk22 on March 08, 2008, 08:55:31 pm
Whoops, I was missing some pointers in the script... try this one: http://pw.scorpei.com/ips/GS3_English00e1.ips Smiley
Thanks, I'll check it out.

Also:

Pheonix Wright on PSP!

EDIT: It worked! Thanks!

EDIT2: Case 1 worked perfectly. Though case 2 has an "overflow issue" after examining the computer in the museum basement, I'll look into finding any other bugs.
« Last Edit: March 10, 2008, 09:13:00 pm by andwhyisit »
Redlandsman87
Guest
« Reply #31 on: March 10, 2008, 09:50:54 pm »

I just finished the first trial, and I must say, your efforts are fantastic so far. I'm very much looking forward to the rest of the translation.
andwhyisit
Guest
« Reply #32 on: March 13, 2008, 05:33:22 pm »

Any progress on Case 2?
akadewboy
Guest
« Reply #33 on: March 13, 2008, 06:15:15 pm »

Check it out:



I worked out the title screen problem. It was just as I suspected, the new title screen doesn't compress as well as the original Japanese one. So what I had to do was reduce the amount of colors in some of the troublesome title screen parts. (the less colors in the image the better it usually compresses).

cocomonk22 here's the title screen parts, you can use them in your next patch:
http://www.fileden.com/files/5938/GS3titlescreenparts.zip

For those of you that can't wait, you can apply this patch to your translated ROM to get the new title screen:
http://www.fileden.com/files/5938/GS3titlescreenpatch.zip
andwhyisit
Guest
« Reply #34 on: March 13, 2008, 10:48:38 pm »

Quote from: akadewboy on March 13, 2008, 06:15:15 pm
Check it out:



I worked out the title screen problem. It was just as I suspected, the new title screen doesn't compress as well as the original Japanese one. So what I had to do was reduce the amount of colors in some of the troublesome title screen parts. (the less colors in the image the better it usually compresses).

cocomonk22 here's the title screen parts, you can use them in your next patch:
http://www.fileden.com/files/5938/GS3titlescreenparts.zip

For those of you that can't wait, you can apply this patch to your translated ROM to get the new title screen:
http://www.fileden.com/files/5938/GS3titlescreenpatch.zip
Nice. Does it work with patch version 00e1 or just 00e?

After playing case 1 I believe there should be "Mia Fey: Ace Attorney" series. Smiley
« Last Edit: March 13, 2008, 11:10:36 pm by andwhyisit »
Nightcrawler
Guest
« Reply #35 on: March 14, 2008, 07:33:34 am »

Good idea. They should try having a woman as the main character. Unfortunately, unless it's a prequel, it won't be Mia.
Guadozoku
Guest
« Reply #36 on: March 14, 2008, 09:56:14 am »

And what prosecutor would Mia go up against in a prequel? One case against Payne and 3 vs Lana Skye? Edgeworth and von Karma both never lost a case, so they're both out at least.
Nightcrawler
Guest
« Reply #37 on: March 14, 2008, 11:52:09 am »

There's nothing that says it can't be a completely new prosecutor never before seen in the series. It would have less of a link that way to the main series, but I'm sure with some creativity one could come up with some nice story links.
cocomonk22
Guest
« Reply #38 on: March 14, 2008, 04:20:43 pm »

akadewboy, thanks for fixing the title! I'll include it with the next ips.

I'm having a bit of trouble finding an address to insert case 2-2 overflow, since I already used 0x007f0000 for the case 1-1overflow. Is there a way to increase the size of the gba rom or to find blank space?
KC
Guest
« Reply #39 on: March 14, 2008, 04:25:56 pm »

You can expand any GBA rom up to 32mb without any problem. As the memory address starts at 0x8000000, the latter 16mb will have pointers in the 09XXXXXX range.
cocomonk22
Guest
« Reply #40 on: March 14, 2008, 06:32:18 pm »

Cool, that solves the space problem, thanks KC :thumbsup:

Things that still need to be fixed:
  • None of the evidence/profile descriptions past the first case are in English. I've been using unLZ to find locations of graphics compressed with LZ77, so hopefully there is an order to them in the rom.
  • At times, you are asked a question and must decide between two or three answers. These questions were graphics in the DS game, and so will require playthrough of the DS version to be copied into the GBA script. There are many full videos of DS gameplay, but unfortunately, those videos only capture the top screen. I'll need those answers at least up until the first trial with Godot before releasing the next patch.

Edit: I found a location image in RAM using breakpoints in VBA:
Code:
debugger> bpw 06013400 20
Added break on write at 06013400 for 20 bytes
debugger> c
Breakpoint (on write) address 06013400 old:0000 new:0000
Breakpoint (on write) address 06013402 old:0000 new:0000
Breakpoint (on write) address 06013404 old:0000 new:0000
Breakpoint (on write) address 06013406 old:0000 new:0000
Breakpoint (on write) address 06013408 old:0000 new:0000
Breakpoint (on write) address 0601340a old:0000 new:0000
Breakpoint (on write) address 0601340c old:0000 new:0000
Breakpoint (on write) address 0601340e old:0000 new:0000
Breakpoint (on write) address 06013410 old:4444 new:fff0
Breakpoint (on write) address 06013412 old:4444 new:ffff
R00=80000400 R04=03002cd0 R08=030037b0 R12=03007200
R01=040000d4 R05=030038f1 R09=03003c54 R13=03007e94
R02=0200afc0 R06=00000000 R10=03003a08 R14=08010b1b
R03=00000003 R07=06013400 R11=00000000 R15=08010b28
CPSR=0000003f (......T Mode: 1f)
08010b24  6088 str r0, [r1, #0x8]
> 08010b26  6888 ldr r0, [r1, #0x8]
08010b28  2300 mov r3, #0x0
debugger> mw 040000d4
040000d4 0200afc0 06013400 00000000 00000000 .....4..........
040000e4 00000000 00000000 00000000 00000000 ................
040000f4 00000000 00000000 00000000 0080fb82 ................
04000104 00000000 00000000 00000000 00000000 ................
04000114 00000000 00000000 00000000 00000000 ................
04000124 00000000 00000000 00000000 000003fe ................
04000134 00008000 00000000 00000000 00000000 ................
04000144 00000000 00000000 00000000 00000000 ................
04000154 00000000 00000000 00000000 00000000 ................
04000164 00000000 00000000 00000000 00000000 ................
04000174 00000000 00000000 00000000 00000000 ................
04000184 00000000 00000000 00000000 00000000 ................
04000194 00000000 00000000 00000000 00000000 ................
040001a4 00000000 00000000 00000000 00000000 ................
040001b4 00000000 00000000 00000000 00000000 ................
040001c4 00000000 00000000 00000000 00000000 ................
debugger>


Saved from memory viewer at 0200AFC0:


That address is in WRAM. How do I find its address/compression method in the rom?

Also OAM sprite 38 and 39:

« Last Edit: March 14, 2008, 08:39:44 pm by cocomonk22 »
KC
Guest
« Reply #41 on: March 14, 2008, 08:52:51 pm »

Well, the game used a DMA transfer to copy the data from WRAM into VRAM. That would be a bit odd for the bios compression scheme, as there's an implementation that supports writing into VRAM directly.
A DMA transfer (at least the one you use for normal data) is activated by writing some words to 40000d4 and up (three words in total, first the source address, then the destination address, and last the control word).
In this case, it transfers 400h halfwords (= 2048 bytes) from 200afc0 to 6013400. You should set a writing breakpoint to the first address and see where it triggers. If r15 is in the ROM area (8000000 and up), then it's most likely a custom compression scheme.
cocomonk22
Guest
« Reply #42 on: March 14, 2008, 09:34:33 pm »

By first address, do you mean 0200afc0? If so, here is the result:

Code:
debugger> bpw 0200afc0 20
Added break on write at 0200afc0 for 20 bytes
debugger> c
Breakpoint (on write) address 0200afc0 old:00 new:00
Breakpoint (on write) address 0200afc1 old:00 new:00
Breakpoint (on write) address 0200afc2 old:00 new:00
Breakpoint (on write) address 0200afc3 old:00 new:00
Breakpoint (on write) address 0200afc4 old:00 new:00
Breakpoint (on write) address 0200afc5 old:00 new:00
Breakpoint (on write) address 0200afc6 old:00 new:00
Breakpoint (on write) address 0200afc7 old:00 new:00
Breakpoint (on write) address 0200afc8 old:00 new:00
Breakpoint (on write) address 0200afc9 old:00 new:00
Breakpoint (on write) address 0200afca old:00 new:00
Breakpoint (on write) address 0200afcb old:00 new:00
Breakpoint (on write) address 0200afcc old:00 new:00
Breakpoint (on write) address 0200afcd old:00 new:00
Breakpoint (on write) address 0200afce old:00 new:00
Breakpoint (on write) address 0200afcf old:00 new:00
Breakpoint (on write) address 0200afd0 old:00 new:f0
Breakpoint (on write) address 0200afd1 old:00 new:ff
Breakpoint (on write) address 0200afd2 old:00 new:ff
Breakpoint (on write) address 0200afd3 old:00 new:ff
R00=08223c78 R04=03002cd0 R08=030037b0 R12=03007200
R01=0200afc0 R05=030038f1 R09=03003c54 R13=03007e94
R02=0200afc0 R06=00000000 R10=03003a08 R14=08010b1b
R03=00000003 R07=06013400 R11=00000000 R15=0803a04c
CPSR=0000003f (......T Mode: 1f)
0803a048  df11 swi $11
> 0803a04a  4770 bx lr
0803a04c  df01 swi $01
debugger>
I'm not quite sure how to read the results, though.
labmaster
Guest
« Reply #43 on: March 14, 2008, 10:49:20 pm »

Quote from: cocomonk22 on March 14, 2008, 09:34:33 pm
I'm not quite sure how to read the results, though.
I think the technical interpretation would be 'it's your lucky day!'.

Code:
0803a048  df11 swi $11
> 0803a04a  4770 bx lr

This is telling you that all of those writes were caused by Software Interrupt $11 (a BIOS function) - if you look it up in gbatek you'll see that it's LZ77UnCompWram. The function takes two arguments, which you'll see in r00 (the source) and r01 (destination).

[NB: Decompressing to an EWRAM buffer then transferring to VRAM via DMA is actually a pretty common pattern.]
andwhyisit
Guest
« Reply #44 on: March 15, 2008, 08:03:48 pm »

Quote from: cocomonk22 on March 14, 2008, 04:20:43 pm
akadewboy, thanks for fixing the title! I'll include it with the next ips.

I'm having a bit of trouble finding an address to insert case 2-2 overflow, since I already used 0x007f0000 for the case 1-1overflow. Is there a way to increase the size of the gba rom or to find blank space?
Glad to see you are still at it. Smiley
Pages: 1 2 [3] 4 5 ... 10  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC