News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - phonymike

Pages: [1] 2 3
1
ROM Hacking Discussion / Re: Editing text in Shadowrun (SNES)
« on: February 02, 2021, 11:02:30 pm »
The make.bat copies the original rom to "sr.sfc", so the original is unmodified. Then xkas does this:

Code: [Select]
org $BFFFFF ;pad to 16 mbit
db $00

which expands the sr.sfc by putting a 0x00 right at the 16 mbit position, file address 0x1FFFFF. No need to expand  :thumbsup:

2
Woah, have you been entering hex codes by hand to get the asm?

You can use an assembler like armips or xkas-plus to convert your asm into hex. Makes it a lot easier and they take care of addresses for you.

3
ROM Hacking Discussion / Re: Editing text in Shadowrun (SNES)
« on: January 29, 2021, 11:20:09 pm »
I made a lot of progress as far as these "lines" are concerned. The pointer table at 0x5980 points to 612 different lines of text. The "conversations" are different because they are more like chunks of pointers, that vary in size. So the conversations will be a little more difficult, but I hope atlas can deal with it.

I was able to decompress the "lines", and use atlas to insert them into the ROM at 0x101000, and update the pointer table at 0x5980. I also wrote some (messy) asm to copy the uncompressed strings into the memory location for text (0x7E21A0). The only problem is the game doesn't show the text. There looks to be a little more to the text decompression routine than just placing the text at 0x7E21A0, maybe as each letter is decompressed it updates some pointer for something.

