[minucce]

I think it looks correct!


I'll explain the revised code:

Code: [Select]

save_hearts:
lda.w $066F // Load Hearts address
and.b #$0F // Mask higher nibble (only consider current health, not max amount of hearts)
cmp.b #$02 // Compare result to #$02 (3 hearts)
bcs not_three // Branch if equal or greater than 3 hearts

lda.w $066F // Load Hearts address
and.b #$F0 // Mask lower nibble (to avoid the case of heart value $01 loading as $03) (keep maximum life)
ora.b #$02 // Bitwise OR to #$02 (Org. ORA #$02) (minimum 3 life)
sta.w $066F // Store in address $066F (Hearts)

not_three:
rts


1) dead code removal
(I think you see this so I'll explicitly explain it anyways)

Code: [Select]

lda.w $66f
and.b #$ff
ora.b #$00
sta.w $66f

ex.
- A = $80  ($66f)  (Z,N flags can change in Processor!)
- $80 & $FF = $80  (value of A does not change but it will change the (P)rocessor flags!)
- $80 | $00 = $80  (value of A does not change but it also changes P flags!)
- $66f = $80  (no memory change, no flags change either)

In short, (poof!) it. Which leaves rts.


2) Your comments are excellent, easy for any novice to read and follow. Or for yourself in the future.


3) Here's an (unnecessary) flag trick. Saves no space in this example but for learning.

Code: [Select]

lda $66f
and #$0f
cmp #$02

lda $66f
bcs .exit

and #$f0
ora #$02
sta $66f

.exit:
rts

- cmp.b #$02 sets (c)arry flag
- lda.w does not affect cf (value remains same)
- allows opcode re-ordering


4) (Optional) Bit trick

Code: [Select]

lda $66f
and #$0f
lsr
bne .exit

lda $66f
and #$f0
ora #$02
sta $66f

.exit:
rts

I'll let you decipher this one. Maybe it's buggy but I want to know if you can solve the intent of (lsr).

If you don't see it, write down some examples and trace the values.
(and #$0f limits us to 16 possible starting incoming)


5) ?? Unknown optimization trick I don't see ??


EDIT:
If space was really desperate, you could do this:

Code: [Select]

ldx $66f
txa

and #$0f
lsr
bne .exit

txa
and #$f0
ora #$02
sta $66f

.exit:
rts

but it hugely depends on x or y not being used atm.

[ShadowOne333]

Oh interesting!
I did think that maybe one of the repeated routines could be saved up, but it didn't occur me that simply not storing back the value into $066F wasn't really needed. That helped a lot!

Also, neat thing about using the LSR there! If I'm not wrong, having a branch check directly after an LDA or anything like that, checks directly against $01 (BEQ directly checks against $01, while BNE branches if the result is NOT $01, right?).

From what I understand out of it, the LSR moves the bits of the lower nibble to the right, and with the BNE there, it checks if you have any value $01 or above after the shift right in order to branch to the RTS instead, so this effectively takes care of anything above $02. For the BNE to not branch, the result should be $00 after the LSR.
$01 should only occur if you have $03 or $02 as values, but in the case of $01 and $00, you get $00 in the check, so it doesn't branch and continues to the ORA #$02. Is this correct?


If so, then that's a nice trick to save some extra space, in the dire need of a couple of bytes. Having the knowledge of the Branches always checking against $01 as well by default without doing a CMP can also save a lot of bytes when optimizing code.

On a side note, I stumbled upon something rather odd.
If you start your save file and then move one screen above or in any direction, and save in that other screen, the cursor in the File Select defaults to the 3rd save instead. It seems like after saving, RAM address $16 is incremented.

Funny thing is it only seems to occur when you move from the starting screen, if you save at the starting screen itself, it defaults to the 1st save slot when returning to the File Select screen.
It's a weird little thing, I took the liberty of debugging it and it seems like this is the code that's doing that:

Code: [Select]

02:A2F9: 20 5D A3  JSR $A35D
>02:A2FC: E6 16     INC $16 = #$00
 02:A2FE: A5 16     LDA $16 = #$00

Not sure what this might be doing precisely, but it's such a weird thing to stumble upon haha.

Thanks for all the help to create the Save Hearts code, Minucce. It certainly opened up the view of some opcodes I didn't fully understand before, and this would help to debug better in the future, and to understand better some routines and opcodes I could use as well!

[minucce]

