|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
Hong Kil Dong debugging
Posted: Thu Mar 26, 2015 11:01 am Last edited by Bock on Mon Apr 06, 2015 9:05 am; edited 1 time in total |
This appears to be an original Korean title.
ROM appears to be 48 KB. I don't have access to the original cartridge anymore but I know a person in Japan who. The game appears to crash after the first boss throw a bullet. Would be nice to find out if it's an emulation issue, a bug in the game or a problem with the dump? (normally the 48 KB are correct and I should have verified them multiple times, in the haste I could have made a mistake. It could be that there is a mapper that I have overlooked at the time of dumping). It decrement life by writing at E090, there's two locations you can NOP out to make yourself invincible. Included three MEKA savestates: - S00 right before boss shooting - S01 end of level 1 because transitioning to the boss scene - S02 i don't remember what it is.. it scrolls and shows glitches but I'm not sure if I was running hacked version or wrong emulation at the time. |
|
|
Posted: Thu Mar 26, 2015 9:00 pm |
Looks like an emulation issue of the R register.
It looks like in MEKA, for each instruction, R is incremented by the instruction's cycle count, except for ld a, r which increment by an extra +1 which makes it 10 (instruction is 9 cycles) Game gets stuck in this loop at $318c, if R unfortunately happens to be a multiple of 4 at the beginning of the loop: foo: ld a, r and $03 cp $00 jr z, foo each instruction increments R by: 10, 7, 7 and 12 (jump is taken since A is a multiple of 4) for a total of 32, so in this loop "ld a, r" is equivalent to "add a, $20" so A is always a multiple of 4 and we never get out of the loop. I looked at the Z80 manual, and the behavior of R is defined thus: " Seven bits of this 8-bit register are automatically incremented after each instruction fetch. The eighth bit remains as programmed, resulting from an LD R, A instruction" This page http://www.worldofspectrum.org/faq/reference/z80reference.htm gives more details about the incrementation rule: " The R register is a counter that is updated during every Z80 M1 cycle (approximately equivalent to every instruction), so long as DD, FD, ED and CB are to be regarded as separate instructions, so shifted instructions increase R by two. There's an interesting exception: doubly-shifted opcodes, the DD CB and FD CB ones, also increase R by two. LDI increases R by two, LDIR increases it by 2 times BC, as does LDDR etcetera. R is set to zero when the Z80 is reset. Both LD A,R and LD R,A use the value of R after it has been increased (eg an XOR A/LD R,A sequence sets the value of R to zero, and [reset]/DI/LD A,R sets A to 0x03)." With this rule, and because LD A, R is encoded with the ED prefix, the R increment for each instruction would now be: 2, 1, 1, 1 for a total of 5, and since LD A, R uses the value post-increment, this works. |
|
|
Posted: Thu Mar 26, 2015 9:31 pm |
Thanks, and thanks for digging into details.
The emulation of R in Meka is completely broken. Good news is that it means the dump is correct (and the fix shouldn't be too hard). I'll probably just copy what MAME does. |
|
|
Posted: Fri Mar 27, 2015 9:29 am |
Found an issue in a piece of the code that sets volumes on sound channels:
L0258: ; E = bitmask (1 = silence channel, 0 = max channel) ld l, a ld a, e and $07 ; we keep only low 3 bits of data ld b, (hl) ; (each bit corresponds to one channel, to turn it off or max volume) ld (hl), a ; write the new version in RAM xor b ; and compare with the old jr z, L027E ; if they are the same, we are only changing the volume of noise channel ld a, e ld bc, $0300 | PSG_Port ld d, $10 L0267: rra ; if bit is 1 for this channel, h = $0f (silence), else h = $00 (max vol.) jr c, L026E ld h, $00 jr L0270 L026E: ld h, $0f L0270: adc a, b ; ??? ld a, $80 ; PSG latch mode add a, d ; type volume, and channel # (on first iteration, 0, then 1, then 2) add a, h out (c), a ; output volume for this channel to PSG ld a, d add a, $20 ld d, a ; update mask for next channel ex af, af' djnz L0267 The adc a, b instruction is useless and non-sensical, what you need instead is an ex af, af' to match the one at the bottom of the loop. This code is actually called frequently (near the end of the interrupt handler), and "adc a,b" and "ex af. af' " are so different in text form, but have relatively close opcodes ($88 vs. $08) ... Place your bets: soju programming or a bump in the dump? :P |
|
|
Posted: Fri Mar 27, 2015 10:16 am |
SMS Bubble Bobble also contains a loop which polls the R register, and can similarly "lock up" in MEKA. See this post. |
|
|
Posted: Fri Mar 27, 2015 10:25 am Last edited by Bock on Mon Apr 06, 2015 9:32 am; edited 1 time in total |
Thanks a bunch. Overlooked that thread. It's quite embarassing frankly. Looks like we can fix it this week-end (calindro is actually looking at it right now, and I may have time this week-end). It's a bit of a miracle that MEKA even works by looking at the codebase. | |
|
Posted: Sat Mar 28, 2015 9:03 pm |
If you are going to work on it, maybe you can take the opportunity to also add full support for graphics modes 1 & 2 in the Tiles Viewer and Tilemap Viewer? Right now the Tiles Viewer only shows up to 512 tiles but graphics 2 supports up to 768. Also Tiles Viewer doesn't seem to use the color table (even though the game screen view seems to use it properly) I am sure it's super low on your todo list but I mention it just in case :P |
|
|
Posted: Tue Mar 31, 2015 7:59 pm |
Fixed R emulation
https://github.com/ocornut/meka/commit/5768f5a36d8f3372dc73a334f07bb4d6d63f82a9 segmtfault: will do at some point.! *EDIT* Actually the tile viewer for video mode render VRAM as raw tiles regardless of the pattern generator registers. There is a slider to select which 4 KB to render. If you don't see if you are probably using an old version of Meka pre 0.8x branch. Working on Meka is really tedious, such as old messy codebase. I want to replace it with ImGui at some point and will probably delete all the UI code and rewrite them in a sensible way. |
|
|
Posted: Tue Mar 31, 2015 11:43 pm |
Ah yes you are right, I am on 0.7x. I should go grab a 0.8x version from the testing thread or even better get off my lazy ass and grab and build the source from the github :P |
|
|
Posted: Wed Apr 01, 2015 8:29 am |
Either way the latest 0.8x are a vast improvement (for debugging tools) over 0.7x | |
|
Posted: Mon Apr 06, 2015 9:31 am |
Thanks all for your help! The dump is now publicly available
http://www.smspower.org/forums/15446-HongKilDongKRPaperboy2ProtoGG |
|
|
Posted: Mon Apr 06, 2015 8:37 pm |
Would someone be interested in creating a patch for Hong Kil Dong that removes that horrible clicking noise when a sfx or music plays?
...Just an idea :) best regards, - dink |
|
|
Posted: Tue Apr 07, 2015 1:08 pm |
I got around to trying it with the new version, but the game still glitches out on me. I can beat the first boss now, but then the second stage starts empty of enemies and treasure chests. Enemies eventually appear, but at the same time the level starts getting messed up. Treasure chests never appear, and in the end the level becomes just a wall of broken tiles, mostly numbers (see screenshot). When I die the level starts with enemies, but still no treasure chests and the same symptoms as I go along.
From the screenshot in the announcements it seems obvious that there is a way to start level 2 properly (at least with treasure chests), but I've played from the beginning three times now, and it was always broken, so I have no idea what causes this. |
|
|
Posted: Thu Apr 09, 2015 3:08 am |
I now tried in Fusion, cause it was mentioned in the news post, and there it works without problems, so I guess it's another emulation issue in MEKA | |
|
Posted: Thu Apr 09, 2015 9:51 am |
Do you have Fusion set to PAL? With TV Type set to PAL/SECAM in MEKA the problem doesn't occur. Was this game possibly developed on a system running at 50 Hz? |
|
|
Posted: Thu Apr 09, 2015 10:39 am |
That'd be odd. Also I don't recall switching to PAL in my own playthrough but I may have done so involuntary.
Where is the point where the glitch is "locked" and we can't change emulation settings to save it from happening? It NTSC/PAL actually making the difference? It would be good to understand exactly what's going on. |
|
|
Posted: Thu Apr 09, 2015 10:57 am |
I've both emulators set to 60Hz. | |
|
Posted: Thu Apr 09, 2015 11:30 am |
What would be odd?
The game locks scrolling when the boss appears so without monsters there's no boss and without boss the scrolling continues beyond the level. The result is garbage in the nametable scrolling in. When I load your savestate and kill the boss with PAL I get monsters in the 2nd level, if I set it to NTSC there are no monsters in the 2nd level.
With the savestate I still don't get enemies when I die so it might as well be an issue of the savestate. Can you provide a Meka savestate in the boss screen? |
|
|
Posted: Thu Apr 09, 2015 12:25 pm |
It would be odd that the game was programmed for 50 Hz. Extremely unlikely.
*EDIT* Here's 4 savestates, two during the boss, one while it is exploding. The last one is close to the boss being defeated, I can't repro with either NTSC or PAL settings. |
|
|
Posted: Thu Apr 09, 2015 12:32 pm |
Btw the S02 on the frist post of this thread is a save that Derboo sent me a long time ago, I don't know how it came to be. | |
|
Posted: Thu Apr 09, 2015 12:57 pm |
Did you just play up to there again? It's the same with these states. If I set TV type to PAL I'm getting enemies and chests, if I set it to NTSC there are no enemies and no chests. Also if I die without monsters there are still no monsters. |
|
|
Posted: Thu Apr 09, 2015 1:45 pm |
No I didn't play from stratch, they are all based on an older savestate. | |
|
Posted: Thu Apr 09, 2015 6:00 pm |
The problem is a stack overflow causing variables to be overwritten.
The game's function to set the VDP address is surrounded by a di/ei pair and is called from within the interrupt handler. This causes the interrupt handler to already re-enable interrupts before it has finished its work. Very often an interrupt occurs at this point causing the interrupt handler to be called again inside the other interrupt handler. This doesn't harm yet. The actual harm comes from another interrupt occurring inside the already nested interrupt handler. This causes the stack to overflow into the variables range. This is what happens when the 2nd stage starts. Now I need to find out why the inner interrupt handler takes longer than usually. Edit: I've noticed 2 other issues: - When I get killed by the boss I respawn at the beginning of the level but the scrolling is still locked so the player is caught at the beginning of the level. - When I spam button presses during the loading screen the first stage often starts without enemies as well. (It's the same issue as described above. A stack overflow overwriting the variables.) I start wondering if the game actually works on real hardware. Would be great if anyone could try. You can replace the opcode at $1107 to NOP to become invincible. |
|
|
Posted: Sat Apr 11, 2015 9:18 pm |
Hmm unfortunately I just noticed that my Japanese SMS won't work with the TV I have here (I have a backup screen but it's packed right now).
I tried with an European SMS (50 Hz). I couldn't repro the "mash button on start gets you no enemies". I killed the boss and Stage 2 seemed to work here. Obviously if it is a timing issue 50 hz would severely affect it. Anybody else could test on a Japanese or Korean system? - mashing the button to start - dying during the first boss - clear the first level |
|
|
Posted: Sun Apr 12, 2015 9:44 am |
Same as on emulators. Those problems only arise when run at 60 Hz. So testing it on any 60 Hz system should help already. |
|
|
Posted: Sun Apr 12, 2015 8:28 pm |
I tested the game on my SMS1 PAL with 60hz switch.
On my play-through I did not have any enemies in level 2. |
|
|
Posted: Sun Apr 12, 2015 8:45 pm |
Some clarifications from Calindro, the overflow appears to only happens at certain points:
"The overflow also happens on the titlescreen but doesn't seem to harm there then it happens right before 2nd stage starts" About the variables in question "I think they are timers something like enemy spawn timer maybe If I remember correctly monsters get spawned only if it hits 0" "I played through the first stage on RetroArch using Genesis Plus GX core, MESS, Fusion, Meka and Emulicious All except Fusion had no monsters in 2nd stage" |
|
|
Posted: Sun Apr 12, 2015 9:11 pm |
My intuition is that the timing could vary depending on player's action and perhaps the bug doesn't happens every time? | |
|
Posted: Sun Apr 12, 2015 9:14 pm |
I wonder what Fusion does differently? | |
|
Posted: Sun Apr 12, 2015 9:15 pm |
Tzz stop quoting me like this... I told you this information is vague and I'm gonna start a more detailed investigation when I have more time... :( The quote:
was my answer to your question:
Edit: You can watch the overflow by entering "w w c0d7" in Meka
I suspect inaccuracy. I tried to find out but couldn't find anything obvious yet. Did you also notice that the game lags a lot on Fusion? |
|