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

Author Topic: Recommended source control for a hack  (Read 3632 times)

PolishedTurd

  • Full Member
  • ***
  • Posts: 115
    • View Profile
Recommended source control for a hack
« on: March 02, 2018, 09:44:29 am »
In the past, I've relied on a loose system of copying my hacked ROM iteratively, giving it some kind of descriptive name to indicate the most recent changes I've made. It is not a reliable system. I would prefer to use a basic source control system, ideally one that could compare and show my changes in hexadecimal. Then I could see my own comments, alongside the actual changes, with an option to roll back a change I no longer want. Is there such a thing?

I have used Team Foundation Server and believe it would be overkill. I have some experience with Git as well. Online capability, multiple users and branching are not needed. Any recommendations?

Squall_FF8

  • Full Member
  • ***
  • Posts: 198
    • View Profile
Re: Recommended source control for a hack
« Reply #1 on: March 02, 2018, 11:02:25 am »
Hehe yes, Team Foundation Server is overkill  :laugh:

I would suggest use only free ones like Git, CVS, SVN. They are proven over years. Personally I don't know a system that compare hex value, sorry.

NaOH

  • Jr. Member
  • **
  • Posts: 23
  • Modernizing old games
    • View Profile
Re: Recommended source control for a hack
« Reply #2 on: March 13, 2018, 01:22:23 pm »
After getting frustrated with keeping copies of backups manually, I wrote a githook to make it easier. In the system I've put together, the hack itself is never stored, only the patch. The githook forces the patch to be up to date with the (not stored) hack; scripts are provided to make this very short work for the user.

Here's my cv1 repo: https://github.com/nstbayless/cv1-controls

Now, this works very well for a single user without worrying about merge conflicts. Unfortunately I haven't yet written hooks to handle merging the ips patch yet.

Gideon Zhi

  • IRC Staff
  • Hero Member
  • *****
  • Posts: 3455
    • View Profile
    • Aeon Genesis
Re: Recommended source control for a hack
« Reply #3 on: March 13, 2018, 02:30:12 pm »
This seems backwards. Wouldn't you rather be keeping track of a series of files relating to the hack which get applied via a build script, turning an untouched rom into the completed hack? In that fashion you have true source control and versioning, and are able to roll back code, not just patch versions.

NaOH

  • Jr. Member
  • **
  • Posts: 23
  • Modernizing old games
    • View Profile
Re: Recommended source control for a hack
« Reply #4 on: March 13, 2018, 04:56:07 pm »
This seems backwards. Wouldn't you rather be keeping track of a series of files relating to the hack which get applied via a build script, turning an untouched rom into the completed hack? In that fashion you have true source control and versioning, and are able to roll back code, not just patch versions.

That's exactly right. The ips patch is the file relating to the hack, and it gets applied to an untouched ROM.

When using FCEUX, the easiest workflow for editing the patch is just to edit the patched ROM directly and regenerate the patch.

Gideon Zhi

  • IRC Staff
  • Hero Member
  • *****
  • Posts: 3455
    • View Profile
    • Aeon Genesis
Re: Recommended source control for a hack
« Reply #5 on: March 13, 2018, 05:36:12 pm »
You misunderstand. What I'm talking about is a build script that would take individual hacks externally - assembly scripts, binaries containing graphic changes, and the like - then run them through the appropriate utilities.

For example, I have a batch file for The Great Battle which looks like this:

Code: [Select]
del gb1e.smc
copy gb1j.smc gb1e.smc

superfamiconv.exe tiles --in-image .\gb1j_title_orig.png --out-data .\title_gfx_e.bin --no-discard --no-flip --no-remap --bpp 8 --verbose
superfamiconv.exe tiles --in-image .\ending_1.png --out-data .\ending_gfx_e_1.bin --no-discard --no-flip --no-remap --bpp 8 --verbose
superfamiconv.exe tiles --in-image .\ending_2.png --out-data .\ending_gfx_e_2.bin --no-discard --no-flip --no-remap --bpp 8 --verbose

