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

Author Topic: FF1 MMC5 Disassembly Updates  (Read 69938 times)

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #340 on: May 28, 2019, 05:36:35 pm »
Well, damn. That's a good amount.

I wonder if I could pull off a crazy ass remake of FF2 with this? The key word system could be a challenge...
Just daydreaming. :3

Anyway, with that amount of space for maps, would it be viable to take an entire map bank and utilize it as a separate overworld?

Without knowing much about how things work, I'm guessing we'd need at least a single bit to use as a flag for which overworld you are on (or more if we wanted multiple overworlds).

If you remember one of our earlier conversations, I'm thinking about that Idea I mentioned about turning the submarine into a fully functional vehicle.

And now that my ideas are flowing, adding a special event to the Sky Castle would be cool.
I'm thinking something along the lines of finding a special "high altitude" airship docked at the Sky Castle.
Maybe make it into a side quest where you have to gain access to it.
Then you get to explore the sky which has a few "sky islands" to explore.

Whoa! Just remembered an idea I had a long time ago...
The past as an entirely new overworld!
The gist of it is that when you use the time gate, you are instead sent near to Cornelia in the past.
Chaos' Temple is sealed and you have to find a way to open it.
Then you end up going around the world again to trade your old quest items for new ones that you'll need.
So you end up replacing all the stuff that was said to have been entrusted for the Warriors of Light.

If I wanted to take things a bit further in terms of the time loop thing, I was thinking that the events in the past should include the crystals being drained by the Fiends in order for them to make the journey to the future.
Then in order to save the world in the past, the Light Warriors then have to return the Light to the crystals by sacrificing themselves (kinda like the Fayth in FFX) to become the guardian spirits of the crystals.
Thus the time loop is complete.

[/rambling]



Just tried out the latest master build on Mesen and it crashes the emulator.
And I mean on immediately when attempting to load I get a black screen and the emulator stops responding.
No conniption fit or anything. Just dead as door nail.
« Last Edit: May 29, 2019, 05:37:50 pm by Vanya »

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #341 on: May 29, 2019, 08:33:38 pm »
Whoopsie. I thought I fixed it... was aware of it doing that, but then traced it to me not updating LongCalls with the proper bank bytes after re-ordering them. Soooo hm. I'm kind of in the middle of messing up everything so I can't fix it without undoing my work or breaking battles, so gimme a day or two to sort that out.

I'm trying to come up with a way to load enemy graphics outside of their tilesets. Formation data has the IDs of all enemies needed, the IDs just need to be sorted small to big, with the amount updated as well...? Then instead of checking the low bits of the first byte for the whole set... just goes through the IDs, but then fiends need their own special loading, but also the second byte in the formation data might be tricky...

Yep. It's a mess.

Love the idea of a second overworld. But... not gonna devote any brain power to how it would be done just now. xD

Edit: Considering how much I have to change for this, I'm shelving it for tonight. I pushed my current build with my new stuff commented out and old stuff in place, and it loads for me okay.

If it still crashes, see what happens with the debugger with a breakpoint set at $C05C... that should be "CMP #$4D" Then let me know if it goes on to "LDA #$4D" or skips past it.



Think I'm gonna drop this idea. Being able to mix and match enemies sounds fun, but the amount of effort is... staggering. And I'm not having fun trying to code it.

Here's a rough draft of what I was trying to do...

Code: [Select]
LoadEnemyGraphics:
;    LDY #2
;   @LoadNext:
;    LDA (tmp+4), Y              ; get enemy ID
;    CMP #$FF                    ; if $FF, do... something to skip it
;    BEQ :+