Long explanation of LDA + BNE - BEQ

EDIT: Keeps eating my code.

Code: [Select]

LDA #$00 ==> sets Z flag (zero)
BNE no_this_wont_jump
BEQ yes_jump_right_now


Code: [Select]

LDA #$01-FF ==> clears Z flag  (not zero)
BEQ no_this_wont_jump
BNE yes_jump_right_now


Code: [Select]

LDA #80-FF ==> sets N flag  (negative)
BPL no_this_wont_jump
BMI yes_jump_right_now


Code: [Select]

LDA #00-7F ==> clears N flag  (not negative, positive)
BMI no_this_wont_jump
BPL yes_jump_right_now


Code: [Select]

SEC ==> sets C flag  (carry)
LDA #$00-FF ==> no C flag change
BCC no_this_wont_jump_ever__impossible__dead_c0de
BCS yes_jump_right_now


Code: [Select]

CLC ==> clears C flag  (no carry)
LDA #$00-FF ==> no C flag change
BCS no_this_wont_jump_ever__impossible__dead_c0de
BCC yes_jump_right_now


Since others are reading, re-verification of your LSR analysis.

Bit long so bracket tagged.

Code: [Select]

LDA #$00
LSR  ==> $00 / 2 = $00
BNE not_happening
BEQ yes_we_are_zero


Code: [Select]

LDA #$01
LSR  ==> $01 / 2 = $00
BNE not_happening
BEQ yes_we_are_zero


Code: [Select]

LDA #$02
LSR  ==> $02 / 2 = $01
BEQ not_happening
BNE yes_we_are_non_zero


Code: [Select]

LDA #$03
LSR  ==> $03 / 2 = $01
BEQ not_happening
BNE yes_we_are_non_zero


Code: [Select]

LDA #$04
LSR  ==> $04 / 2 = $02
BEQ not_happening
BNE yes_we_are_non_zero


Right! Only for 00-01 we fall-through to the ORA #$02.

Nothing more to add.

----

If you start your save file and then move one screen above or in any direction, and save in that other screen, the cursor in the File Select defaults to the 3rd save instead. It seems like after saving, RAM address $16 is incremented.

Funny thing is it only seems to occur when you move from the starting screen, if you save at the starting screen itself, it defaults to the 1st save slot when returning to the File Select screen.
It's a weird little thing, I took the liberty of debugging it and it seems like this is the code that's doing that:

Mmm. Have to check my notes. $16 could be a "submode selecter" -- aka what menu phase we're in. It can only get so much done in 1 VBlank so it split itself into mulitple parts.

----

Thanks for all the help to create the Save Hearts code, Minucce. It certainly opened up the view of some opcodes I didn't fully understand before, and this would help to debug better in the future, and to understand better some routines and opcodes I could use as well!

Curiously other hackers have learned a lot from reading this exercise also. Bonus!
November 24, 2021, 02:58:29 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Keep tapping $16 writes. Final one says:

Code: [Select]

02:A573: A5 54     LDA $54 = #$02
 02:A575: C9 03     CMP #$03
 02:A577: 90 02     BCC $A57B
 02:A579: A9 00     LDA #$00

 02:A57B: 85 16     STA $16 = #$02
>02:A57D: A9 00     LDA #$00


which turns out to be my code (.. uh-oh!)

Code: [Select]

%org($a573, $02)

main_menu_init_done:
lda $54
cmp #$03
bcc .write

lda #$00 ; default save slot 0


.write:
sta $16


$16 is used as our menu cursor (save 1-3, copy, erase).
(watch hex editor as cursor moves around)


Put a breakpoint on a573.
- Enter copy menu. Quit. $54 = $03 ==> $16 = $00.
- Enter erase menu. Quit. $54 = $04 ==> $16 = $00.
- Copy from 2 to 1. $54 = $00 ==> $16 = $00.
- Copy from 2 to 3. $54 = $02 ==> $16 = $02.

So $54 appears to be a temp var I found and was using. It remembers the last person we selected.

This seems to break on game over.


You have a few quick options:
- Always default to save 1 (makes sense)
- Fix game over to reset to save 1 (or current player). More asm work.
- ..?
- Debug $54 as turns out it's the guilty one (I first thought $16 too)

[ShadowOne333]

Oh whoops
I didn't check if that STA $16 was part of your Menu tweaks code haha