xkas make.asm gb1e.smc

atlas gb1e.smc in_dlog.txt > _dlog.log

make.asm looks like this:
Code: [Select]
lorom

org $188000
  padbyte $FF : pad $208000

org $008C36
  incbin title_spritemap.bin

org $188000
  incbin font.bin
  incbin chapter_title_font.bin
  incbin blank_tmap.bin
  incbin blank_tmap.bin
  incbin blank_tmap.bin
  incbin blank_tmap.bin
  incbin blank_tmap.bin
  incbin blank_tmap.bin
  incbin blank_tmap.bin

org $198000
  incbin title_gfx_j.bin
  incbin title_tmap_e.bin
org $198000
  incbin title_gfx_e.bin

...

  incsrc intro.asm
  incsrc dma.asm
  incsrc intro_expand.asm
  incsrc dlog_text_expand.asm
  incsrc text_speed.asm

And so on. This way all hacks are known, all are applied after every change, and all are easily changed/removed without any residue of earlier hacks causing potential issues. I never made an actual IPS patch until I was 100% done with the game. This is precisely the opposite of what you're suggesting, which is hardcoding all hacks directly into the ROM.

NaOH

  • Jr. Member
  • **
  • Posts: 23
  • Modernizing old games
    • View Profile
Re: Recommended source control for a hack
« Reply #6 on: March 13, 2018, 06:04:33 pm »
Fair enough. But in the build scheme you're suggesting, can't you just use git directly as is on the source files? (Possibly leaving the clean ROM out for space or copyright concerns, of course)

I may be mistaken but I believe the OP asked about tracking changes to the binary directly.

Gideon Zhi

  • IRC Staff
  • Hero Member
  • *****
  • Posts: 3455
    • View Profile
    • Aeon Genesis
Re: Recommended source control for a hack
« Reply #7 on: March 13, 2018, 06:19:14 pm »
Fair enough. But in the build scheme you're suggesting, can't you just use git directly as is on the source files? (Possibly leaving the clean ROM out for space or copyright concerns, of course)

Oh, absolutely. This is sort of the point. Hacking a rom directly in this manner isn't exactly good form, though I'll freely admit to being guilty of this in the past.

RedComet

  • Hero Member
  • *****
  • Posts: 3160
    • View Profile
    • Twilight Translations
Re: Recommended source control for a hack
« Reply #8 on: March 13, 2018, 07:04:17 pm »
I do the same as Gid: I have a build script in each repository that copies the unaltered ROM and applies all of the changes to it to create a new ROM. I track my source code with Git and use Bitbucket for hosting (free private repositories). This way I have 100% reproducible builds and 0 stress caused by juggling multiple binary back ups.  :beer:
Twilight Translations - More than just Dragonball Z. :P

PolishedTurd

  • Full Member
  • ***
  • Posts: 115
    • View Profile
Re: Recommended source control for a hack
« Reply #9 on: March 14, 2018, 11:06:33 am »
I was thinking something more like what NaOH mentions, but the discussion makes me more aware of shortcomings in my approach to hacking...

Generally, I find some free space to put my assembly code, shove the existing code around to make room for my page swap and/or JSR, then paste (or type!) my code in manually in a hex editor, directly editing my ROM full of cumulative changes. I come up with the code by writing the assembly by hand in a text editor, then consult the docs to manually convert the assembly instructions into opcodes and operands, one instruction at a time. Caveman style. Before long, I've got them memorized for the addressing modes I use most, but I'll freely admit the process is slow and backward. Humans should not compile code. It also does not allow me to do the kind of iterative build process Gideon and RedComet mention. And when there are bugs, what a drag it is to hunt them down.

I would love to manipulate code at a higher level, e.g. JSR #enemyCollision, STA #playerXCoord, etc. That would save me time and brain juice. It is a little off topic, but could someone recommend a good tool for programming more symbolically, and compiling to hex/binary from text input? Looks like Gideon uses xkas.