;    ASL A                       ; double ID, put in X
;    TAX
;    STY enemyload_counter       ; save Y as counter
;    LDA lut_EnemyBankCHR, X     ; get first byte of this table
;    AND #$0F                    ; cut off high bits
;    LDY enemyload_pointer       ; load the pointer thing into Y
;    STA enemyload, Y            ; save the bank # as this byte in the new loading list
;    INY
;    LDA lut_enemyBankCHR, X     ; get first byte again
;    AND #$F0                    ; cut off low bits
;    BEQ @SmallEnemy             ; if its 0, its a small enemy, else...
;   
;    CMP #02
;    BEQ @Fiend
;    CMP #03
;    BEQ @Chaos
;   
;   @LargeEnemy:
;    INX                         ; get second byte of above table
;    LDA lut_enemyBankCHR, X     ; large enemies are $240 bytes each - #576 bytes
;    LDX #$24                    ; so multiply by...
;    JSR MultiplyXA              ;
;    STA enemyload, Y            ; low byte of address
;    INY                         ;
;    TXA                         ; get high byte of multiplication
;    ORA #$80                    ; set highest bit so it loads from the bank's address properly
;    STA enemyload, Y            ; and save as high byte of address
;    INY
;    STY enemyload_pointer
;    LDY enemyload_counter
;    INY
;    CPY #6
;    BEQ @Finish
;    JMP @LoadNext
;   
;   
;   @SmallEnemy:
;    INX                         ; get second byte of above table
;    LDA lut_enemyBankCHR, X     ; small enemies are $100 bytes each
;    STA enemyload, Y            ; low byte of address
;    INY                         ;
;    TXA                         ; get high byte of multiplication
;    ORA #$80                    ; set highest bit so it loads from the bank's address properly
;    STA enemyload, Y            ; and save as high byte of address
;    INY
;    STY enemyload_pointer
;    LDY enemyload_counter
;    INY
;    CPY #6
;    BEQ @Finish
;    JMP @LoadNext

lut_enemyBankCHR:
;; JIGS - left nybble: enemy size (0 = small, 1 = large, 2 = fiend, 3 = chaos)
;;       right nybble: enemy place in chr list
;;        second byte: order in bank (small and large are seperated graphically)


So the thought was, 4 enemies, $10 bytes of pointers and such. 1st byte is the bank to load from, 2nd and 3rd bytes are the pointers to start drawing, 4th byte is how many tiles. Then pass that off to a routine in the fixed bank that would go through the list, swap banks, draw the enemy tiles, ending up with basically the same format as it is now.

But also gotta organize the enemy graphics in the banks, know how many small/large are in each bank, add that offset in when doing large enemies, oawoo... Just a ton more code and extra LUTs for something so... probably not that useful at the current stage...?
« Last Edit: May 29, 2019, 11:28:33 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Disch

  • Hero Member
  • *****
  • Posts: 2717
  • NES Junkie
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #342 on: May 29, 2019, 11:46:03 pm »
I haven't really been keeping up lately, so I might not fully understand what you were going for.

It sounds like you are trying to remove the graphic assignment for a battle formation, and instead load the graphics dynamically based on which enemies are in the encounter?

That's totally do-able.  And I think that might be a fun thing I might not mind spending some time on.  It always seemed unwieldly that to change an enemy you had to change not just the enemy ID, but also the graphic page that gets loaded, the graphic that enemy used, the loaded palettes AND which palette the enemy used.  Most of that should be automatically detectable by just changing the enemy ID.

The real question is what to do about enemy palette assignments....


Here's what I'm thinking:

