Shell Monsters

[KingMike]

I beat the game just now, so... :jumping-smiley1:
Stage 1 of bugtest (make sure game is finishable without crashes)...complete. :)
Stage 2 (fix graphics glitches)...to begin. :ph34r:

[KaOSoFt]

Well, I hope you finish soon. Well done and good luck!

[byuu64]

Kick ass, was it a cool ending? btw, what are you going to call the game for your title screen hack?
I want to try and come up with a naming convention, at least for the title.
Romaji variants > Kaiju Monogatari (most common, wrong), Kaijuu Monogatari, Kaijyu Monogatari (wrong wrong wrong), etc.
Or are you going with an English translation?
English variants > Shell Monster Story, Shell Monsters Story, The Story of the Shell Monsters, etc.

[KingMike]

I'm thinking of Shell Monsters Story.
I'm planning on changing "Kaijyu Monogatari (kanji)" to MONSTERS
and "Kaijyu Monogatari (kana)" to STORY.

So we have the original SHELL graphic, then MONSTERS in the big gray letters, then STORY below it. Good idea?

I'm not quite sure if I saw the whole ending. I just waited for awhile at a blank screen and didn't get even an "END" or anything :lol: after the last graphic dissapeared.

I have a FCEUltra save state right after beating Fat Badger, still works with the Japanese ROM.
The trouble I'm having right now is finding the data relating to clearing sprites behind windows (only sprites within the original window dimensions are hidden when a window is opened). That is the one major graphics glitch that will need to be fixed before a release can come.

[byuu64]

I'd have to see the Japanese title screen again, honestly... all I remember is that it scrolls from the top and bottom and joins in the middle.

As far as the window issue goes, I'd wager to guess it draws the window first, and then goes through in another loop to set the tile priorities to overlap the sprites. I don't think anyone has really made a good debugger for the NES, but this is probably the -only- game I'd want to see translated on the NES at this point, so I doubt there's any incentive to anyway. If you're unable to figure it out in time, I'd be willing to give it a shot for you, I imagine I could whip up a disassembler for the game in 5 minutes. My cross assembler will already work on it... but I do warn you that I know absolutely nothing on the NES right now (I'd really only need a crash course in the PPU regs)... anyway, let me know if you want me to give it a shot. I'm even stumped right now on dkjm, dealing with trying to get the Swap command working with the -ultra-complicated- setup I used to scroll the 8x8 vwf tiles for the item lists and it is just totally kicking my ass.

I wonder what I should call the sequel. Big Shell Monsters Story doesn't sound right. They haven't technically gotten any 'bigger'. It conveys the wrong meaning... :/

By the way, I found two more (albeit stupid) Kaijuu Monogatari games. There's two gameboy card games called Miracle of the Zone 1/2. But they're stupid. Just interesting that there are more spinoffs than official games. Damn greedy companies <_<

[KingMike]

When the game starts up, it shows a mountain (Shell Monster Island) with a SHELL banner written on it. Then the island moves up to the top of the screen. Then the kanji title slides in from both directions (top half from the left, bottom half from the right). Then everything else fades in.

I've looked at a trace log done in Nesten. I've firgured a LDA ($something),Y command would be most likely (since there's so many windows, it'd make sense to read from a database), but I haven't hit upon a working command yet. I've only hit the map data (I think) and maybe some map tileset properties, but nothing that affects the windows.
I noticed some code in the $C000 ROM block that made the main character show through the window when he shouldn't have (this was way before I even knew how to expand the windows at all). Maybe I'll run suspicious data (stuff that looks like a pointer table) through a corruptor.
Also I'm going to try and see about getting normal (8KB) SRAM added to the game, instead of the special 128 byte SRAM this game was intended to use (I don't think it'd be too hard, assuming that the game only uses the block the save/load code is in (since of course long jumps are impossible in the NES, I'll need to swap in a duplicate of the original bank, making sure none of the code the save/load routines need get overwritten) and the "hard-wired" RAM bank. I believe I would just need to copy the load/save ASM, replace the STA $F800 (high bit turns auto-address increment on/off, lower 7 bits are the SRAM address) and LDA/STA $4800 (read from/write to SRAM respecitively) commands.
AFAIK, this mini-SRAM is only supported in Unofficial Nester, and only in the properly-dumped Japanese ROM.
Lastly, I'm also thinking of speeding the text up slightly, which is fine for the Japanese text, but a tad slow for the English (notice how DW1 prints text faster than DQ1, even though it has more characters to print :lol: )? Though this is really a minor touch-up thing.
I've found the value that controls text speed (fast has a hex value of $00, normal=$01, slow=$02... $FF=maybe it will print sometime today :lol: ), I guess it would be a matter of somehow shortening the number of frames or whatever each increase in the hex value represents?