I'm guessing the make.asm example inserts the compiled binary code starting at the "org" address? Beautiful! That would make source control much cleaner and easier.

Gideon Zhi

  • IRC Staff
  • Hero Member
  • *****
  • Posts: 3455
    • View Profile
    • Aeon Genesis
Re: Recommended source control for a hack
« Reply #10 on: March 14, 2018, 12:32:56 pm »
I would love to manipulate code at a higher level, e.g. JSR #enemyCollision, STA #playerXCoord, etc. That would save me time and brain juice. It is a little off topic, but could someone recommend a good tool for programming more symbolically, and compiling to hex/binary from text input? Looks like Gideon uses xkas.

I'm guessing the make.asm example inserts the compiled binary code starting at the "org" address? Beautiful! That would make source control much cleaner and easier.

I use xkas for SNES stuff, but it isn't really suitable for the NES, at least not on a full-hack scale. Unfortunately I can't really recommend anything else.

make.asm is sort of the master insertion file. It inserts the binaries at the origin/org addresses specified (the incbins), but each of the asm source files (the incsrcs) has their own org addresses. intro_expand.asm looks like this:

Code: [Select]
lorom


;$00/92B1: A2 0C 16     LDX #$160C                A:0002 X:0002 Y:990E D:0000 DB:15 S:03F8 P:eNvMxdizc HC:940 VC:021
;$00/92B4: 86 1C        STX $1C [$00:001C]        A:0002 X:160C Y:990E D:0000 DB:15 S:03F8 P:envMxdizc HC:1004 VC:021
;$00/92B6: A0 00 00     LDY #$0000                A:0002 X:160C Y:990E D:0000 DB:15 S:03F8 P:envMxdizc HC:1076 VC:021
;$00/92B9: C2 20        REP #$20                  A:0002 X:160C Y:0000 D:0000 DB:15 S:03F8 P:envMxdiZc HC:1140 VC:021
;$00/92BB: A5 1C        LDA $1C [$00:001C]        A:0002 X:160C Y:0000 D:0000 DB:15 S:03F8 P:envmxdiZc HC:1202 VC:021
;$00/92BD: 18           CLC                       A:160C X:160C Y:0000 D:0000 DB:15 S:03F8 P:envmxdizc HC:1274 VC:021
;$00/92BE: 69 80 00     ADC #$0080                A:160C X:160C Y:0000 D:0000 DB:15 S:03F8 P:envmxdizc HC:1328 VC:021
;$00/92C1: 85 1C        STA $1C [$00:001C]        A:168C X:160C Y:0000 D:0000 DB:15 S:03F8 P:envmxdizc HC:1392 VC:021
;$00/92C3: E2 20        SEP #$20                  A:168C X:160C Y:0000 D:0000 DB:15 S:03F8 P:envmxdizc HC:096 VC:022
;$00/92C5: AA           TAX                       A:168C X:160C Y:0000 D:0000 DB:15 S:03F8 P:envMxdizc HC:158 VC:022
;$00/92C6: A9 00        LDA #$00                  A:168C X:168C Y:0000 D:0000 DB:15 S:03F8 P:envMxdizc HC:212 VC:022
;$00/92C8: EB           XBA                       A:1600 X:168C Y:0000 D:0000 DB:15 S:03F8 P:envMxdiZc HC:268 VC:022
;$00/92C9: A9 14        LDA #$14                  A:0016 X:168C Y:0000 D:0000 DB:15 S:03F8 P:envMxdizc HC:328 VC:022
;$00/92CB: 85 02        STA $02 [$00:0002]        A:0014 X:168C Y:0000 D:0000 DB:15 S:03F8 P:envMxdizc HC:384 VC:022

org $0092B1
  ;Tilemap start position
  LDX #$1584

org $0092C9
  ;line length limit
  LDA #$1D