From what I'm seeing, making it default to the first save slot is what would make the most sense, right?
In that case, then perhaps simply forcing it to store #$00 at $16 on menu init should be good enough.

Code: [Select]

org $A573 // 0x0A583
main_menu_init_done:
lda.b #$00 // Default save slot 0
sta.b $16

Having that should do it, right?
Although I'm not sure if the LDA $54 and the CMP #$03 is needed there for anything else.
If it's not, then I think leaving it like this should be good enough.

Let me know what do you think.

[minucce]

I didn't check if that STA $16 was part of your Menu tweaks code haha

I was wondering where it came from and dug around. Surprised me too.


You're fix looks good to me! Discarding $54 is safe because code flow shows us:

Code: [Select]

LDA $54 = #$02
CMP #$03
BCC path_2

path_1:
LDA #$00

path_2:
STA $16 = #$02

path_2a:
LDA #$00
sta $13

lda #$ff
sta $526

inc $11
rts

We always hit path_2. And path_2a says to clobber A = #$00, which removes any evidence we loaded $54 (00-FF).

A smart person can object that the (C)arry flag is still in play. Rest of code shows it is not used (follow code after rts).

You're done!

[ShadowOne333]

Neat! Then it's ready to ship
Thanks!

A smart person can object that the (C)arry flag is still in play. Rest of code shows it is not used (follow code after rts).

In that case, would you recommend adding a CLC to clear the carry flag?
And if so, where would it be ideal to put it?

[minucce]

In that case, would you recommend adding a CLC to clear the carry flag?

I personally checked it. The Carry flag (c=0 or c=1) gets erased later on so does no damage to us. Original main menu routine itself does not rely on (c)arry flag (0 or 1) so that's a double + to ignore it.


And I had no use for (not)carry beyond that simple cmp. No need to worry this time.
(people like me can preserve it for awhile or use it as (rts exit value) so it is something to be mindful of, but not this case)


EDIT:
If it was important, you'd either have to know the correct value (clc, sec) and set it towards the end (latest possible moment). You don't want some other opcode mucking it up too early (Z80 is very good at doing this to you; xor - or - and are not friendly to carry, unlike the 6502).

Or php / plp.
Or regenerate it from whatever (original old code).


Side-note:
A "ld" on Z80 does not affects Z,C flags. Which requires a harmless "or a" to check if it's zero.
(a | a = a)


Honestly I forgot if it's (not) true for the other chips, but that's why you use a debugger to write up quick opcode tests to see what happens.

Give me a week and likely I'll forget these opcode quirks.

[ShadowOne333]

Ah I see.
Then indeed the carry flag is only kept but isn't used at all during its routine, and it effectively gets erased without being used.

It's nice to know!

Thanks for all the detailed explanations, and also thanks yet again for all the wonderful help that you've given to some of the projects I had in preparation for years.
Thanks to all that, all of the points I wanted to cover for both Zelda 1 and Zelda 2 are now a reality, and I can happily say both projects are complete and finished!
If nothing arises, I will push the updates to the Romhacking pages in the upcoming days.

The most sincere and honest thanks for your help!

[minucce]

Asar code
https://github.com/minucce/workbox/raw/a5da30090130878d0952fbcd2f290d0572b31ccb/box7/main.txt


This goes on top of "Super Castlevania IV Uncensored"
https://github.com/minucce/workbox/raw/a5da30090130878d0952fbcd2f290d0572b31ccb/box7/blood_drop.ips


Which makes this



The rest of the special effect I'm allowing ShadowOne333 to take care of - sprite repaint, reposition, puddle, misc.
November 30, 2021, 01:25:33 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Took a small peek recon work of Wrecking Crew 98. It already crashed when pressing button on this cutscene.

Code: [Select]

