Previous Thread
Next Thread
Print Thread
Page 2 of 3 1 2 3
Joined: Apr 2015
Posts: 387
E
Senior Member
OP Offline
Senior Member
E
Joined: Apr 2015
Posts: 387
Don't know about that. I distinctly remember the original board slowing down severely when things got busy (and speeding back up when the cause of slowdown was gone). This can be alleviated for the most part by overclocking the emulated cpu. Double Dragon suffered the same problem,

Joined: Apr 2004
Posts: 1,555
J
Very Senior Member
Offline
Very Senior Member
J
Joined: Apr 2004
Posts: 1,555
Originally Posted By Shoegazer
Ah right, that's too bad. Air Zonk is a lot of fun even if it's fairly derivative. It's an odd case because of how it's triggered - moving to a certain spot on the screen causes lockups. You got me as to how that kind of bug is manifest (my uneducated guess is that it's somehow timing related).


If you could somehow create an input file to reliably reproduce the problem then that will greatly help to discover what might be wrong in the code.

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
IIRC you just have to start the game: no inputs are recognized and no enemies appear... zonk just go on forever flying...

Joined: Dec 2004
Posts: 111
P
Senior Member
Offline
Senior Member
P
Joined: Dec 2004
Posts: 111
Originally Posted By EoceneMiacid
Don't know about that. I distinctly remember the original board slowing down severely when things got busy (and speeding back up when the cause of slowdown was gone). This can be alleviated for the most part by overclocking the emulated cpu. Double Dragon suffered the same problem,


Yeah, although at one point both Double Dragon and Double Dragon 2 ran far too slowly in MAME due to an interrupt issue with the sprite MCU. Xain'd Sleena may be worth checking in case there is indeed a similar issue.

Joined: Mar 2006
Posts: 1,059
Likes: 1
L
Very Senior Member
Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,059
Likes: 1
The sprite mcu in double dragon is still emulated as the wrong type in MAME, iirc.
It is emulated as an hd63701V0, P0 or R0 (28 or 40-pin dip package?), but the real chip is an HD637A01Y0 (sdip64 package) which has extra 8-bit i/o ports and different on-die peripherals and interrupt pin routing.

The most similar other hd6301 series mcu is the hd63701X0 which has less eprom, a different programming method, and some minor peripheral differences. Both parts are SDIP64 package.

Also, super dodge ball has another hd637A01Y0 on it which vastly underutilizes the mcu for a very simple program which reads inputs and activates a separate 'run' output for the 4 directions per player if a direction input gets double-tapped within a certain period of time. It also has a 'dumb' presence check it responds to. We currently HLE it, but we do have the code dumped from dr decap from about 5 years ago.

LN


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Joined: Mar 2006
Posts: 1,059
Likes: 1
L
Very Senior Member
Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,059
Likes: 1
Sorry for double post, but I quickly tested airzonk with the tg16 driver. As etabeta said, the game works up until gameplay is supposed to start, zonk's sprite freezes and doesn't respond to controls, and no enemies appear. The level continues scrolling, and music continues to play.

One thing I did note is that on the tg16 driver, the contents of the code memory window change when you scroll it, even if emulation is paused. (This doesn't happen at first, so there's clearly some banking going on. You'll have to excuse me since I'm not familiar with the details of the pce/tg16 hardware.) If this is some sort of open bus emulation which the debugger is interfering with, the code needs to guard against debugger access triggering on-read-do-something parts of the memory code.

Another possibly telling bit is there is some constant incrementing/etc going on with certain areas mapped into memory at 0x0A2000-0x0A20FF, particularly 0x0A20A0-0x0A20A1, which halts dead when the game softlocks.


IMPORTANT NOTE: Btw, I attempted to duplicate the freeze a second time by while the debugger was open and running and looking at the mem window at 0xA2xxx, hitting 'soft reset' in the menu after it softlocked. After that soft reset, and holding RIGHT on the controller during the stage opening, the game WORKED and was "playable"*! Maybe the game doesn't like ram to be inited the way we do on start or something? (edit: no, it is coordinate based, see below)

*The game will freeze again if your character moves to any coordinate on the TOP HALF of the screen. if you stay still at start, the game freezes, but you can move for a small period of time before this and can move down to the bottom half, and the game will not crash! If you then move to the top half later it will instantly crash. Very curious.

Further testing shows this only happens when the stage 1 parallax background stuff is active; when fighting the stage boss with a scrolling but non-parallax bg, you can move to the top of the screen with no ill effect. The same crash happens on stage 2 as well.

It seems to be stuck in an infinite loop when softlocked.

Interestingly, if you set a breakpoint at 41c4 while it is softlocked, and force the 'rts' at 41c6 to execute, MESS crashes! (sometimes. I had this happen exactly once.)

EDIT: This is as far as I can go with this for now, someone else will have to take over debugging this. frown

LN

Last edited by Lord Nightmare; 04/16/15 03:09 AM. Reason: add note

"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Joined: Feb 2006
Posts: 30
Member
Offline
Member
Joined: Feb 2006
Posts: 30
Air Zonk will lock up if line timing, in regards to RCR IRQ versus V-Blank IRQ, is significantly wrong.

Joined: Mar 2001
Posts: 16,806
Likes: 32
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,806
Likes: 32
Thanks Mednafen, I'd suspected something like that in a Shout Box discussion smile

Is there some good$docs-like documentation on the TG16 and what the timings should be?

Joined: Feb 2006
Posts: 30
Member
Offline
Member
Joined: Feb 2006
Posts: 30
Not that I know of.

RCR IRQ tends to occur sometime around the end of HDW, and V-Blank IRQ sometime around the beginning of HDW/end of HDS.

Last edited by Mednafen; 04/17/15 12:39 PM.
Joined: Mar 2001
Posts: 16,806
Likes: 32
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,806
Likes: 32
I haven't seen that particular terminology before. HDW is H-Blank and HDS is active display area?

Page 2 of 3 1 2 3

Link Copied to Clipboard
Who's Online Now
4 members (mixmaster, R. Belmont, 2 invisible), 27 guests, and 8 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,973
Posts117,882
Members5,001
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com