I still don't really have a good way to (for instance) pass addresses for files that make incbins to other source files so some of this is still managed sort of by hand, but it's far and away better than hardcoding everything into the hacked rom.

Edit: To further elaborate, here's another example (texthack.asm from GB5, incsrc'd from GB5's make.asm) This does what you mentioned with finding free space for new code, inserting hooks, and so on. Not the most efficient code but it got the job done and I was pressed for time.
Code: [Select]
lorom


;$8F/AB6A: BD 00 00     LDA $0000,X [$8F:A1E9]    A:0000 X:A1E9 Y:9F2D D:0000 DB:8F S:01BA P:eNvmxdizc HC:628 VC:108
;$8F/AB6D: E8           INX                       A:01BE X:A1E9 Y:9F2D D:0000 DB:8F S:01BA P:envmxdizc HC:708 VC:108
;$8F/AB6E: DA           PHX                       A:01BE X:A1EA Y:9F2D D:0000 DB:8F S:01BA P:eNvmxdizc HC:762 VC:108
;$8F/AB6F: 0A           ASL A                     A:01BE X:A1EA Y:9F2D D:0000 DB:8F S:01B8 P:eNvmxdizc HC:832 VC:108
;$8F/AB70: AA           TAX                       A:037C X:A1EA Y:9F2D D:0000 DB:8F S:01B8 P:envmxdizc HC:886 VC:108
;$8F/AB71: E2 20        SEP #$20                  A:037C X:037C Y:9F2D D:0000 DB:8F S:01B8 P:envmxdizc HC:940 VC:108

org $8FAB6A
  JMP $FC00

;$8F/AB73: A9 99        LDA #$99                  A:037C X:037C Y:9F2D D:0000 DB:8F S:01B8 P:envMxdizc HC:1002 VC:108
;$8F/AB75: 48           PHA                       A:0399 X:037C Y:9F2D D:0000 DB:8F S:01B8 P:eNvMxdizc HC:1058 VC:108
;$8F/AB76: AB           PLB                       A:0399 X:037C Y:9F2D D:0000 DB:8F S:01B7 P:eNvMxdizc HC:1120 VC:108
;$8F/AB77: BC 2C 99     LDY $992C,X [$99:9CA8]    A:0399 X:037C Y:9F2D D:0000 DB:99 S:01B8 P:eNvMxdizc HC:1188 VC:108
;$8F/AB7A: A9 99        LDA #$99                  A:0399 X:037C Y:D87C D:0000 DB:99 S:01B8 P:eNvMxdizc HC:1268 VC:108
;$8F/AB7C: BC 2C 99     LDY $992C,X [$99:9CA8]    A:0399 X:037C Y:D87C D:0000 DB:99 S:01B8 P:eNvMxdizc HC:1324 VC:108
;$8F/AB7F: 22 73 94 81  JSL $819473 [$81:9473]    A:0399 X:037C Y:D87C D:0000 DB:99 S:01B8 P:eNvMxdizc HC:1404 VC:108

org $8FAB73
  LDA #$B0
  PHA
  PLB
  LDY $8000,X
  LDA #$B0
  LDY $8000,X


org $8FFC00
PointerHack1:
  LDA $0000,X
  INX
  PHX
  PHA
  ASL A
  CLC
  ADC $01,s
  TAX
  PLA
 
  SEP #$20
  LDA #$B0
  PHA
  PLB
 
  LDY $8000,X
  LDA $8002,X
  JMP $AB7F

PointerHack2:
  REP #$20

  LDA $1BD8
  LSR A
  PHA
  ASL A
  ADC $01,s
  TAX
  PLA

  SEP #$20
 
  LDA #$B0
  PHA
  PLB
 
  LDY $8000,X
  LDA $8002,X
  JML $819A49

