Final Fantasy II Restored

[redmagejoe]

I am certainly using the Chaos Rush translation, which I have an unofficial v1.8 for (went through and fixed up typos, but he's retired from ROM hacking, and standards prevents me from updating his rather than as an addendum). I believe abw said his disassembly is based on the original JP ROM though.

[Cyneprepou4uk]

a usable disassembler available that works with CDLs and is also mapper aware

IDA 5.2 can do it if you have scripts for it.

So while you at it, can you record a video of how you make a disassembly from scratch?

[Disch]

I am certainly using the Chaos Rush translation, which I have an unofficial v1.8 for

Hrm.  Any chance I could get that translation patch off you?  (without any of the other fixes you made in this thread) --- assuming there's no distribution issues.  Is Chaos Rush OK with that version being passed around?  I feel like that would be the most preferable starting point.

Either that or I could use the 1.7 patch hosted on RHDN.  But getting the latest version possible seems like a better idea.  I really don't want to use the original Japanese ROM -- I don't think the target audience here is likely to use that version.

IDA 5.2 can do it if you have scripts for it.

Oooo, neat.  I figured someone must have done something like this already.  However I don't know if I can go this route.

The big problem with IDA is that it's not free.  That's kind of a deal breaker for me.  Also it's kind of a huge dependency for something a few python scripts could do.  Kind of like using a sledgehammer to drive a nail.

So while you at it, can you record a video of how you make a disassembly from scratch?

I mean, I'm probably just going to write some python to do the bulk of it.  I'm going to try to make something that's a bit extensible so that it can be reused for other games... but once I get the basic program done you'll be able to just run it to get a ~70% functional disassembly of whatever.

I say ~70% because I can't think of a good way to reliably automate replacing indirect memory accesses with proper labels.  And without that, you won't really be able to "move code around" without breaking everything.  So I'm still going to have to go through the disassembly by hand and look for all those and tweak them manually.  But that's not [usually] particularly difficult, it's just tedious.

For example, there might be code like this in the disassembly:

Code Select Expand


LDA #$20
STA $10
LDA #$80
STA $11
LDA ($10),Y


It's obvious to a human, but it's really hard to get a disassembler smart enough to realize that SHOULD be disassembled to this:

Code Select Expand


LDA #<Label_8020
STA $10
LDA #>Label_8020
STA $11
LDA ($10),Y


Especially when there is a gap between where the pointer is set and where it's used.  And Indirect JMPs are even worse, as those pointers are usually pulled from a LUT.

There are probably one or two more other things that'll have to be done manually, too.

[Cyneprepou4uk]

The big problem with IDA is that it's not free

Ghidra is free if that's your concern. But I don't know much about it. I think I saw some projects on GitHub like this one. You take it from here.

[redmagejoe]

I haven't distributed it or tried to upload it as an addendum because I didn't get any feedback from Chaos Rush one way or another. I reached out to him, but the only response I got was "I don't do ROM hacking any more". I don't want to make it widely available unless I ascertain his feelings on the matter, but I can PM you v1.8. It still has a minor issue that 1.7 does with spell names using DTE to be more clear, but he expanded some of them to 5 characters instead of 4. This causes spell levels in combat above 9 to get pushed outside the bounds of the display box. So Thunder 10 becomes |Thunder 1|. I don't know how to fix that though.

Also, I am going to be taking a VERY brief hiatus on this project (less than a week) while I focus on a work project. I feel like I'm at a good stopping point with nothing up in the air other than the Evasion/MDef thing, so I'll get right back to it once I finish my obligations.

[abw]

I dunno if there's a usable disassembler available that works with CDLs and is also mapper aware, though, so I'll probably have to just whip something up in Python (which, IIRC, is what I did for FF1).


I hope you're not too offended, but I think it would actually be significantly easier for me to build a new disassembly from scratch than it would be to try to build off of what you have.     And in the process I might be able to make an actually re-usable disassembler.

One of my pet projects has been a NES disassembler that leverages a CDL file to provide (with many caveats) code/data separation, detects and labels intra-bank absolute and indexed control flow and data load targets, and utilizes a separate file to augment that with various other information such as assumptions for unknown bytes, targeting info for inter-bank operations and indirect jump/pointer tables, comments for blocks and lines of code/data, etc. with the end goal being the generation of a fully labelled and commented re-assemblable disassembly. Most of the time it works out pretty well, but there are some annoying edge cases to deal with, and in practice I've been more interested in the intermediate results I'm getting than in the final product, so re-assemblable output is still WIP.

That said, I guess I ought to post the re-assemblable version of what I've got. There are plenty of missing labels, so use with caution.

In any case, I am totally fine with having an another option available (especially if it's better than mine!), so go right ahead .

Just to verify, after skimming the thread it looks like everyone here is using the Chaos Rush translation.  Is that correct?

Is that what the CDL is built on, too?

The CDL file found on the internet was for the Japanese ROM (MD5: 374ED97BE8BFD628F6B359A720549ECD), so that's what I've been working from. If the translation also touches mechanics or uses any of the free space, there could be conflicts with the fixes made in this thread, but so far we've haven't done anything specifically related to text, so I'm thinking these patches should be widely compatible with translations.

For example, there might be code like this in the disassembly:

Yeah, automatic labelling is hard. Here's an actual expanded example from FF2:

Code Select Expand


; call $0C:$8F49
; external control flow target (from $0B:$9645)
0x03FB27|$0F:$FB17:A9 49    LDA #$49    ; $0C:$8F49
0x03FB29|$0F:$FB19:D0 16    BNE $FB31 
; call $0C:$8F4C
; external control flow target (from $05:$A14E, $05:$A52A, $05:$A745, $05:$A7B8)
0x03FB2B|$0F:$FB1B:A9 4C    LDA #$4C    ; $0C:$8F4C
0x03FB2D|$0F:$FB1D:D0 12    BNE $FB31 
; call $0C:$8F4F
; external control flow target (from $05:$9FBD, $05:$A0F7, $05:$A13A, $05:$A413)
0x03FB2F|$0F:$FB1F:A9 4F    LDA #$4F    ; $0C:$8F4F
0x03FB31|$0F:$FB21:D0 0E    BNE $FB31 
; call $0C:$8F52
; external control flow target (from $05:$A54A)
0x03FB33|$0F:$FB23:A9 52    LDA #$52    ; $0C:$8F52
0x03FB35|$0F:$FB25:D0 0A    BNE $FB31 
; call $0C:$8F55
; external control flow target (from $05:$A4E7)
0x03FB37|$0F:$FB27:A9 55    LDA #$55    ; $0C:$8F55
0x03FB39|$0F:$FB29:D0 06    BNE $FB31 
; call $0C:$8F58
0x03FB3B|$0F:$FB2B:A9 58    LDA #$58    ; $0C:$8F58
0x03FB3D|$0F:$FB2D:D0 02    BNE $FB31 
; call $0C:$8F5B
; external control flow target (from $05:$A1CD, $05:$A3E3)
0x03FB3F|$0F:$FB2F:A9 5B    LDA #$5B    ; $0C:$8F5B
; control flow target (from $FB19, $FB1D, $FB21, $FB25, $FB29, $FB2D)
0x03FB41|$0F:$FB31:85 40    STA $40   
0x03FB43|$0F:$FB33:A9 8F    LDA #$8F   
0x03FB45|$0F:$FB35:85 41    STA $41   
0x03FB47|$0F:$FB37:A9 0C    LDA #$0C   
0x03FB49|$0F:$FB39:4C 88 FA JMP $FA88  ; swap in PRG bank in A, saving $3E to $3F and A to $3E, then JSR ($0040)

On the bright side, MMC1 is a pretty simple mapper, so probably the RAM addresses and targetting info (what there is of it, at least) are all correct.

[Disch]

One of my pet projects has been a NES disassembler that leverages a CDL file to provide (with many caveats) [a ton of stuff]

Yeah this is sort of like the holy grail.  Though I'm dubious as to how much of it can be reasonably automated reliably.  I think a reasonable goal (at least at the start) would be something that can be reassembled out of the box, but with the caveat that if you add/remove bytes and move data around, some stuff might break.

A heavy duty static analysis tool like IDA/Ghidra might be able to do a better job of this, but I just spent the past hour looking over docs and tutorials of how to create a custom loader for Ghidra and it's not exactly straightforward.  I'm probably going to stick with my idea of just doing something custom in Python.

That said, I guess I ought to post the re-assemblable version of what I've got. There are plenty of missing labels, so use with caution.  [snip]  The CDL file found on the internet was for the Japanese ROM (MD5: 374ED97BE8BFD628F6B359A720549ECD), so that's what I've been working from.

Nice!  I like some of your ideas here, like adding a line to tell what parts of the code are jumping to each label.  Also, did you automatically detect the PRG swapping routine or did you add those notes manually?

I suppose if you're working with the J Rom and I'm working with the Chaos Rush translation, then I'm not COMPLETELY duplicating your work   .  I'm torn between really wanting to do this because it's fun, but also recognizing that I'd be redoing a lot of stuff that you've done already.

Maybe instead of FF2, I should work on FF3?  Though I'd still be duplicating the work on the disassembler...


... or maybe I can do some kind of automated CDL generator?  That'd be something new.

I haven't distributed it or tried to upload it as an addendum because I didn't get any feedback from Chaos Rush one way or another.

Thanks, but if you're not comfortable handing it out publicly, then neither am I.  I'll stick to using the 1.7 release... if I continue with the FF2 idea at all.

[abw]

Also, I am going to be taking a VERY brief hiatus on this project (less than a week) while I focus on a work project.

Yeah, this is the first day in a couple of weeks where there have been fewer than a dozen posts in this thread .

I think a reasonable goal (at least at the start) would be something that can be reassembled out of the box, but with the caveat that if you add/remove bytes and move data around, some stuff might break.

Assuming my disassembler works at all*, I've got that part done.

*: FCEUX's CDL format leaves a couple of things to be desired (e.g. it assumes 4 RAM slots regardless of what the mapper actually does, it would be great to log info about code/data accesses from code running in NES or cartridge RAM, etc.), and some mappers are tricky.

• As an example, I was running into issues with Crystalis (an MMC3 game with $2000 bank size) where bank $12 gets loaded into $8000-$9FFF and bank $13 gets loaded into $A000-$BFFF, but there's a STA $04 that crosses the bank boundary and screws everything up.
• ROM banks that get loaded into multiple RAM banks are also problematic.
• I'm not sure what the right way is to label things like LDA $8000,X in a $C000-$FFFF fixed bank where that legitimately refers to any of several banks potentially loaded into $8000.
• Similarly, I'm not sure how to handle labelling bytes that get chopped up into a pointer, e.g. the high 3 bits select the bank and the low 5 bits select the N'th pointer in a pointer table in the selected bank, especially when there's extra math and conditional logic involved. Probably I'll just define those as a constant or something.
• Sometimes code also gets logged as data (e.g. checksums, RNG reading from random addresses, list scanning routines going way beyond their data) and sometimes data is actually code (e.g. bytes get copied to RAM and then executed).
• Anything that gets executed in RAM will require much better static analysis!

It's far enough along to not completely suck, but basically it's still a WIP project.

Nice!  I like some of your ideas here, like adding a line to tell what parts of the code are jumping to each label.

I really like knowing what's going on with the control flow when mucking about with ASM changes. Without that, it's too easy to look at a bunch of code and say "oh, I can make this little change and everything will be awesome" only to find out that some other code is branching into the middle of your changes and crashing the system .

Also, did you automatically detect the PRG swapping routine or did you add those notes manually?

I guess it wouldn't be too hard to pick out swap routines automatically, but at the moment I'm just identifying those manually. My setup involves an extra file that augments the CDL with assumptions for unknown bytes (e.g. byte X is code even though it wasn't logged as code), targeting info for inter-bank/calculated/partial pointers, all the other comments (one fun thing is that I can have comments act a bit like labels, e.g. add a comment on a routine and have the comment appear inline on all calls to the routine; they can also be transitive on pointers, e.g. when $8000 is a pointer to $9ABC and $9ABC has a comment-label, the comment appears on $8000 and anything that points to $8000), and formatting info for data tables.

I suppose if you're working with the J Rom and I'm working with the Chaos Rush translation, then I'm not COMPLETELY duplicating your work   .  I'm torn between really wanting to do this because it's fun, but also recognizing that I'd be redoing a lot of stuff that you've done already.

Maybe instead of FF2, I should work on FF3?  Though I'd still be duplicating the work on the disassembler...


... or maybe I can do some kind of automated CDL generator?  That'd be something new.

Dealer's choice here . Do you have any idea what the breakdown of work for your FF1 disassembly was?

[Cyneprepou4uk]

Without that, it's too easy to look at a bunch of code and say "oh, I can make this little change and everything will be awesome" only to find out that some other code is branching into the middle of your changes and crashing the system

Oh please, you are exaggerating. In most cases it's enough to scroll debugger up/down a few pages looking for nearby jumps and branches. And even if the worst does happen, this issues can be located very easy.

Talking about a skillful romhacker of course, with a bunch of backups 

[Disch]

abw:  I started a new thread since we're pretty far off of topic with regard to redmagejoe's project.

http://www.romhacking.net/forum/index.php?topic=29943.0

[CoolCatBomberMan]

I'm not sure how relevant this is, but Hironobu Sakaguchi explained why the Ultima bug is a thing: when he first discovered it, he wanted the bug fixed, but some jerk programmer said no, because the bug reflected how legendary weapons/items in real life rarely live up to their own hype. Then, he ciphered the bug, so Sakaguchi couldn't fix it himself. So, here's to hoping you don't have too much trouble fixing Ultima.

[redmagejoe]

I'm not sure how relevant this is, but Hironobu Sakaguchi explained why the Ultima bug is a thing: when he first discovered it, he wanted the bug fixed, but some jerk programmer said no, because the bug reflected how legendary weapons/items in real life rarely live up to their own hype. Then, he ciphered the bug, so Sakaguchi couldn't fix it himself. So, here's to hoping you don't have too much trouble fixing Ultima.

Still working on my work project, but thought I'd pop in to say that, given that Ultima behaves the way Sakaguchi wanted it to in the remake, and knowing that was his original intent, it is definitely a priority to attempt to make it work in this version. Perhaps that will be our Final Challenge.

I went and looked into this, and it was the source code that was ciphered apparently. Fortunately we're reverse-engineering it, so I'm not sure it would be an issue, though if by "source code" it means the assembly which we're turning the binary back into... Then yeah, we may have trouble. Hopefully we can make sense of most of the rest of the disassembly such that the only things left by the time we get to it must, by process of elimination, be related to Ultima.

[Chaos Rush]

I still lurk on RHDN because I like reading about programming stuff so I thought I'd give a response to something that is related to me.

I haven't distributed it or tried to upload it as an addendum because I didn't get any feedback from Chaos Rush one way or another. I reached out to him, but the only response I got was "I don't do ROM hacking any more".

Well to be fair, you didn't say upfront what you wanted to do, and once you did you left the chatroom before I was able to give a proper response, preventing me from giving a proper reply (since apparently Discord only lets you message people that you share a chatroom with). (EDIT: it was before I saw that you PM'd me here too)

Anyways if you want to make a v1.8, go ahead. I thought I made it rather clear in my last post in the FF NES trilogy translations thread that I'm "passing it on" to the community and people can update it from there, though I apologize if that wasn't made clear. Though I'm not sure if RHDN's system allows owner transfership of projects, if not then you would have to post it as an addendum (I think).

But also I want to say, around the time I said that I'm done with working on those projects, some people harassed me on Discord with questions like:

"Are you going to release the source code for your tools?"

"So you're never going to translate the Wonderswan versions of FF then?"

I want to say, I appreciate people's support for my past projects, but I also wish people could understand that I'm not obligated to work on them until perfection, nor am I obligated to work on projects I never even started to begin with (despite expressing interest in the past to do it - such as a hypothetical translation of Wonderswan FF1). I don't want to be held a slave to projects that I simply don't want to work on anymore.

Also I understand that my text editors might be useful but for personal reasons I don't wish to release the source code (and I no longer have access to the older ones anyways since they were on my old laptop which I no longer have access to).

At this point I want to devote my creative energies fully to my own game that I'm working on, and I am confident that if I work hard on it that it can be successful. There's a good reason why you don't see former ROM hackers like the Undertale dev or the Sonic Mania devs returning to ROM hacking (I'm not gonna state why I think at this time but I will say it's related to ethics).

So yes, feel free to update any of my old projects. However, I will not -cannot- update any of my old text editors, and I hope the community can respect my decision regarding that. I am done with ROM hacking.

EDIT: One more thing I want to add, my FF2 translation was the first one I did, so it's also the least polished under the hood. It used the Demiforce translation as an "engine" (since it already contained DTE code and re-arranged the in-game special terms menu), but redid all of the text. There may or may not be some changes unaccounted for, and also unused data from the Demiforce title screen (which I used a patch to remove), and also just data offsets shifts of various tables to increase space. If you're making a disassembly, I think you should work with the Japanese version and just make a new English version from there - and as stated before I'm okay with you guys using/updating the script from my FF2 translation.

[Disch]

Thanks for chiming in, ChaosRush!   

Anyways if you want to make a v1.8, go ahead.

Great!  Thanks.  I'll keep that in mind if/when I get around to actually making a new disassembly.

but I also wish people could understand that I'm not obligated to work on them until perfection, nor am I obligated to work on projects I never even started to begin with

I came to the same conclusion long ago.  What makes these projects fun for me is that I can work on them as much or as little as I want without the pressure of expectations.  If you are working under a deadline, it is no longer a hobby, it's a job -- but one that you're not getting paid for.

If you're making a disassembly, I think you should work with the Japanese version and just make a new English version from there

Ehhhhh, gonna disagree with you there.

I'm sure you're aware that "just make[ing] a new English version" is a very large undertaking.  And suggesting people who want to make a hack of this game, no matter how small, should completely retranslate the whole thing is completely unrealistic.

The only people a disassembly of the J ROM would be useful to would be the Japanese hacking community (who I'm not targeting) and people looking to retranslate a game that already has several serviceable translations.  Which I'm not opposed to, but doesn't strike me as a very large audience.  It would be next to useless for hackers looking to make other modifications to the game -- as they're almost certainly going to be using an English translation as a base.

[redmagejoe]

Thank you for weighing in on the matter, Chaos Rush. I completely understand and respect your desire to move on, and thank you for entrusting your legacy to us, the community. 

I have attempted once more, now with Chaos Rush's own words as evidence, to submit v1.8 to the site. The previous reason I was given involved getting direct consent from Chaos Rush, which I believe his post gives. That said, if anyone wishes to make a new side-project of dissecting his patch and "polishing it up" as he says, condensing space used, cleaning up anything else that may have changed not critical to the script itself, and maybe helping figure out the spell name DTE and its use of 5 characters instead of 4 (thus causing spell levels above 9 to be pushed outside the box in combat), then I strongly encourage it.

At this time, I cannot give that top priority as I try to work out the base game mechanic bugs. That said, if no one wishes to take up that gauntlet by the time this project nears completion, then I will definitely add that to my to-do list. I would like to have the Restored patch function off the JP ROM, with Chaos Rush's v2.0 being the recommended English patch to pair with it.

[Special]

If RMJ wants to update this to 1.8 or whatever then it should just be an addendum and not a replacement for Chaos Rush's work, so what's the issue?

[redmagejoe]

• Tested: Stats cannot go above 99 with stat-raising equipment in the Anniversary Edition. Cap stats at 99 no matter what for this patch.
• Tested: Stats can stack bonuses from multiple equipment in the remakes. Giant's Helm + Power Sash + Giant's Glove will yield +30 Strength in the remake. Try to implement this behavior into this patch.

Had some downtime, so thought I'd try to find the area relevant to a seemingly simple fix, and wow, how easy it was to track down stat bonuses from equipment. All I did was Ctrl+F ADC #$0A (+10), and behold, it's literally the only Add Carry of 10 in the entire code. Sure enough, I changed it to $14 (+20) and all equipment gave +20 instead of +10. So the routine at 0x003F23 handles stat bonuses from equipment. Should be easy to figure out how to apply these two fixes. It's just a matter of utilizing space effectively. Don't forget that we're currently using the following spaces. Or I'll work on it when I finish my work project.

Code Select Expand


0x013B33: 221
0x013D5D: 689
0x015D77: 409
0x03400D: 3
0x0387CB: 69
0x03F75E: 178
0x03F83B: 21

... Fixed bank below, can't use above addresses

0x03F858: 184 <- 39/184 used by my combat counter fix
0x03FEFC: 196
0x03FFCD: 3
0x03FFDD: 19  <- abw's RNG WIP uses 12/19


EDIT: Also, v1.8of Chaos Rush's translation is now available on its usual page, as the submission was accepted! 

[abw]

Still working on my work project, but thought I'd pop in to say that, given that Ultima behaves the way Sakaguchi wanted it to in the remake, and knowing that was his original intent, it is definitely a priority to attempt to make it work in this version. Perhaps that will be our Final Challenge.

I appreciate your restraint in not calling it our ULTIMAte challenge . Sounds like it should be fun when we get to it!

Ehhhhh, gonna disagree with you there.

[...]

The only people a disassembly of the J ROM would be useful to would be the Japanese hacking community (who I'm not targeting) and people looking to retranslate a game that already has several serviceable translations.  Which I'm not opposed to, but doesn't strike me as a very large audience.  It would be next to useless for hackers looking to make other modifications to the game -- as they're almost certainly going to be using an English translation as a base.

As a counter-point, translations come and go, but the base ROM is forever. Look at the number of Final Fantasy VI translations, for instance; I would argue that a disassembly of any one of them is generally less useful than a disassembly of the original ROM would be.

How's this for an idea? Instead of a binary ROM and various patches, say we have a git repo where one branch contains a disassembly of the base ROM and other branches contain the changes that a patch introduces. Each of the mechanics bugfixes from this thread could have its own branch, each translation could have its own branch, and so on for every other kind of graphics/sound/level/etc. patch.

Had some downtime, so thought I'd try to find the area relevant to a seemingly simple fix, and wow, how easy it was to track down stat bonuses from equipment. All I did was Ctrl+F ADC #$0A (+10), and behold, it's literally the only Add Carry of 10 in the entire code. Sure enough, I changed it to $14 (+20) and all equipment gave +20 instead of +10. So the routine at 0x003F23 handles stat bonuses from equipment. Should be easy to figure out how to apply these two fixes. It's just a matter of utilizing space effectively.

That should be easy enough - it looks like $00:$BF13 is only called from one place, so you can save 4 bytes (JSR $BF13 and its RTS) by inlining the function and you can save 2 more bytes by flipping LDX #$00/INX/INX/CPX #$06 to LDX #$06/DEX/DEX, which is enough to add CMP #$64/BCC +2/LDA #$63 before writing the updated stat. If you really want more space for some reason, I'll note that the CLC at $00:$BF1F is useless since we know A < 128 (because we didn't take the BMI), so A + 16 can't overflow, and as long as the current stat value from the LDA ($7A),Y at $00:$BF1D is less than 246 (and if it's not, something has gone seriously wrong somewhere), we also know that adding 10 to it won't overflow, so the CLC at $00:$BF24 is also not needed.

[redmagejoe]

I will make sure that my changes are independent of any Chaos Rush changes, in that case, to stick to conventions, and release the final patch in IPS form that does not include Chaos Rush's translation.

That should be easy enough - it looks like $00:$BF13 is only called from one place, so you can save 4 bytes (JSR $BF13 and its RTS) by inlining the function and you can save 2 more bytes by flipping LDX #$00/INX/INX/CPX #$06 to LDX #$06/DEX/DEX, which is enough to add CMP #$64/BCC +2/LDA #$63 before writing the updated stat. If you really want more space for some reason, I'll note that the CLC at $00:$BF1F is useless since we know A < 128 (because we didn't take the BMI), so A + 16 can't overflow, and as long as the current stat value from the LDA ($7A),Y at $00:$BF1D is less than 246 (and if it's not, something has gone seriously wrong somewhere), we also know that adding 10 to it won't overflow, so the CLC at $00:$BF24 is also not needed.

Yes, but is this also the only routine that handles +10 stat granting equipment? It might be a good idea to try and address both fixes here, including the bonus stacking one. Not that I'm averse to trying out that suggested fix, but I don't want to commit it into IPS and mark it FIXED if we'll just have to change it again.

Also, progress update: I should be finished with my work project before the end of tomorrow, so I can focus all my energy on this by Sunday night at the latest.

Original:

Code Select Expand


0x003F0F|$00:$BEFF:A2 00    LDX #$00
; control flow target (from $BF10)
0x003F11|$00:$BF01:B5 44    LDA $44,X
0x003F13|$00:$BF03:85 5E    STA $5E
0x003F15|$00:$BF05:B5 45    LDA $45,X
0x003F17|$00:$BF07:85 5F    STA $5F
0x003F19|$00:$BF09:20 13 BF JSR $BF13
0x003F1C|$00:$BF0C:E8      INX
0x003F1D|$00:$BF0D:E8      INX
0x003F1E|$00:$BF0E:E0 06    CPX #$06
0x003F20|$00:$BF10:D0 EF    BNE $BF01
0x003F22|$00:$BF12:60      RTS

; control flow target (from $BF09)
0x003F23|$00:$BF13:A0 04    LDY #$04
0x003F25|$00:$BF15:B1 5E    LDA ($5E),Y
0x003F27|$00:$BF17:30 12    BMI $BF2B
0x003F29|$00:$BF19:18      CLC
0x003F2A|$00:$BF1A:69 10    ADC #$10
0x003F2C|$00:$BF1C:A8      TAY
0x003F2D|$00:$BF1D:B1 7A    LDA ($7A),Y
0x003F2F|$00:$BF1F:18      CLC
0x003F30|$00:$BF20:69 0A    ADC #$0A
0x003F32|$00:$BF22:48      PHA
0x003F33|$00:$BF23:98      TYA
0x003F34|$00:$BF24:18      CLC
0x003F35|$00:$BF25:69 10    ADC #$10
0x003F37|$00:$BF27:A8      TAY
0x003F38|$00:$BF28:68      PLA
0x003F39|$00:$BF29:91 7A    STA ($7A),Y
; control flow target (from $BF17)
0x003F3B|$00:$BF2B:60      RTS


My mock-up:

Code Select Expand


0x003F0F|$00:$BEFF:A2 06    LDX #$06
; control flow target (from $BF10)
0x003F11|$00:$BF01:B5 44    LDA $44,X
0x003F13|$00:$BF03:85 5E    STA $5E
0x003F15|$00:$BF05:B5 45    LDA $45,X
0x003F17|$00:$BF07:85 5F    STA $5F
0x003F19|$00:$BF09:A0 04    LDY #$04
0x003F1B|$00:$BF0B:B1 5E    LDA ($5E),Y
0x003F1D|$00:$BF0D:30 16    BMI $BF25
0x003F1F|$00:$BF0F:18      CLC
0x003F20|$00:$BF10:69 10    ADC #$10
0x003F22|$00:$BF12:A8      TAY
0x003F23|$00:$BF13:B1 7A    LDA ($7A),Y
0x003F25|$00:$BF15:69 0A    ADC #$0A
0x003F27|$00:$BF17:48      PHA
0x003F28|$00:$BF18:98      TYA
0x003F29|$00:$BF19:69 10    ADC #$10
0x003F2B|$00:$BF1B:A8      TAY
0x003F2C|$00:$BF1C:68      PLA
0x003F2D|$00:$BF1D:C9 64    CMP #$64
0x003F2F|$00:$BF1F:90 02    BCC $BF23
0x003F31|$00:$BF21:A9 63    LDA #$63
0x003F33|$00:$BF23:91 7A    STA ($7A),Y
0x003F35|$00:$BF25:CA      DEX
0x003F36|$00:$BF26:CA      DEX
0x003F37|$00:$BF27:D0 D8    BNE $BF01
0x003F39|$00:$BF29:60      RTS
0x003F3A|$00:$BF2A:EA      NOP
0x003F3B|$00:$BF2B:EA      NOP


Anything I missed? Pretty sure I fixed all the branches. Also do the other CLCs after BMI need to remain?

[Disch]

Also do the other CLCs after BMI need to remain?

That CLC needs to be there, yes.  Unless you know for certain that C is clear coming into this code (which, based on what you posted, we can't make that determination).