$D4/2263 A4 3C       LDY $3C    [$00:0F3C]   A:1945 X:1942 Y:0000 D:0F00 DB:00 S:1FFB P:envmxdIZc HC:0607 VC:232 FC:03 I:00
$D4/2265 B7 0E       LDA [$0E],y[$D4:7E57]   A:1945 X:1942 Y:7E57 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0653 VC:232 FC:03 I:00
$D4/2267 85 38       STA $38    [$00:0F38]   A:429C X:1942 Y:7E57 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0695 VC:232 FC:03 I:00
$D4/2269 C8          INY                     A:429C X:1942 Y:7E57 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0710 VC:232 FC:03 I:00
$D4/226A 84 3C       STY $3C    [$00:0F3C]   A:429C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0718 VC:232 FC:03 I:00
$D4/226C 64 3A       STZ $3A    [$00:0F3A]   A:429C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0733 VC:232 FC:03 I:00
$D4/226E 4C C5 21    JMP $21C5  [$D4:21C5]   A:429C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0748 VC:232 FC:03 I:00
$D4/21C5 A5 38       LDA $38    [$00:0F38]   A:429C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0756 VC:232 FC:03 I:00
$D4/21C7 29 FF 00    AND #$00FF              A:429C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0785 VC:232 FC:03 I:00
$D4/21CA AA          TAX                     A:009C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0793 VC:232 FC:03 I:00
$D4/21CB 7C CE 21    JMP ($21CE,x)[$D4:3C84] A:009C X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0801 VC:232 FC:03 I:00
$D4/3C84 FF FF FF FF SBC $FFFFFF,x[$FF:009B] A:009C X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0832 VC:232 FC:03 I:00
$D4/3C88 FF FF FF FF SBC $FFFFFF,x[$FF:009B] A:00E3 X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0873 VC:232 FC:03 I:00
$D4/3C8C FF FF FF FF SBC $FFFFFF,x[$FF:009B] A:012A X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0914 VC:232 FC:03 I:00
$D4/3C90 FF FF FF FF SBC $FFFFFF,x[$FF:009B] A:0171 X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0955 VC:232 FC:03 I:00
$D4/3C94 FF FF FF FF SBC $FFFFFF,x[$FF:009B] A:01B8 X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0996 VC:232 FC:03 I:00

Does this look familiar? Otherwise I'll dig deeper.
November 30, 2021, 06:42:18 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Fix:
https://github.com/minucce/workbox/raw/ee6aa1b2ff1eb04dadf3eed5f7762e20a5986579/box8/main.txt
https://github.com/minucce/workbox/raw/ee6aa1b2ff1eb04dadf3eed5f7762e20a5986579/box8/wrecking_fix.ips



Explain:
I wouldn't call this easy. It required comparing 2 very long trace logs for unusual differences.

Code: [Select]

$D4/249A AD A9 18    LDA $18A9  [$00:18A9]   A:0001 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:1317 VC:240 FC:25 I:00
$D4/249D D0 0D       BNE $0D    [$24AC]      A:7F01 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:1341 VC:240 FC:25 I:00
$D4/24AC 3A          DEC A                   A:7F01 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:1355 VC:240 FC:25 I:00
$D4/24AD 0A          ASL A                   A:7F00 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:1363 VC:240 FC:25 I:00
$D4/24AE 18          CLC                     A:FE00 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:eNvmxdIzc HC:0007 VC:241 FC:25 I:00
$D4/24AF 65 3C       ADC $3C    [$00:0F3C]   A:FE00 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:eNvmxdIzc HC:0015 VC:241 FC:25 I:00
$D4/24B1 A8          TAY                     A:57B4 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:envmxdIzC HC:0044 VC:241 FC:25 I:00
$D4/24B2 20 B6 FF    JSR $FFB6  [$D4:FFB6]   A:57B4 X:001C Y:57B4 D:0F00 DB:00 S:1FFB P:envmxdIzC HC:0052 VC:241 FC:25 I:00

See value of $18a9. Where did $7f01 come from?

Code: [Select]

$D4/5D23 A2 01       LDX #$01                A:5C06 X:0000 Y:00CC D:0F00 DB:00 S:1FF7 P:envMXdIZC HC:0085 VC:239 FC:13 I:00

$D4/5D25 8E A9 18    STX $18A9  [$00:18A9]   A:5C06 X:0001 Y:00CC D:0F00 DB:00 S:1FF7 P:envMXdIzC HC:0098 VC:239 FC:13 I:00

$D4/5D28 28          PLP                     A:5C06 X:0001 Y:00CC D:0F00 DB:00 S:1FF7 P:envMXdIzC HC:0107 VC:239 FC:13 I:00
$D4/5D29 6B          RTL                     A:5C06 X:0001 Y:00CC D:0F00 DB:00 S:1FF8 P:envmxdIzc HC:0116 VC:239 FC:13 I:00

For those unfamiliar with snes, X can be 8-bit (-X) or 16-bit (-x) (see Processor flags in trace).
- Sound engine uses 8-bit value. Only writes to $18a9.
- Script engine uses 16-bit value. Reads from both $18a9 and $18aa.