PointerHack3:
  LDA #$B0
  PHA
  PLB

  REP #$20
  TXA
  LSR A
  PHA
  ASL A
  CLC
  ADC $01,s
  TAX
  PLA
  SEP #$20
  LDY $8000,X
  LDA $8002,X
  JML $8CA4F0
 
PointerHack4:
  REP #$20

  LDA $1BD8
  LSR A
  PHA
  ASL A
  ADC $01,s
  TAX
  PLA

  SEP #$20
 
  LDA #$B0
  PHA
  PLB
 
  LDY $8000,X
  LDA $8002,X
  JML $819A27


PointerHack5:
  LDA #$B0
  PHA
  PLB

  REP #$20
  TXA
  LSR A
  PHA
  ASL A
  CLC
  ADC $01,s
  TAX
  PLA
  SEP #$20
  LDY $8000,X
  LDA $8002,X
  JML $8F9493
 
;$81/9A41: A9 99        LDA #$99                  A:0000 X:0021 Y:0021 D:0000 DB:99 S:01B9 P:envMxdiZc HC:418 VC:161
;$81/9A43: AE D8 1B     LDX $1BD8 [$99:1BD8]      A:0099 X:0021 Y:0021 D:0000 DB:99 S:01B9 P:eNvMxdizc HC:474 VC:161
;$81/9A46: BC 2C 99     LDY $992C,X [$99:9B46]    A:0099 X:021A Y:0021 D:0000 DB:99 S:01B9 P:envMxdizc HC:554 VC:161
;$81/9A49: 22 73 94 81  JSL $819473 [$81:9473]    A:0099 X:021A Y:C10E D:0000 DB:99 S:01B9 P:eNvMxdizc HC:634 VC:161
org $819A41
  JML PointerHack2


;$8C/A4E9: A9 99        LDA #$99                  A:1900 X:0322 Y:124A D:0000 DB:82 S:01BC P:envMxdizC HC:1368 VC:085
;$8C/A4EB: 48           PHA                       A:1999 X:0322 Y:124A D:0000 DB:82 S:01BC P:eNvMxdizC HC:056 VC:086
;$8C/A4EC: AB           PLB                       A:1999 X:0322 Y:124A D:0000 DB:82 S:01BB P:eNvMxdizC HC:118 VC:086
;$8C/A4ED: BC 2C 99     LDY $992C,X [$99:9C4E]    A:1999 X:0322 Y:124A D:0000 DB:99 S:01BC P:eNvMxdizC HC:186 VC:086
;$8C/A4F0: 22 73 94 81  JSL $819473 [$81:9473]    A:1999 X:0322 Y:D61C D:0000 DB:99 S:01BC P:eNvMxdizC HC:266 VC:086
org $8CA4E9
  JML PointerHack3

;$81/9A1F: A9 99        LDA #$99                  A:00F8 X:0023 Y:0023 D:0000 DB:99 S:01B9 P:envMxdizc HC:858 VC:154
;$81/9A21: AE D8 1B     LDX $1BD8 [$99:1BD8]      A:0099 X:0023 Y:0023 D:0000 DB:99 S:01B9 P:eNvMxdizc HC:914 VC:154
;$81/9A24: BC 2C 99     LDY $992C,X [$99:9B62]    A:0099 X:0236 Y:0023 D:0000 DB:99 S:01B9 P:envMxdizc HC:994 VC:154
;$81/9A27: 22 73 94 81  JSL $819473 [$81:9473]    A:0099 X:0236 Y:C248 D:0000 DB:99 S:01B9 P:eNvMxdizc HC:1074 VC:154
org $819A1F
  JML PointerHack4