I included everything except xkas.exe (v0.06), atlas.exe (1.11), and the Shadow Run ROM. Put those in the main folder, and run make.bat. To extract the script (it's already extracted), in the script_dump folder there's a dump_lines.bat. It puts the output in the previous main folder.

The cool thing is the code for the conversations and the lines come from different areas, so I'm able to filter the "lines" by setting the carry flag. The conversation text does not have the carry flag, so it is decompressed and displayed as normal. So my code can tell the difference. I haven't tested it much at all though, but it at least works for the first few text dialogs.



Hopefully I can get it working in the next several days. If I make more progress, I'll make a projects thread so more people can find this work and hopefully expand to a full Shadow Run script project. I've only seen the text for "lines" and "conversations". I don't see script triggers like giving the player 2,000. The script could say anything, but the game will still only give 2,000.

Download

4
ROM Hacking Discussion / Re: Editing text in Shadowrun (SNES)
« on: January 27, 2021, 11:22:56 pm »
I modified one of the programs to dump these lines, I count 612 of them from the pointer table.

Download it in my next post.

Code: [Select]
[348] 0xF1136
Dances with Clams does not work for money. He merely requires a donation of 2,000 nuyen to the Tribal Balldance Fund. I sense great need. Do you wish to make a donation?

I show it as line 348 (decimal) in the pointer table. Since each pointer is 2 bytes, multiply 348 x 2, and add it to the start of the pointer table 0x5980 and you get pointer 0x5C38. The values at that location are 0x36 0x91. Byteswap them and add 0xE8000 to get the rom location 0xF1336.



The script dump tells us the location 0xF1336 and that's really helpful to know, but you're only allowed to change that line as long as it's shorter than the original text. The pointer table gives us a lot more control. You could make this line longer, and the next line shorter, and just change the pointer to the second line to be farther than it was originally.

The only problem with this pointer table is that it only allows text to be located within a certain range. This might be a different routine than the conversation routine. Maybe these lines could be inserted uncompressed and the routine changed to point to expanded rom space.

5
ROM Hacking Discussion / Re: Editing text in Shadowrun (SNES)
« on: January 22, 2021, 11:12:38 pm »
I did a little searching around in the ROM, and it seems at $80:947A (0x147A unheadered ROM file) there's a pointer table to the conversations. The pointer table is 0x116 bytes in length, and 2 bytes per pointer. You need to take the pointer, and add bank $8D to get the snes memory address. For example, the third pointer 0x6F 0x90 gets byteswapped, and add 0x8D resulting in snes mem pointer $8D:906F (0x6906F unheadered ROM file).

The conversations are shown in conversedump.txt. The conversations have a structure you can see in shadowconverse.c, with a pointer to the character photo, and pointers to possible dialog strings. At least I think this is how it works.

So there's a pointer table for the conversations, and each conversation contains pointers to compressed text strings.

Keep in mind these script dump files may show ROM file locations with an extra 0x200 byte header.
Code: [Select]
66      42     E8966    Tread carefully whelp, you have much to overcome.
This is location 0xE8766 (snes mem $9D:8766) using an unheadered ROM.

6
ROM Hacking Discussion / Re: Editing text in Shadowrun (SNES)
« on: January 20, 2021, 12:44:45 am »
The way I would do it, is dump the entire script to plain text, and then change the decompression routine to simply copy the uncompressed text to RAM. If the script dumper could create a file compatible with atlas, you could reinsert the uncompressed script into space at the end of the ROM (expand it) and atlas would update the pointers.

update: There seems to be lots of effort into editing the script to this game but no actual hacks to show for it. This post by RetroHelix links to a zip file with tons of info.

I looked into the code a little bit but couldn't find a pointer table. If you update the script, but your text is longer than what the game already contains, then it will throw off all the text after that. So you recalculate the pointer table. Unless this game somehow works differently than that.

Also on datacrystal there's a ton of information, as well as a python script compressor.

7
ROM Hacking Discussion / Re: Need help turning an AR code into a patch
« on: December 15, 2020, 08:11:15 am »
I found a forum post by guess who. The next post describes downloading ARCrypt and shows some decrypted raw codes. So go download ARCrypt.

Using ARCrypt, if you paste the japanese AR code in the left window, then below in the "From" window choose "AR v3/4". Then on the right in the "To" window click "RAW". Then click "Proceed".

US decrypted code:
00000000 1803B517
000070A3 00000000

Looking at GBATEK, it shows what the raw values mean.
Quote
00000000 18aaaaaa 0000zzzz 00000000  [8000000+aaaaaa*2]=zzzz  (ROM Patch 1)

The "aaaaaa" represents where to get the address (03B517). GBATEK says to multiply that by 2 and we get 76A2E.

Looking at the "zzzz" part is the data we use for the patch (70A3). You have to swap the two bytes (xxyy = yyxx) and you get A370.

If you open the US rom in a hex editor and go to 76A2E, and overwrite the values with A370, you will have done the same thing as the US .ips patch.



Now just convert the japanese code into raw, convert the address and data, save it. Then use a program like Lunar IPS to make a patch  :thumbsup:

8
Newcomer's Board / Re: Not sure if I should submit my primitive "hack"
« on: December 10, 2020, 06:16:15 pm »
I would be interested in seeing your method to come up with the hack in the first place. I'd like to see a few lines of assembly, even just in the readme. You never know, maybe the method would help someone else hack another game, even if it's just changing one byte. I try to collect all the effort and knowledge that went into the hack and put it out there for someone else to learn from.

9
I made a tool to convert .bmp files into the 5 bit graphics NBA JAM uses. It's command line, so it's meant to be used in an automated way. Once you run it, it dumps all the images to .bmp into a folder. You are then free to use any graphics editor (I use photoshop) to make changes. The tool can then insert the images back into the ROM. The palette of the .bmp files must be 8 bit, and the first color in the palette will be used as transparency.

Download it here. Of course the C source is in there too.

There's also 2 other graphical utilities used to editing graphics, I linked them in the Data Crystal.

10
Personal Projects / [Tutorial] Finding GBA pointers
« on: December 04, 2020, 04:16:32 am »
Hey everybody. I wrote up a tutorial on finding GBA pointers using No$gba. I want it to be very compatible so I made it in html with embedded images. I'd like some feedback on it. I'm not looking to make any drastic changes, but any suggestions to make it easier to follow would be welcome. It's aimed at a beginner who knows how to use a hex editor but might be afraid of assembly.
  • Can any parts be simplified or made to be more clear?
  • Does it flow well?
  • Are the images too big?
  • Should I change the "Step 1", "Step 2" etc. titles?
  • Is the document in the proper tense? Step 3: "We found a result..." Step 4: "After a few more searches we find a result..."

possible changes:
  • Add shortcuts at the beginning to each step.
  • I might break Step 15 into separate steps with a few more images.

Thanks for taking a look, you can download it here.

11
Hi. I posted the location of the pointer table in another thread. It's better to make only one topic per project.

I was able to use cartographer and dump what seems to be most of the script. And then I used atlas to insert the script. Atlas will adjust the pointers as needed to give you freedom while editing the script.

Download this file (version 2), it is part of the extracted script, and can be inserted into the rom. You need to put atlas.exe and "Yu-Gi-Oh! - GX Duel Academy (U).gba" into the same folder as these files, and run "insert.bat". The script will be inserted and you'll have "modified.gba".

Let me know how it works for ya.



EDIT: I went through and cleaned up the script. It has 4,521 strings, and it inserts into the rom with no problems. You need atlas for it to work. There is still the tutorial text, and some other texts like "Blue-Eyes White Dragon..Mystical Elf..Baby Dragon.Ryu-Kishin..Feral Imp"

12
Newcomer's Board / Re: I can't find pointers in this game (GBA/Hex editing)
« on: November 21, 2020, 09:59:41 pm »
Hello. The script starts at ROM hex 0x013F6DF0, pointer table starts at ROM hex 0x014280B0 (4 bytes per pointer).

The pointer for "Welcome, elite duelists!" is at 0x0142AF90, which is 0x00012E3C.
0x00012E3C + 0x013F6DF0 = 0x0142AF90

If you want to move or expand the script or pointer table:
The pointer to the script is at ROM hex 0xBB650 (F0 6D 3F 09) which is GBA hex 0x093F6DF0 (ROM hex 0x013F6DF0)
The pointer to the pointer table is at ROM hex 0xBB64C (B0 80 42 09) which is GBA hex 0x094280B0 (ROM hex 0x014280B0)

To convert ROM hex into GBA hex just add 0x8000000  :thumbsup:

13
Programming / Re: Snes 65816 assembly - How do TRB and TSB opcodes work?
« on: November 12, 2020, 02:57:00 am »
I use 65816 Programming Primer for instruction details (well I have a plain text version of it.)

Quote
TRB Test and Reset Memory Bits
------------------------------

TRB performs a logical AND of the accumulator's compliment and the
effective address - data is then rewritten back to the specified address.
This clears each memory bit that has a corresponding bit set in the
accumulator, leaving all other memory bits unchanged.

To put it another way - TRB flips or inverts the accumulator value and then
AND's that value with memory operand and stores the result back to the
effective address.

Quote
TSB Test and Set Memory Bits
----------------------------

TSB logically OR's the accumulator and the data at the effective address.
This effectively sets a bit at the memory location for each bit set in the
accumulator.

Quote
       Flags Affected: ------z-
                       z Set if memory value AND'ed with accumulator value is zero.

This is the only part that got me. If the value at the memory location (before the instruction begins) AND'ed with the accumulator value is zero, then Z is set.




Code: [Select]
;xkas v0.06
lorom

Start:
phk ; Put current bank on stack
plb ; make it current programming bank
clc ; Clear Carry flag
xce ; Native 16 bit mode  (no 6502 Emulation!)


;=======================================================
; TRB
;=======================================================

lda #$00
sta $0000
lda #$00
trb $0000

;result: $0000 = $00, zero flag is set

lda #$00
sta $0000
lda #$FF
trb $0000

;result: $0000 = $00, zero flag is set

lda #$FF
sta $0000
lda #$00
trb $0000

;result: $0000 = $FF, zero flag is set

lda #$FF
sta $0000
lda #$FF
trb $0000

;result: $0000 = $00, zero flag is cleared

;=======================================================
; TSB
;=======================================================

lda #$00
sta $0000
lda #$00
tsb $0000

;result: $0000 = $00, zero flag is set

lda #$00
sta $0000
lda #$FF
tsb $0000

;result: $0000 = $FF, zero flag is set

lda #$FF
sta $0000
lda #$00
tsb $0000

;result: $0000 = $FF, zero flag is set

lda #$FF
sta $0000
lda #$FF
tsb $0000

;result: $0000 = $FF, zero flag is cleared


- jmp -

;=====================
;CPU Exception Vectors
;=====================
org $FFE0
;Native $00:FFE0
dw $00, $00 ;4 bytes unused
dw Start ;2 bytes COP
dw Start ;2 bytes BRK
dw Start ;2 bytes ABORT
dw Start ;2 bytes NMI
dw $00 ;2 bytes unused (would be RESET, but the SNES always boots in Emulation mode)
dw Start ;2 bytes IRQ
;Emulation $00:FFF0
dw $00, $00 ;4 bytes unused
dw Start ;2 bytes COP
dw $00 ;2 bytes unused (would be BRK, but BRK and IRQ share the same vector in Emulation mode)
dw Start ;2 bytes ABORT
dw Start ;2 bytes NMI
dw Start ;2 bytes RESET
dw Start ;2 bytes IRQ/BRK

;==========================
;Create new internal header
;==========================
org $FFC0
db "Mike's test asm      "
;  "---------------------" 21 characters

db $30 ;LoROM and fastrom
db $02 ;ROM/RAM/BATT
db $0A ;ROM size 8 mbit
db $03 ;SRAM size 8KB
db $00 ;Country: Japan
db $01 ;Nintendo
db $01 ;version 1.1
dw $D609 ;checksum compliment
dw $29f6 ;good checksum ;)