Then where did $18aa gets it value?

Code: [Select]

$D4/FFE8 8D A9 18    STA $18A9  [$00:18A9]   A:7FFE X:20F7 Y:7FFE D:0F00 DB:00 S:1FF7 P:envmxdIzC HC:0721 VC:233 FC:04 I:00

Some line break or pause scripting code. So fix sound engine code to write full 16-bit value.

No more crashes on skipping intro. (Spike cutscene untested)
November 30, 2021, 07:23:25 pm - (Auto Merged - Double Posts are not allowed before 7 days.)On a side-note, there's a free GBC game called "Tobu Tobu Girl DX"
http://tangramgames.dk/tobutobugirldx


which turns out has a SGB + GBC bug in mGBA, but not BGB.
https://github.com/mgba-emu/mgba/issues/2367

vs

which also turns out, that same bug is affecting the Konami GB Collection - Autoboot + SGB compatibility patches.


I consider my work in them complete atm, but you gamers may have to wait awhile until mGBA 0.10.0+.

Because I've been asked a few times privately already, no I'm not releasing them other than to the hacker who originally requested the fixes + improvements. Sorry. You'll just have to wait like (mostly) the rest of us.


When the situation changes, I'll probably let everyone know.

(and no, fixing the games for emulator compatibility would take lots more time than to fix the emulator itself). Please be patient.
November 30, 2021, 07:53:54 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Tested Wrecking Crew 98 - Spike. Okay. No crash.

[ShadowOne333]

Wow WHAT?!
That came totally out of the blue!
I wasn't expecting both the Blood Drop and the Wrecking Crew fix as well!

Amazing!
As soon as I saw this, I started work, this is what I have:

Asar code
https://github.com/minucce/workbox/raw/a5da30090130878d0952fbcd2f290d0572b31ccb/box7/main.txt


This goes on top of "Super Castlevania IV Uncensored"
https://github.com/minucce/workbox/raw/a5da30090130878d0952fbcd2f290d0572b31ccb/box7/blood_drop.ips


Which makes this



The rest of the special effect I'm allowing ShadowOne333 to take care of - sprite repaint, reposition, puddle, misc.

I spent the whole day editing the sprites, graphics and everything needed to get this properly working.
I only modified the title screen a little bit to accommodate the blood drop, and I had to also change the blood drop graphics so they appear in the correct Y position on the screen.

Here's the latest patch:
https://www.dropbox.com/s/6xwbcmtk1x9eklt/Super%20Castlevania%20IV%20Uncensored%20%28Headerless%29.ips?dl=0

(I'd post a GIF, but I can't find a way to record the screen nor make a gif in Gentoo with what I have atm :/)

There's just one small drawback to this...
The blood puddle in the stone is mirrored, so you can now see two blood puddles, one where the blood drop falls, and another on the left (what a bloody mess!).

I have the suspicion that this might be due to the tile mapping being shared with the left side of the screen (and some small pixels of blood on the bottom too).
I didn't have time today to attempt to find the tile mapping to hide the left puddle and the bottom tiles, but I'll continue on this tomorrow morning.

Took a small peek recon work of Wrecking Crew 98. It already crashed when pressing button on this cutscene.

Code: [Select]

$D4/2263 A4 3C       LDY $3C    [$00:0F3C]   A:1945 X:1942 Y:0000 D:0F00 DB:00 S:1FFB P:envmxdIZc HC:0607 VC:232 FC:03 I:00
$D4/2265 B7 0E       LDA [$0E],y[$D4:7E57]   A:1945 X:1942 Y:7E57 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0653 VC:232 FC:03 I:00
$D4/2267 85 38       STA $38    [$00:0F38]   A:429C X:1942 Y:7E57 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0695 VC:232 FC:03 I:00
$D4/2269 C8          INY                     A:429C X:1942 Y:7E57 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0710 VC:232 FC:03 I:00
$D4/226A 84 3C       STY $3C    [$00:0F3C]   A:429C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0718 VC:232 FC:03 I:00
$D4/226C 64 3A       STZ $3A    [$00:0F3A]   A:429C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0733 VC:232 FC:03 I:00
$D4/226E 4C C5 21    JMP $21C5  [$D4:21C5]   A:429C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0748 VC:232 FC:03 I:00
$D4/21C5 A5 38       LDA $38    [$00:0F38]   A:429C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0756 VC:232 FC:03 I:00
$D4/21C7 29 FF 00    AND #$00FF              A:429C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0785 VC:232 FC:03 I:00
$D4/21CA AA          TAX                     A:009C X:1942 Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0793 VC:232 FC:03 I:00
$D4/21CB 7C CE 21    JMP ($21CE,x)[$D4:3C84] A:009C X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0801 VC:232 FC:03 I:00
$D4/3C84 FF FF FF FF SBC $FFFFFF,x[$FF:009B] A:009C X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0832 VC:232 FC:03 I:00
$D4/3C88 FF FF FF FF SBC $FFFFFF,x[$FF:009B] A:00E3 X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0873 VC:232 FC:03 I:00
$D4/3C8C FF FF FF FF SBC $FFFFFF,x[$FF:009B] A:012A X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0914 VC:232 FC:03 I:00
$D4/3C90 FF FF FF FF SBC $FFFFFF,x[$FF:009B] A:0171 X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0955 VC:232 FC:03 I:00
$D4/3C94 FF FF FF FF SBC $FFFFFF,x[$FF:009B] A:01B8 X:009C Y:7E58 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:0996 VC:232 FC:03 I:00