;$8F/948C: A9 99        LDA #$99                  A:0314 X:0314 Y:0008 D:0000 DB:82 S:01BB P:envMxdizc HC:368 VC:233
;$8F/948E: 48           PHA                       A:0399 X:0314 Y:0008 D:0000 DB:82 S:01BB P:eNvMxdizc HC:424 VC:233
;$8F/948F: AB           PLB                       A:0399 X:0314 Y:0008 D:0000 DB:82 S:01BA P:eNvMxdizc HC:486 VC:233
;$8F/9490: BC 2C 99     LDY $992C,X [$99:9C40]    A:0399 X:0314 Y:0008 D:0000 DB:99 S:01BB P:eNvMxdizc HC:554 VC:233
;$8F/9493: 22 73 94 81  JSL $819473 [$81:9473]    A:0399 X:0314 Y:D529 D:0000 DB:99 S:01BB P:eNvMxdizc HC:634 VC:233
org $8F948C
  JML PointerHack5

;palette for main dialog
org $8EE103
  db #$FF,#$FF,#$4A,#$29
« Last Edit: March 14, 2018, 12:51:11 pm by Gideon Zhi »

Squall_FF8

  • Full Member
  • ***
  • Posts: 198
    • View Profile
Re: Recommended source control for a hack
« Reply #11 on: March 15, 2018, 05:06:43 am »
I was thinking something more like what NaOH mentions, but the discussion makes me more aware of shortcomings in my approach to hacking...
I would love to manipulate code at a higher level, e.g. JSR #enemyCollision, STA #playerXCoord, etc. That would save me time and brain juice. It is a little off topic, but could someone recommend a good tool for programming more symbolically, and compiling to hex/binary from text input? Looks like Gideon uses xkas.
That's the right way of thinking! What you need is a macro-assembler. It allows you to type command mnemonics rather their hex value, it free your mind from trivial things like do I need A9 or AB for this instructions. It pretty much allows you to strip all the extra things you must do when using hex.

Giving meaningful name to addresses is only part of the fun. Calculating/recalculating brunch offsets is the other advantage of assemblers. Probably the biggest advantage is ability to write macros - grouping number of instruction in a logical block and giving it meaningful name. Here is an example of loading palette trough DMA (macro with params):
Code: [Select]
;macro for loading palette data into the CGRAM
 ;only use if SIZE is less than 256 bytes
 ;syntax SetPalette LABEL CGRAM_ADDRESS SIZE
 .macro SetPalette
 pha
 php
 
 rep #$20 ; 16bit A
 lda #\3
 sta $4305 ; # of bytes to be copied
 lda #\1 ; offset of data into 4302, 4303
 sta $4302
 sep #$20 ; 8bit A
 
 lda #:\1 ; bank address of data in memory(ROM)
 sta $4304
 lda #\2
 sta $2121 ; address of CGRAM to start copying graphics to
 
 stz $4300 ; 0= 1 byte increment (not a word!)
 lda #$22
 sta $4301 ; destination 21xx   this is 2122 (CGRAM Gate)
 
 lda #$01 ; turn on bit 1 (corresponds to channel 0) of DMA channel reg.
 sta $420b ;   to enable transfer
 
 plp
 pla .endm

That example is written in WLA-DX. Other macro-assemblers are ca65, bass, xcas,...

NaOH

  • Jr. Member
  • **
  • Posts: 23
  • Modernizing old games
    • View Profile
Re: Recommended source control for a hack
« Reply #12 on: March 15, 2018, 06:00:41 pm »
This is really cool. What's a good way to get an assembler to insert chunks of code into the ROM at specified points? Is this a common feature? I imagine it's rather unique to hacking.

RedComet

  • Hero Member
  • *****
  • Posts: 3160
    • View Profile
    • Twilight Translations
Re: Recommended source control for a hack
« Reply #13 on: March 16, 2018, 12:09:11 am »
This is really cool. What's a good way to get an assembler to insert chunks of code into the ROM at specified points? Is this a common feature? I imagine it's rather unique to hacking.

xkas is the only available cross assembler that supports this for 65816. I've never used it for 6502 work. I honestly don't remember what assembler I used for 6502 work. I think it was some combination of WLA-DX plus some custom tooling to insert the assembled code. :-\