14
Ucon64 also supports Game Genie and has source code for it in the "src\patch\gg.c" file.

As for a "cheater", I think and Arduino would be fast enough to replay TAS controller input (youtube search tasbot) through the controller port, but not fast enough to change ROM values in real time as a Game Genie would. Maybe an FPGA would work for that?

There's also the Pro Action Replay, which can modify RAM values. I'm guessing rather than just modify the ROM data bus (is that how the GG works?) It actually runs code which can update the RAM values in the SNES. It even has a feature where you reset the SNES, and it will search through the memory and find codes just like the cheat search in a SNES emulator.

15
Once you figure out where the value in RAM is, you'll want to take that value from RAM and display it as a BG tile, so you're going to want to know where the BG map data is stored and how to change it. BG map data can be placed at different places in RAM, and you can use no$gba's Vram Viewer to see the BG maps 0, 1, 2, and 3. It will show you the actual map address, like 6001036 for example. Addresses for the GBA that start with 6xxxxxx are VRAM addresses. Memory that's used to display data on the screen. If the variable that you want to display is from 02038E7C, memory at 2xxxxxx is WRAM (Work RAM) also general purpose RAM. So you'd need to read data from 02038E7C and copy it to 6001036 for example. These are probably not the exact memory addresses but that's for you to figure out.