- Battle formations themselves only include the enemy IDs, and the quantities (and other formation stuff, like 9small vs. 4large, surprise rate, can't run flag, etc).  Remove ALL graphic and palette info from the formation.

- Separate LUTs for graphics, to be indexed by Enemy ID

- Similar LUT for palettes

- When battle is being loaded, use those new LUTs to dynamically load the tiles and palettes you need.


This will work for most cases, but there are problems if the battle formations are configured "improperly".  For example, if you build a formation that has enemies which use 3 separate palettes.. one of the enemies isn't going to get displayed properly because you can only have 2 palettes loaded.

The question in that case is, what to do about it?  Draw the enemy with a wrong palette?  Or simply don't load that enemy (treat it as a quantity of zero)?  I'd lean more towards the latter.


But yeah lemme know what you think.  I'll consider looking at this if I can find the time.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #343 on: May 30, 2019, 01:19:59 am »
Hmmm... My knee-jerk reaction is to not allow more than 2 enemy types per formation.

But that would be pretty draconian, and a step backwards.

I think that the best way to handle it is to zero out anything that would need a third palette.

Anything beyond that is probably more trouble than it's worth.

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #344 on: May 30, 2019, 03:21:14 pm »
Quote
It sounds like you are trying to remove the graphic assignment for a battle formation, and instead load the graphics dynamically based on which enemies are in the encounter?

 Exactly! I just went from Blegh to Oooh Cool in less than 24 hours, so... I like it again! I'll help as much as I can.

I went and did my best to fill out lut_BattlePalettes with information on what enemy uses what palettes, and there's a few combinations I'd love to see. Gas Dragons surrounded by scum and ooze... Zombulls leading zombies... Shadows and spiders together!

Some palettes are really close, too. There's not a whole lot of difference in the palettes SeaTrolls and SeaSnakes use--at least not for those enemies. So some enemies could be slightly altered without losing their main thematic colours and look Just Fine.

If there can be a way to set a trigger on enemies that are using the wrong palette, then I might be in favour of keeping it. They could have a higher rate of stealing special items, or double exp/gold or something. Shiny pokemon enemies! They'd only happen if whoever was building new formations mucked up, so someone could actually make a formation where an imp is using, I d'nno, palette $1C (Earth, Sand W., Ankylo)... sand imps...! Same enemy, new clothes for a new location.



Moved the enemy names so there's more room in Bank B for doing neat formation stuff. Also set up $70 in zero page RAM for enemy_load, in case that's needed.
« Last Edit: May 30, 2019, 04:58:46 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #345 on: May 30, 2019, 03:26:03 pm »
That could be useful for bonus areas or in non-FF projects.
Don't think I'd use it in the main game.

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #346 on: June 01, 2019, 03:30:31 pm »
Nothing really new to report, just a grump:

I made a new way to load the battle backgrounds. In Bank 3, they're all arranged in rows of $100 bytes each. Then instead of loading up a blank tile, there's code that just draws in the blank tiles at the start and after the background. But this does take up some extra room in the fixed bank! So I wondered: maybe it would save bytes to have the blank tiles stored with the backgrounds? But then they'd be in $120 tile rows. That's pretty messy to deal with! I figure, multiply by $12, then shift things left by 4 bits.

I worked out the code for that:

Code: [Select]
    LDA #0
    STA tmp+1
    LDX ow_tile                   ; Get last OW tile we stepped on
    LDA lut_BtlBackdrops, X       ; Use it as an index to get the backdrop ID
    AND #$0F                      ; mask with $0F (there are only 16 battle BGs)
    LDX #$12
    JSR MultiplyXA
    ASL A               ; shift highest bit into carry
    ROL tmp+1           ; shift carry into tmp+1
    ASL A
    ROL tmp+1
    ASL A
    ROL tmp+1
    ASL A
    ROL tmp+1
    STA tmp             ; save remainder of A as low byte of address
    LDA tmp+1           ; load high byte of address
    CPX #1              ; then see if X = 1 from the multiply
    BNE :+
        ORA #$10        ; if the multiplication result was over $FF, add the 1 in
 :  ORA #$80            ; then add the 8 for the start of the bank address
    STA tmp+1

Pretty sleek! Well. Final tally of space in the fixed bank after this is 323 bytes. Final tally with the current version in github is 335! All that work fer nothin'!
I know exactly what I'm doing. I just don't know what effect it's going to have.

Disch

  • Hero Member
  • *****
  • Posts: 2717
  • NES Junkie
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #347 on: June 01, 2019, 07:31:57 pm »
Quote
I figure, multiply by $12, then shift things left by 4 bits.

Err... why not just multiply by $120?

Code: [Select]
LDA lut_BtlBackDrops, X
STA tmp+1               ; using value directly as high byte is the same as mulitply by $100
LDX #$20
JSR MultiplyXA          ; multiply by $20
STA tmp
TXA
CLC
ADC tmp+1               ; (value * $20) + (value * $100) = (value * $120)
ORA #$80
STA tmp+1

EDIT:  made some corrections.

Also, you can't use ORA to add.  It will only add the $10 if that bit isn't already set.
« Last Edit: June 01, 2019, 07:37:34 pm by Disch »

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #348 on: June 09, 2019, 02:46:49 am »
Good news / Bad news

Bad News: My girlfriend's laptop that I was using temporarily to get by without my desktop died hard this week when two of it's resistors blarffed and took out two of the nearby chips on the motherboard.

Good News: I fixed my desktop.

So time allowing, I'll get back to testing the latest build of the project this coming week.

I want to take some time to organize my notes so I can add some suggestions to the online document.

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #349 on: June 23, 2019, 02:10:07 pm »
Err... why not just multiply by $120?

WELL THAT IS AWESOME. I didn't know that was possible... thanks!

And, yeah, I know ORA isn't "add" but in this case... it basically is. I think. Its been a while.

@Vanya: Hope she gets a computer of her own soon! I would go crazy not having one.

So, it turns out having cable internet is not good for my productivity. Been playing too much Elder Scrolls Online, and Shadowbringers is coming out in like two weeks... Also have some music projects to work on, and summer is usually just too hot for me to focus on anything. I've been letting this simmer, not really feeling like working on it lately, but really wishing I did. I don't know when I'll get back into it! Maybe once the music stuff is nearing completion I'll start poking around again.

(Plus I really wanna play that new FF6 script thing!)
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #350 on: June 23, 2019, 06:03:17 pm »
Thanks! We're getting by and thinking of getting a Switch before getting a new laptop.
I've been pretty busy too, but still testing and poking around the banks to see what I can tweak (read: break). :P

Take your time, and enjoy the summer!

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #351 on: June 25, 2019, 11:47:14 pm »
I'm really more of a winter gal... But I'll try?  :D

So I woke up this morning and forgot the thing I thought of then, but I think I remember it: In Mesen, there's an Event viewer thing... Could there be some way to set, not a break point, but a "count how many times we do this" point? Put that in the start of MusicPlay, then get into battle and use the frame-by-frame advance debug button to watch every frame that a menu is drawn and undrawn, and see where MusicPlay is NOT called...? Might look into that tomorrow...
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #352 on: June 26, 2019, 08:32:51 am »
In the Memory Tools dialogue box there is a tab called Access Counters.
Maybe you can use that in conjunction with break points?
I dunno for sure, I'd have to research it more.

Also, what exactly are you trying to "count how many times we do this"?
Like how many times a loop is run? Or something different?

Cyneprepou4uk

  • Full Member
  • ***
  • Posts: 161
  • Самый лысый ромхакер
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #353 on: June 26, 2019, 09:08:36 am »
Could there be some way to set, not a break point, but a "count how many times we do this" point?

How about counting routine executions in log from trace logger by searching how many routine start addresses are in txt file, and comparing it to frames counter
I am the baldest romhacker
NES Romhacking Guide

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #354 on: June 26, 2019, 04:32:05 pm »
I'm confused by what's being suggested! But that's normal.

So I set a breakpoint at the start of MusicPlay in Bank D, then had that marked in the Event Viewer. I got into battle, got to where the messages are being drawn, and started going frame by frame.

This is what it usually looks like:
(PC | Scanline | Cycle | Type | Address | Value | Details)
Code: [Select]
FC74 0 18 Mapper Register Write $5205 $00
FC77 0 30 Mapper Register Write $5206 $1C
FC7A 0 42 Mapper Register Read $5205 $00
FC7D 0 54 Mapper Register Read $5206 $00
FAC6 0 159 Mapper Register Write $5115 $94
FAC6 7 1 Mapper Register Write $5115 $98
FAC6 37 199 Mapper Register Write $5115 $94
FAC6 43 328 Mapper Register Write $5115 $98
FB36 51 84 PPU Register Read $2002 $08
FB46 51 120 PPU Register Write $2000 $88
FB49 241 25 NMI
FB2C 241 46 PPU Register Write $2000 $08
FB2F 241 58 PPU Register Read $2002 $88
F15E 241 133 PPU Register Write $2006 $23
F163 241 154 PPU Register Write $2006 $A0 2nd Write
F16A 241 187 PPU Register Write $2007 $00
F16A 241 235 PPU Register Write $2007 $00
F16A 241 283 PPU Register Write $2007 $00
F16A 241 331 PPU Register Write $2007 $00
F16A 242 38 PPU Register Write $2007 $00
F16A 242 86 PPU Register Write $2007 $00
F16A 242 134 PPU Register Write $2007 $00
F16A 242 182 PPU Register Write $2007 $00
F16A 242 230 PPU Register Write $2007 $00
F16A 242 278 PPU Register Write $2007 $00
F16A 242 326 PPU Register Write $2007 $00
F16A 243 33 PPU Register Write $2007 $00
F16A 243 81 PPU Register Write $2007 $00
F16A 243 129 PPU Register Write $2007 $00
F16A 243 177 PPU Register Write $2007 $00
F16A 243 225 PPU Register Write $2007 $00
F16A 243 273 PPU Register Write $2007 $00
F16A 243 321 PPU Register Write $2007 $00
F16A 244 28 PPU Register Write $2007 $00
F16A 244 76 PPU Register Write $2007 $00
F16A 244 124 PPU Register Write $2007 $00
F16A 244 172 PPU Register Write $2007 $00
F16A 244 220 PPU Register Write $2007 $00
F16A 244 268 PPU Register Write $2007 $00
F16A 244 316 PPU Register Write $2007 $00
F16A 245 23 PPU Register Write $2007 $00
F16A 245 71 PPU Register Write $2007 $00
F16A 245 119 PPU Register Write $2007 $00
F16A 245 167 PPU Register Write $2007 $00
F16A 245 215 PPU Register Write $2007 $00
F16A 245 263 PPU Register Write $2007 $00
F16A 245 311 PPU Register Write $2007 $00
F0FF 246 210 PPU Register Write $2001 $1E
F104 246 228 PPU Register Write $2005 $00
F107 246 240 PPU Register Write $2005 $00 2nd Write
FAC6 246 327 Mapper Register Write $5115 $9A
A6CE 247 40 Breakpoint Type: PRG:‒‒X Addresses: N/A [$366CE]
A780 247 301 Mapper Register Write $5000 $3F
A785 247 322 Mapper Register Write $5002 $57
A78A 248 2 Mapper Register Write $5003 $03
A7BB 248 71 Mapper Register Write $5004 $70
FAC6 255 84 Mapper Register Write $5115 $98
FB36 255 213 PPU Register Read $2002 $00
FB46 255 249 PPU Register Write $2000 $88

The breakpoint in there is where music is being updated for that frame! But then this happened, not long after the damage to an enemy was drawn:

Code: [Select]
FAC6 77 274 Mapper Register Write $5115 $9C
FAC6 84 140 Mapper Register Write $5115 $9C
FAC6 116 229 Mapper Register Write $5115 $9C
FAC6 122 313 Mapper Register Write $5115 $9C
FAC6 154 291 Mapper Register Write $5115 $9C
FAC6 161 34 Mapper Register Write $5115 $9C
FAC6 193 42 Mapper Register Write $5115 $9C
FAC6 199 60 Mapper Register Write $5115 $9C

?? Nothing happened in that frame?

Shortly after undrawing the damage box:
Code: [Select]
FAC6 71 305 Mapper Register Write $5115 $9C
FAC6 78 171 Mapper Register Write $5115 $9C
FAC6 110 260 Mapper Register Write $5115 $9C
FAC6 117 3 Mapper Register Write $5115 $9C
FAC6 148 322 Mapper Register Write $5115 $9C
FAC6 155 65 Mapper Register Write $5115 $9C
FAC6 187 73 Mapper Register Write $5115 $9C
FAC6 193 91 Mapper Register Write $5115 $9C
FC74 256 49 Mapper Register Write $5205 $00
FC77 256 61 Mapper Register Write $5206 $1C
FC7A 256 73 Mapper Register Read $5205 $00
FC7D 256 85 Mapper Register Read $5206 $00
FAC6 256 190 Mapper Register Write $5115 $94

I'm getting this last one again 21 frames after the bottom of the damage box is drawn, which I thiiink would be 18 frames after the whole visible part of the message area is drawn. So if I'm doing this right, there are 2 dropped music frames. All I've been doing is attacking.

Frost wolf doing FROST now, seems to be the same thing. Big list when its drawing the messages, smaller list like this after messages are drawn and its just waiting for you to read them:

Code: [Select]
FB49 241 30 NMI
FB2C 241 51 PPU Register Write $2000 $08
FB2F 241 63 PPU Register Read $2002 $88
FAC6 241 246 Mapper Register Write $5115 $9A
A6CE 241 300 Breakpoint Type: PRG:‒‒X Addresses: $A6CE [$366CE]
A780 242 271 Mapper Register Write $5000 $34
A785 242 292 Mapper Register Write $5002 $E0
A78A 242 313 Mapper Register Write $5003 $01
A7A3 243 38 Mapper Register Write $5004 $73
A7A8 243 59 Mapper Register Write $5006 $F0
A7AD 243 80 Mapper Register Write $5007 $00
FAC6 250 105 Mapper Register Write $5115 $98
FB36 259 228 PPU Register Read $2002 $08
FB46 259 264 PPU Register Write $2000 $88

Then there's a no-music frame right before it starts to un-draw the damage message from the FROST attack.



So... that's a lot of bank switching. $9C is Bank... E? $94 is A. $98 is C.

I'm not sure what data its needing to get from Bank E, but A is basically all the names of things. So it switches back to C to resume battle code, then back to A to get another name. Probably Enemy + Enemy Attack in this case? So, hm. After swapping back to bank C, it should probably be calling MusicPlay? Or I should figure out why its loading Bank E in 8 times. My first guess is that's 8 times to use the number crunching routines to get the HP for everyone.

Yay, progress.
« Last Edit: June 26, 2019, 04:43:52 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #355 on: June 26, 2019, 06:19:10 pm »
Sounds about right to me, but I'm no expert on this.

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #356 on: June 26, 2019, 06:51:28 pm »
Well, I put in a stupid attempt at fixing it. Give it a whirl!

After reading player HP 8 times, it now goes to CallMusicPlay before doing anything else. Pretty sure this is a very bad way to handle this, but in all my frame-event-viewing I've never seen the 8 calls to Bank E followed by the breakpoint before the next NMI happens.

NMI means the next frame is due, right?

Should the temporary fix be to go to WaitForVBlank instead...?

My break from this means I'm again unfamiliar with what's going on when HP is being converted to be drawn... so I can't yet think of a better way to handle it.
I know exactly what I'm doing. I just don't know what effect it's going to have.

91-MPH

  • Jr. Member
  • **
  • Posts: 55
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #357 on: June 26, 2019, 07:14:28 pm »
is it ok if u can also port the localized names (if not script) from the gba-version (and later) into the hack?

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #358 on: June 27, 2019, 03:29:13 pm »
Sure, probably!? Eventually. If the GBA names fit...

How about counting routine executions in log from trace logger by searching how many routine start addresses are in txt file, and comparing it to frames counter

Hey so I think I understand this now after playing around with the trace logger! Yeah, this might have been a faster way to check. XD

From what I can tell, my fix works; actually, without the WaitForVBlank in there too, its sometimes playing music half a frame too fast or something. So I'm editing it a bit more to fix that, and I can't detect any more audio lagging/speeding up.

I also found out that Ninjas can't steal and Poison isn't effecting characters until after the battle, and a possible bug where a character would stay asleep after being hit if the enemy attacking them was giving them an ailment they already have. So I'm gonna try to fix that then upload it again.



All the things I mentioned should be fixed now. Kraken's orb is using the thief's sprite. My fiend battle music was behaving weirdly while I was going through menus; notes getting cut off... not sure what that was about... I'm not going to look into it unless it keeps happening.
« Last Edit: June 27, 2019, 05:46:24 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #359 on: June 28, 2019, 01:05:47 am »
https://wiki.nesdev.com/w/index.php/NMI

This is what nmi is in case you want to know in technical terms.

I'll check out the new changes this weekend.
Gonna be busy, but I'll make to fit it in.