I wrote my own assembler for 68k (Sega Genesis/Mega Drive, etc) years ago, but in recent times, I've been using off the shelf assemblers and some custom python scripts to parse some of the assembler's output files and insert the changes where they're expected. If I ever get back around to doing NES work, I'll probably implement a similar solution.

The successful romhacker's toolkit is full of hopes, dreams, a little duct tape and blind luck.  :thumbsup:
Twilight Translations - More than just Dragonball Z. :P

NaOH

  • Jr. Member
  • **
  • Posts: 23
  • Modernizing old games
    • View Profile
Re: Recommended source control for a hack
« Reply #14 on: March 16, 2018, 12:14:50 am »
The successful romhacker's toolkit is full of hopes, dreams, a little duct tape and blind luck.  :thumbsup:

It's as I feared. I guess I'll have to cobble something together. Thanks!

Squall_FF8

  • Full Member
  • ***
  • Posts: 198
    • View Profile
Re: Recommended source control for a hack
« Reply #15 on: March 16, 2018, 04:09:59 am »
Quote
xkas is the only available cross assembler that supports this for 65816.
Nor really. WLA-DX supports multi processor/platform code compilation. 6502, Z80, SPC-700 are some of the processors it maintain while keeping syntax intact. The only exception are platform specific directives like .LoROM/.HiROM/.bank created specifically for SNES. Pretty much except platform specific directives (and the mnemonics of the used assembly language ofc) you continue to work the same way - in your case insert hack changes.

jonk

  • Sr. Member
  • ****
  • Posts: 269
    • View Profile
Re: Recommended source control for a hack
« Reply #16 on: July 06, 2018, 11:35:54 pm »
My son has been doing patches and the easiest way I found to give him exactly what he wanted was to just find existing source code and modify it. This I did and the results are here: Modifying an assembler to directly patch ROMs. It might be worth a short read. I pulled together the documentation pages pretty quickly, mostly to just get something down on paper so to speak, and I'm fairly sure it could be greatly improved with some more effort. (Perhaps I'll do that later on this year.) Let me know if you have specific questions.

The basic idea is that code sections are named and you can move these named sections around in the ROM space wherever they need to be placed. The code sections can be addressed to the exact same addresses, if you want, for cases where sections of a ROM are enabled and mapped to the same address. So it handles those kinds of things as well. It's a full symbolic assembler and linker (which I did not write) that was leveraged by me to add a few new capabilities.

Nothing big, but it shows you what can be achieved with a few modifications to existing assembler and linker tools.
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

NaOH

  • Jr. Member
  • **
  • Posts: 23
  • Modernizing old games
    • View Profile
Re: Recommended source control for a hack
« Reply #17 on: July 08, 2018, 02:32:31 am »
The basic idea is that code sections are named and you can move these named sections around in the ROM space wherever they need to be placed.

Oh, this is exactly what I wanted. That's incredible. Does it work for NES or just SNES?

jonk

  • Sr. Member
  • ****
  • Posts: 269
    • View Profile
Re: Recommended source control for a hack
« Reply #18 on: July 11, 2018, 12:38:08 am »
Oh, this is exactly what I wanted. That's incredible. Does it work for NES or just SNES?
It works for both. The assembler handles both 6502 and 65816 opcodes as I recall. And my modifications handle ROMs that have different banks that are brought into visibility, as well.
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

optiroc

  • Jr. Member
  • **
  • Posts: 41
    • View Profile
Re: Recommended source control for a hack
« Reply #19 on: July 21, 2018, 04:46:37 pm »
Here's the repository for the Super Famicom Wars translation, if anyone's interested: SuperFamicomWars-Translation

It contains all tools needed to build the final ROM and patches from source, something I usually find myself doing for these things with a pretty low number of small tool dependencies.

Most patching code is generated from python using a little library that generates data/code insertion assembly, with the freedom to specify absolute addresses, free placement within a bank, or completely free placement anywhere I've marked as free space. Graphic assets are generated from PNG files as part of the make script.