Using the example assembly code from [Unknown] (because my gba assembly is rusty), your code might look something like this
Code: [Select]
ldr r1,=2038E7Ch ;load address of variable into r1
ldr r0,[r1] ;load what's at address r1, put it into r0
ldr r1,=6001036 ;load address of map spot for new tile into r1
str r0,[r1] ;store value from r0 to address in r1

It looks like you can use xkas-plus v14+1 to assemble the commands and insert into the ROM pretty easy. Locations starting with 8xxxxxx are ROM cartridge locations and that's where your hack will be stored.

You'll also need to insert a jump into the game's code. This will interrupt the code, make it execute your code, and then return to the game code.

16
Newcomer's Board / Re: I have MSCOMCTL.OCX but...
« on: September 12, 2020, 05:58:42 am »
I'm pretty sure I found the problem.

I know its there. I followed the instructions to the letter too.

MSCOMCTL.OCX in SysWOW64
open the command window (right click, run as administrator)
go to C:\WINDOWS\SYSWOW64
Run: regsvr32 mscomctl.ocx

Same error message.

I got xenoscript working, but it bugged me about a few other things. I had to register comdlg32.ocx and richtx32.ocx also (got them from a website called ocxdump). Check the properties of .ocx files you download, click digital signatures, and details to make sure the signature is OK. You don't want any dirty ActiveX applications running on your machine  :)