Does this look familiar? Otherwise I'll dig deeper.
November 30, 2021, 06:42:18 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Fix:
https://github.com/minucce/workbox/raw/ee6aa1b2ff1eb04dadf3eed5f7762e20a5986579/box8/main.txt
https://github.com/minucce/workbox/raw/ee6aa1b2ff1eb04dadf3eed5f7762e20a5986579/box8/wrecking_fix.ips



Explain:
I wouldn't call this easy. It required comparing 2 very long trace logs for unusual differences.

Code: [Select]

$D4/249A AD A9 18    LDA $18A9  [$00:18A9]   A:0001 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:1317 VC:240 FC:25 I:00
$D4/249D D0 0D       BNE $0D    [$24AC]      A:7F01 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:1341 VC:240 FC:25 I:00
$D4/24AC 3A          DEC A                   A:7F01 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:1355 VC:240 FC:25 I:00
$D4/24AD 0A          ASL A                   A:7F00 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:envmxdIzc HC:1363 VC:240 FC:25 I:00
$D4/24AE 18          CLC                     A:FE00 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:eNvmxdIzc HC:0007 VC:241 FC:25 I:00
$D4/24AF 65 3C       ADC $3C    [$00:0F3C]   A:FE00 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:eNvmxdIzc HC:0015 VC:241 FC:25 I:00
$D4/24B1 A8          TAY                     A:57B4 X:001C Y:59B4 D:0F00 DB:00 S:1FFB P:envmxdIzC HC:0044 VC:241 FC:25 I:00
$D4/24B2 20 B6 FF    JSR $FFB6  [$D4:FFB6]   A:57B4 X:001C Y:57B4 D:0F00 DB:00 S:1FFB P:envmxdIzC HC:0052 VC:241 FC:25 I:00

See value of $18a9. Where did $7f01 come from?

Code: [Select]

$D4/5D23 A2 01       LDX #$01                A:5C06 X:0000 Y:00CC D:0F00 DB:00 S:1FF7 P:envMXdIZC HC:0085 VC:239 FC:13 I:00

$D4/5D25 8E A9 18    STX $18A9  [$00:18A9]   A:5C06 X:0001 Y:00CC D:0F00 DB:00 S:1FF7 P:envMXdIzC HC:0098 VC:239 FC:13 I:00

$D4/5D28 28          PLP                     A:5C06 X:0001 Y:00CC D:0F00 DB:00 S:1FF7 P:envMXdIzC HC:0107 VC:239 FC:13 I:00
$D4/5D29 6B          RTL                     A:5C06 X:0001 Y:00CC D:0F00 DB:00 S:1FF8 P:envmxdIzc HC:0116 VC:239 FC:13 I:00

For those unfamiliar with snes, X can be 8-bit (-X) or 16-bit (-x) (see Processor flags in trace).
- Sound engine uses 8-bit value. Only writes to $18a9.
- Script engine uses 16-bit value. Reads from both $18a9 and $18aa.

Then where did $18aa gets it value?

Code: [Select]

$D4/FFE8 8D A9 18    STA $18A9  [$00:18A9]   A:7FFE X:20F7 Y:7FFE D:0F00 DB:00 S:1FF7 P:envmxdIzC HC:0721 VC:233 FC:04 I:00