[byuu64]

Well that explains why I had to use savestates to save... heheh.

As far as text speed. What I would do was, get a good save point before text appears, enter into the debugger, set the text speed to 0 and run a trace, then load the save, set it to 1, and do another trace. Compare the files for the first difference...
I would say the game probably has -something- like:
lda text_speed : beq speed1
cmp #$01 : beq speed2
speed3: lda #$30 : bra done
speed2: lda #$20 : bra done
speed1: lda #$10
done: jsr vsync

Reg. a would contain how many frames to skip, and the subroutine would just repeatedly vsync. It's also -possible- that they were hardcore and just made a dummy loop that lagged the system for a certain amount of time. If you're able to trace like stated above, it should be easy enough. Otherwise, it -could- be a nightmare.

Resizing the sram sounds incredibly complicated. I think I'll stick to my SNES ways, and just modify a single byte ^_^ Sorry, I know that's not helping :/

As far as the windows, using a corrupter? >_<
Man... I could never tolerate doing that with an SNES game. I would imagine that would be a bad idea, though. The data to actually draw the window at all could be right in there, or asm code, too. And then everything would die. It would be hard to tell when you hit the right data.
Also, in Der Langrisser, all window data is hardcoded.
You want a 6x12 window?
lda #$06 : sta $0010
lda #$0c : sta $0012
jsr draw_window
Perhaps you could get lucky by searching for things like lda #$<starting tile for old window size>, lda #$<number of tiles the window that DOES clip on the old window size>, etc.
If not, the lda bla,x and lda bla,y sound like good candidates to try next.
Hopefully it's the latter, as that would mean table. And table would mean you could easily resize all the window sprite mask regions you need quickly.

[KingMike]

I think, I HOPE I found the sprite clear data. :)
BETTER BE, I spent all day tracking it down in Nesten trace logs. :eplus2:
Around $29F20 in the expanded ROM ($9F20 in the original), there seems to be a bunch of 4-byte values. They look like they could be values for mask if (sprite X is greater than or equal to), (and X is less than), (and Y is greater than or equal to), (and Y is less than) respectively. I hacked one of the values and it seemed to do the intended job.

[byuu64]

Kickass. BTW the title screen idea you mentioned earlier sounds pretty cool. So then that only leaves the possibility of maybe speeding up text printing :D
I look forward to playing it and understanding more than just the menu options ;)

[KingMike]

Yep, I did find the data for clearing sprites. And I figured out (roughly) why the windows on the battle screen had remnants even after the window was closed. I guess the game doesn't like 3 or more windows piled on top of each other. Now I have to just move the windows so they don't overlap.
Now I think there only some minute graphics bugs left. (2 VRAM issues, menu flickering, and if a window touches the left edge of the screen, the rightmost 16x16 tile's (on the line above) attribute (palette) goes wacky).

UPDATE! I've nearly finished the SRAM hack. It works, but it's kinda buggy (like the character reappears inside a wall, but getting anything to load is progress. Though it appears to only work with Waking Room saves, and not with Kupikupi's Save skill.
Actually, I could probably just hack the original routine, instead of a new one.
Replacing a few bytes, since fortunately, I'd need fewer bytes than the game uses.

I think these are functionally-equivalent WRAM/SRAM routines:

LDA #$80
STA $F800 (high bit = auto-increment on (1)/off (0), low 7 bits = address)
--------------------------
(STA $F800 gets replaced with a JSR)
should be functionally equivalent to
first time:
LDA #$00
STA $WRAM_LOW
LDA #$60
STA $WRAM_HIGH
RTS
on the second and so on readings, I would just STA to WRAM_LOW
(and of course adjust the values to reflect the high bit off)

LDA $somthing and LDA $something,X
STA $4800
---------------------------------------
(STA $4800 replaced with JSR to routine)
STA backup_of_loaded_value
TXA
PHA
LDX #$00
STA ($WRAM_LOW),X
INC WRAM_LOW
PLA
TAX
RTS

LDA $4800
STA $somewhere or STA $somewhere,X
----------------------------------------------
TXA
PHA
LDX #$00
LDA ($WRAM_LOW),X
INC WRAM_LOW
STA backup_value
PLA
TAX
LDA backup_value
RTS
(then the game returns to the original STA command)