Then when you get the 429 ActiveX component can't create object and Run-time error '91' Object variable or With block variable not set errors, you gotta do the same thing and register sqlite3.dll which would be done with the run_me.bat but fails. Just edit run_me.bat to include the full path to sqlite3.dll like below, save, then right click and run run_me.bat as administrator:

Code: [Select]
:run_me.bat

c:\windows\syswow64\regsvr32 "c:\program files (x86)\Xenoscript\sqlite3.dll"

Side note: you want to put the .ocx files into the SysWOW64 (Windows 32-bit on Windows 64-bit) folder, and run the regsvr32 from the SysWOW64 folder. Which is exactly what you did I'm just pointing out the significance for other readers. sqlite3.dll can stay in the xenogrears folder because it probably isn't used by anything else if you didn't have to register it. Good luck  :thumbsup:

17
There's an old program called SNESSOR v2.1 which can rip and insert SNES sound samples. It's a DOS command line program (from over 22 years ago lol), it will not run under Windows so you'll need to run a DOS emulator first like DOSBox to run the program. It's not an easy task, but it's another option for you. SNESSOR 95 might run in Windows, but it can't insert sound samples.

18
Hey again. This is just something funny I came across on one of dejap's archived webpages. It's at the bottom of the first post. It's in response to what you mentioned earlier.

AFter several days i have to admit that i m beaten trying to dejap the end of the game

Here's a quote from Tomato
Quote
P.S. "DeJap" is NOT a verb! Don't make me come over there!

I thought it was funny  :laugh:

19
I have an old "Lufia (US).smc" that has the CRC32 of 087FCACF. With the header removed it is 5E1AA1A6. So it's the same game. If you add a header (so it's 1,049,088 bytes), then it's the correct file to patch. After patching and removing the header, I got CRC32 of 55FF8A59 for Restored 2.4.1 and 27E5A7A3 for Restored VANILLA FONT 2.4.1 which should match yours if you remove the header.

Here are the 512 bytes (0x200 hex) from the beginning of the file (the header). These bytes are not part of the game, they are settings for HiROM/LoROM, SRAM size etc that are used by an old copier device. They can safely be removed after patching. If your ROM is 1,049,088 bytes, overwrite the first 512 bytes with the following. If you have the nointro ROM with a size of 1,048,576 bytes and CRC32 5E1AA1A6, insert these 512 bytes at the beginning. Then you will have the CRC32 087FCACF file.

Spoiler:
Code: [Select]
00000000 80 00 00 00 00 00 00 00 AA BB 04 00 00 00 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 ................

This is the problem with SNES ROMs and old copier/backup unit headers. The header is metadata from the copier saved along with the ROM data from the cartridge. Backup units could also dump the saveram to a separate file. Different units have different headers which result in different file checksums, even though the ROM data is the same in all of them. 512 is the sector size of the 3.5 inch floppy disk. So if you don't have a backup unit, you don't need the copier header.

If I find a patch that needs a headered ROM, I add a header, apply the patch, then remove the header, then rename to .sfc. If you do remove the header, make sure the ROM has a different filename than the .ips so your emulator doesn't auto-patch the ROM again and cause corruption. The patched ROM should show up as checksum OK in some emulators because the authors fixed the internal checksum (I use ucon64 for this).

20
I think the problem is with how SNES LoROM mapping works. For this you need to use Lunar Address. SNES ROM memory addresses don't use xx:0000 - xx:7FFF. They go from xx:8000 - xx:FFFF.

Code: [Select]
   PC        SNES
0x000000 = $00:8000
0x008000 = $01:8000
0x010000 = $02:8000
0x018000 = $03:8000
0x020000 = $04:8000
...
0x080000 = $10:8000
0x087000 = $10:F000

So if you have data at $10:F000 - $10:FFFF, the next byte will be at 11:8000, not 11:0000.

The problem is probably that the data crosses banks. If you look at the copy routine, it doesn't change the bank value. To fix this, data must be less than $8000, and stored at the start of a bank.

A better way of doing it like KingMike said would be to use DMA. I think DMA can work across banks. I don't have any DMA code to share at the moment, but there's several documents on it like this one.

Pages: [1] 2 3