Some line break or pause scripting code. So fix sound engine code to write full 16-bit value.

No more crashes on skipping intro. (Spike cutscene untested)
November 30, 2021, 07:53:54 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Tested Wrecking Crew 98 - Spike. Okay. No crash.

The whole day I went bollocks with the SC4 stuff, that I didn't even get time to test this out as well.
I'll make sure to give this one a test.
So in the end, the issue was that there was one opcode that was receiving an 8bit value instead of a 16bit one?

I'll test this as well tomorrow and let you know if I find anything!
Thank you, thank you, thank you for everything!

EDIT:
I tested out the Wrecking Crew 98 fix rather quickly (since I won't have access to the PC I do this stuff on until tomorrow), and indeed, both the crash you mention and the Spike crashes seem to now be fixed!

[Pethronos]

Hi guys! I know that I always come here to ask things but, here I go... 

Shadowone333, your new patch is not compatible with FastRom (asm) anymore. Could you do somthing about it? 

BTW thanks for all yor hacks and fixes mates, you are awesome! 

[ShadowOne333]

Hi guys! I know that I always come here to ask things but, here I go... 

Shadowone333, your new patch is not compatible with FastRom (asm) anymore. Could you do somthing about it? 

BTW thanks for all yor hacks and fixes mates, you are awesome! 

Which patch are you talking about?

[Pethronos]

I don't believe you don't know Vitela's SA-1 and FastRom patches.

https://github.com/VitorVilela7/

https://github.com/VitorVilela7/fastrom/tree/master/super-castlevania-iv
December 01, 2021, 06:27:31 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Oops, it seems that it is compatible if applied after FastRom 

I have to check why I thought that the only way was applying the asm after the Uncensored. I'll check it this weekend in my main laptop.

[minucce]

I didn't want to suggest anything about CV4 or W98 until I was sure I could handle them.


Of which, while you were fixing up CV4 (thank you!), I took care of inserting the W98 credits. They might need re-centering, re-naming or ypos adjusting.


https://github.com/minucce/workbox/raw/b98e4ff265859acb0930ca4488c1cdb648b84ebd/box8/wrecking_credits.ips
(thanks to DarkSamus993 for leaving behind lots of useful documentation)


And the source
https://github.com/minucce/workbox/raw/b98e4ff265859acb0930ca4488c1cdb648b84ebd/box8/credits.7z
(I wrote my own packer as I couldn't locate the original graphics tools)


I did see untranslated tiles. Maybe they're unused?


_____________________________________________


I didn't know a FastROM patch existed either (and almost wasted some time). The website says

You can play the FastROM version with the Uncensored hack.

Apply the .asm file directly into the Uncensored ROM via Asar.

It's a very destructive process and should always be applied first, before anyone else's work (via ips patch or asm modification).

________________________________________________


Current blood preview



Very nice touchups! I haven't looked at giving some advice yet on the last problems, but you're a capable hacker.

_____________________________________________________


Wrecking Crew 98 is an original engine bug. Exactly as you described, 8-bit opcode being used when it should be 16-bits.

[ShadowOne333]

Oh man, you should have just asked me
https://www.dropbox.com/s/echwwnkzdzy7gvj/WC98%20Tools.zip?dl=0

I had that one saved up for ages, hopefully it helps you out on something.
I believe it has everything up to the point where I left the last update at.
It should have everything both DarkSamus993 and rainponcho did as well, all of the scripts and other stuff required for extracting the assets and compressing/compiling them back into the game.

All that's needed is a file called "Wrecking Crew '98 (Japan).sfc" inside the /game/ folder and it should work just fine.

I also tested the Credits you made, and they seem to work wonderfully!
All of the characters are now fully translated!
Thanks again, minucce!

If you don't mind, I'll prep up the patches to update the Wrecking Crew '98 translation and call it complete now

As for these untranslated tiles:

I did see untranslated tiles. Maybe they're unused?

From what I remember, and I briefly do, I think they're unused assets.
This is 安全第一, which stands for "Safety First".
This specific phrase appears when you defeat an enemy by making a 9-block combo of Pink Walls, serves as some sort of insta-kill. When you achieve that combo, a sign of Bowser with a helmet, and that phrase, appears on the opponent's side.

You can easily test it out in-game with the following cheat code:

Instant Win (Press A)
C21F2780
C21F280D
C21F3CC9
C21F3D00

That's the one I use to easily win and test stuff out quickly.
Quickly enter a match and press A, you will win almost instantly and you will see that sign appearing, with the proper words translated.
I'm unsure if those untranslated graphics are used or not during the Credits sequence, I haven't checked with a VRAM viewer, but that's the only place where those graphics might show up.
Although, if those graphics DO end up showing up there, since the credits sequence only shows Bowser's graphics in the framing, they might be effectively unused.


As for Super Castlevania 4, I did some more digging with bsnes-plus and its Tile debugging features, and I think I have found the tilemapping for the title screen.

The title screen tiles seem to be around $292300 (in the SC4 Uncensored ROM), each tilemap address seems to be two bytes, corresponding to the tiles themselves.
They all seem to follow a pattern like $1X XX. I have yet to determine which tiles will overwrite the ones for the left puddle and the ones at the bottom, but at least I know where to screw around in the ROM now.

I'll continue updating the WC98 translation, and then I'll continue with the SC4 stuff as well today

PS: Btw, I noticed the Uncensored ROM is 4MB, but when actually viewing it in a Hex or graphics editor, it stops having data after the 3MB range, would it possible to trim it down to 3MB instead of 4MB?

I don't believe you don't know Vitela's SA-1 and FastRom patches.

https://github.com/VitorVilela7/

https://github.com/VitorVilela7/fastrom/tree/master/super-castlevania-iv
December 01, 2021, 06:27:31 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Oops, it seems that it is compatible if applied after FastRom 

I have to check why I thought that the only way was applying the asm after the Uncensored. I'll check it this weekend in my main laptop.

Oh I was asking because you only said "your new patch is not compatible with FastROM", but SC4 is not the only SNES game I have worked on, that's why I had to ask which project you were referring to, since you didn't mention the name of the game or project

It's nice to know Vitor has a FastROM hack for SC4, and more so that it is compatible with SC4 Uncensored!
I might add the FastROM feature into it, just to it also removes the annoyances of slowdowns, thanks for bringing it up!

[minucce]

PS: Btw, I noticed the Uncensored ROM is 4MB, but when actually viewing it in a Hex or graphics editor, it stops having data after the 3MB range, would it possible to trim it down to 3MB instead of 4MB?

I really doubt there's bank mirroring so should be safe to edit the SNES header flag and manually trim the rest.
December 02, 2021, 02:35:54 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Got a blood hit at d2:a2af ($2922af). 6 tiles wide.

[ShadowOne333]

I've been taking way too long because I wanted it to look as close to the original Japanese version as possible, but I think I'll have to settle with look-a-like tiles from the current tileset for the ground

I managed to replace the blood splashes on the bottom of the screen:


Now, unto the blood puddle, and that should be it

PS: For documentation purposes, these are the exact tilemap bytes for the blood puddle on the left:

Code: [Select]

DB 5D DA 5D D9 5D D8 5D

E3 1D E4 1D E5 1D E6 1D E7 1D E8 1D E9 1D

F3 1D F4 1D F5 1D F6 1D F7 1D F8 1D F9 1D FA 1D FB 1D FC

05 1E 06 1E 07 1E 08 1E 09 1E


DONE!



I really had a hard time trying to make it look good with the available tileset, but I think it looks really good now!
I will retouch the title screen a little bit, to add some blood below the "CASTLEVANIA" title, and then I'll call it a day

[minucce]

Japan tileset (vram 6600-8e00) looks identical to USA tileset (vram 6000-8800). You could copy over the remaining tiles but it would require redoing the tilemap.

I'd say keep working until you're happy; it's only once you get a 1st impression. Although a good 2nd one can change that.

[ShadowOne333]

From what I've seen, it seems like the US one is missing a small number of tiles. Well, not really missing, but repurposed. I finalized what I was doing with the tilemapping, and I think I'm happy with the result.

Not only that, but I have also finished the reworked title screen, so it combines aspects from both the Japanese release and the US release, for a more proper complete title screen that goes well alongside the blood dropping



And here's the patch for it:
https://www.dropbox.com/s/6xwbcmtk1x9eklt/Super%20Castlevania%20IV%20Uncensored%20%28Headerless%29.ips?dl=0

If everyone's happy, next would be to simply apply the FastROM patch by Vitor from here:
https://github.com/VitorVilela7/fastrom/tree/master/super-castlevania-iv

After that, it should be ready for update

[Pethronos]

You can call it a day indeed!!