Old Regen pages
Moderator: AamirM
Hi,
I think I still haven't got this completely right. It will slow down the DAC in Mega Turrican. But I think it has somthing to do with trace feature of 68k (trace exceptions). I think that is not being emulated correctly. I will look at it again though and will get back with the results.
stay safe,
AamirM
I think I still haven't got this completely right. It will slow down the DAC in Mega Turrican. But I think it has somthing to do with trace feature of 68k (trace exceptions). I think that is not being emulated correctly. I will look at it again though and will get back with the results.
stay safe,
AamirM
no, this is properly handled by musahshi, here's the C sourcecode:Chilly Willy wrote:According to Motorola, the DBcc instruction has three conditions on the timing:Eke wrote: nice finding, thanks, but it also seems to me that the last musashi core was emulating this instruction correctly, or at least, like described in 68k docs, i.e 12 cycles +/- 2 extra cycles depending on the compare result... so what was wrong ?
1) cc is true - 12 cycles
2) cc is false, and the count has not expired - 10 cycles
3) cc is false, but the count has expired - 14 cycles
I suspect the CPU core probably just handled cc being true or false without handling the count condition.
M68KMAKE_OP(dbf, 16, ., .)
{
uint* r_dst = &DY;
uint res = MASK_OUT_ABOVE_16(*r_dst - 1);
*r_dst = MASK_OUT_BELOW_16(*r_dst) | res;
if(res != 0xffff)
{
uint offset = OPER_I_16();
REG_PC -= 2;
m68ki_trace_t0(); /* auto-disable (see m68kcpu.h) */
m68ki_branch_16(offset);
USE_CYCLES(CYC_DBCC_F_NOEXP);
return;
}
REG_PC += 2;
USE_CYCLES(CYC_DBCC_F_EXP);
}
with:
so thi stakes clearly 10 cycles when the counter is not expired and 14 cycles when counter expires (condition is always FALSE with DBF)default cycle is 12 in op table
CYC_DBCC_F_NOEXP = -2
CYC_DBCC_F_EXP = +2
In Zero the Kamikaze, incrementing the default cycle for DBF (DBRA) to 14 (this makes 12 and 16 cycles) simply delay certains CRAM write that should not occur at the end of a scanline but during the next scanline
00004CF8 MOVE.L $00FF1202,A0
00004CFE MOVE.L #$C0360000,$00C00004
00004D08 MOVEQ #$12,D0
00004D0A DBRA D0,$00004D0A <--- wait loop
00004D0E MOVE.W (A0)+,$00C00000
This is what cause the flickering in the sky
I didn't look into Pacman 2 yet...
I can confirm original Musashi handles all 3 cases correctly (i.e. the way docs say).I suspect the CPU core probably just handled cc being true or false without handling the count condition.
Don't know how you got this idea, but I've looked at this too, and it surely doesn't do trace. In fact, I haven't encountered any game which would do that.AamirM wrote:But I think it has somthing to do with trace feature of 68k (trace exceptions). I think that is not being emulated correctly.
-
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States
Hi,notaz wrote:I can confirm original Musashi handles all 3 cases correctly (i.e. the way docs say).I suspect the CPU core probably just handled cc being true or false without handling the count condition.
Don't know how you got this idea, but I've looked at this too, and it surely doesn't do trace. In fact, I haven't encountered any game which would do that.AamirM wrote:But I think it has somthing to do with trace feature of 68k (trace exceptions). I think that is not being emulated correctly.
Yes, no trace. I was going in the wrong direction. Still haven't figured out the correct solution. I have very less time these days.
stay safe,
AamirM
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Don't search on 68000 core, problem is timing and specially interrupts timings. I spent *many* time with them on Gens. I adjusted them probably more than hundred time, a single cycle can fix more 1 or 2 games but break 3 others :-/ Today i know my timings are almost completly wrong, i had just luck with all my adjustements and fudges...AamirM wrote:Hi,notaz wrote:I can confirm original Musashi handles all 3 cases correctly (i.e. the way docs say).I suspect the CPU core probably just handled cc being true or false without handling the count condition.
Don't know how you got this idea, but I've looked at this too, and it surely doesn't do trace. In fact, I haven't encountered any game which would do that.AamirM wrote:But I think it has somthing to do with trace feature of 68k (trace exceptions). I think that is not being emulated correctly.
Yes, no trace. I was going in the wrong direction. Still haven't figured out the correct solution. I have very less time these days.
stay safe,
AamirM
exactly, this is something that i still driving me crazy, just to fix one game sometime
For me, the most difficult is still getting the exact occurence of HINT regarding to HBLANK, and also HBLANK exact duration,so we could render the line in the emulator at the exact moment when all required settings (i.e VDP writes) for the line are supposed to have occured.
HCounter values regarding those events (HINT,VINT,HBLANK, Vcounter increment...) would also be useful for the few games using this
For me, the most difficult is still getting the exact occurence of HINT regarding to HBLANK, and also HBLANK exact duration,so we could render the line in the emulator at the exact moment when all required settings (i.e VDP writes) for the line are supposed to have occured.
HCounter values regarding those events (HINT,VINT,HBLANK, Vcounter increment...) would also be useful for the few games using this
Found that on ReGen site:
-Loading a ROM from the Load ROM dialog then loading a cheat for the game, causes the Load ROM window to open at the Cheats folder, not the ROMs folder. Possible Vista-only issue. Needs To Be Confirmed By Others On Vista
Yup, confirmed. Running under Vista x64 sp1 w/o elevated access rights.
-Loading a ROM from the Load ROM dialog then loading a cheat for the game, causes the Load ROM window to open at the Cheats folder, not the ROMs folder. Possible Vista-only issue. Needs To Be Confirmed By Others On Vista
Yup, confirmed. Running under Vista x64 sp1 w/o elevated access rights.
-
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States
Hi,King Of Chaos wrote:Aamir's Regen site is done, comments are appreciated.
http://aamirm.hacking-cult.org/
I have said this already and saying it again. Nice job! Although I think it would look even better if there was a way to move the search option some other place.
@ Zoomer
Thanks for confirming. I better start doing some testing on Vista.
stay safe,
AamirM
-
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States
-
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States