GP2X Drz80 Disscusion

[FluBBa]

My mail account is acting up again and I though maybe me, Reesy, Franxis & Pepone can use this space here for some disscusion instead of talking 1 on 1 all the time.

Franxis: I've got some questions regarding the Previous PC in your additions. What is it's purpose? Isn't it only for dealing with the EI opcode so that you don't do interrups directly after it? And why update cycle_pointer all the time?
Have this fixed any games yet?

I wanted to add an extra variable for the cycles to be able to return the correct amount of executed cycles but I didn't think it had to be that complicated?

Reesy, Pepone! what do you say?

 

[Reesy]

Pepone is having problems with DrZ80. He's added this to DrZ80 to support NMIs, looks okay to me. Anyone else spot anything wrong in there?

DoInterrupt:
ldrb r0,[cpucontext,#z80irq]
tst r0,r0
moveq pc,lr

tst r0,#2                         ;@ NMI interrupt
bne DoInterrupt_NMI

ldrb r0,[cpucontext,#z80if]
tst r0,#1
moveq pc,lr;@ exit if int disabled


....
SNIP
....


DoInterrupt_NMI:
stmfd sp!,{lr}

bic r0,r0,#2
strb r0,[cpucontext,#z80irq]

ldrb r0,[cpucontext,#z80if]
tst r0,#4;@ check halt
addne z80pc,z80pc,#1

;@ clear halt
bic r0,r0,#5
;@mov r0,r0,lsl #1
strb r0,[cpucontext,#z80if]

ldr r0,[cpucontext,#z80pc_base]
sub r0,z80pc,r0
.if FAST_Z80SP
mov r1,r0, lsr #8
strb r1,[z80sp,#-1]!
strb r0,[z80sp,#-1]!
.else
sub z80sp,z80sp,#2
mov r1,z80sp
writemem16
.endif
;@ jump to vector
mov r0,#0x66
rebasepc

b DoInterrupt_end

 

[FluBBa]

Ummm, I tried to fix the bitstuff for HALT flag, but I must've been sleeping when I looked at it.

It should probably look something like this:

;@ clear IFF2 & halt, copy IFF1 to IFF2
	bic r0,r0,#Z80_IF2|Z80_HALT
	mov r0,r0,lsl#1
	strb r0,[cpucontext,#z80if]

 

[pepone]

Ummm, I tried to fix the bitstuff for HALT flag, but I must've been sleeping when I looked at it.

It should probably look something like this:

;@ clear IFF2 & halt, copy IFF1 to IFF2
	bic r0,r0,#Z80_IF2|Z80_HALT
	mov r0,r0,lsl#1
	strb r0,[cpucontext,#z80if]

​

I think I've try every combination for this one. Doesn't help for now.
I wonder if the problem is really here...

On the speed side, it's really encouraging. Drz80 make gngeo nearly 10fps faster.

 

[FluBBa]

On the speed side, it's really encouraging. Drz80 make gngeo nearly 10fps faster.

​

Holy s*! :blink:
That's what I wanted to hear Now I know what I'm working toward.
I'll try to read up on how the NeoGeo works in the Z80 department.

If you haven't update drz80_inerf.c, this may have some relevance as well:

void cpu_z80_nmi(void)
{
	printf("Cause NMI\n");
	mydrz80.Z80_IRQ = 0x02;
}

I think you'd better do:
mydrz80.Z80_IRQ |= 0x02;
otherwise you'll clear the HALT flag as well. Same thing with the normal IRQ.

 

[pepone]

On the speed side, it's really encouraging. Drz80 make gngeo nearly 10fps faster.

​

Holy s*! :blink:
That's what I wanted to hear Now I know what I'm working toward.
I'll try to read up on how the NeoGeo works in the Z80 department.

If you haven't update drz80_inerf.c, this may have some relevance as well:

void cpu_z80_nmi(void)
{
	printf("Cause NMI\n");
	mydrz80.Z80_IRQ = 0x02;
}

I think you'd better do:
mydrz80.Z80_IRQ |= 0x02;
otherwise you'll clear the HALT flag as well. Same thing with the normal IRQ.

​

This is what I do now. But IIRC, Z80_IRQ has nothing to do with the halt flags (Z80_IF).
Since DrZ80 now work with the neogeo under mame, I'm now sure it's a bug on my side. But I just don't understand the way interrupt are handled with it.
I've put a snapshot of gngeo source here:
http://m.peponas.free.fr/gngeo/download/gn...20060306.tar.gz

 

[BradN]

I'm not 100% sure if it's the same context as what I'm thinking, but doesn't an interrupt bring the chip out of halt mode?

 

[FluBBa]

This is what I do now. But IIRC, Z80_IRQ has nothing to do with the halt flags (Z80_IF).
Since DrZ80 now work with the neogeo under mame, I'm now sure it's a bug on my side. But I just don't understand the way interrupt are handled with it.
I've put a snapshot of gngeo source here:
http://m.peponas.free.fr/gngeo/download/gn...20060306.tar.gz

​

It seems I'm still sleeping, don't know why I confuse the 2 all the time...
I'll check the new source.
BradN: yes an interrupt gets you out of halt mode, that's why you just can't clear the halt bit without actually moving the cpu out of halt and executing the interrupt.

 

[Franxis]

My mail account is acting up again and I though maybe me, Reesy, Franxis & Pepone can use this space here for some disscusion instead of talking 1 on 1 all the time.

Franxis: I've got some questions regarding the Previous PC in your additions. What is it's purpose? Isn't it only for dealing with the EI opcode so that you don't do interrups directly after it? And why update cycle_pointer all the time?
Have this fixed any games yet?

I wanted to add an extra variable for the cycles to be able to return the correct amount of executed cycles but I didn't think it had to be that complicated?

Reesy, Pepone! what do you say?

​

I keep updated PC (program counter), cycles (cycles pending to be executed) and previouspc (program counter of previous opcode). I solved some problems with PC and cycles, because those data accessed by MAME code, but the amount of games those need previouspc updated is very limited and still don't run. Maybe i have not undestand previouspc meaning correctly.

Conclusion: Delete my additions if you want i spend a little time to re-add again ;-) Don't worry about this code... :lol:

 

[FluBBa]

The cycles stuff you did was only to be able to report back the number of actuall executed cycles? because I have another way to do that, which only needs code in the start and end of DrZ80_Run... or should it do anything else? Are there any specific games that use it?

 

[slaanesh]

I've been experimenting with DrZ80 with the GP32 version of MAME.
I simply take the latest DrZ80 source from the GP2X version and plop it into MAME GP32.
Compatibility still seems low. Games that require two Z80s CPUs (excluding sound CPUs) seem to have a smaller chance of working - is there some sort of limit?

Is there somewhere where I can get latest builds/releases to test out changes to DrZ80? I'd be happy to do so.

There are some games that do work well, Franxis has mentioned them previously. 1943 Jap is great and so is Ghosts and Goblins.

Do the improvements Flubba made to get NeoGeo working have any known improvements to other MAME games?

BTW - no parle the Z80 - I used to be a 6502 guy... sorry.

 

[FluBBa]

I think the biggest problem with MAME is that it simulates a lot of the protection hardware instead of actually emulating it. They use the internal state of the Z80 outisde of it, which doesn't happen IRL. According to MAMEs z80 C version the Astrocade sound driver is dependant on 16bit IO, but depending on which version of MAME it was implemented wrong.

 

[pepone]

It seems I'm still sleeping, don't know why I confuse the 2 all the time...
I'll check the new source.

​

:lol:
I think I need a sleep too! the bug is just under my eyes since the very begining.
Look at it:

void drz80_write8(unsigned char data,unsigned short address) {
        if (address>=0xf800) drz80mem[address&0xFFFF]=data;
}
void drz80_write16(unsigned short data,unsigned short address) {
        drz80_write8(address, data & 0xFF);     // WRONG!!!!
        drz80_write8(address + 1, data >> 8);
}

instead of

void drz80_write8(unsigned char data,unsigned short address) {
        if (address>=0xf800) drz80mem[address&0xFFFF]=data;
}
void drz80_write16(unsigned short data,unsigned short address) {
        drz80_write8(data & 0xFF, address);      // GOOD :)))
        drz80_write8(data >> 8, address + 1);  
}

It's just that I allways write my mem handler with (address, data) for the param order.

Now, it seems to work perfectly I'll try to put a beta online tonight.

 

[Reesy]

yeah sorry about that. Is because when I first wrote DrZ80 it had all of the memory handlers built in so I didn't care which came first, so it ended up being data first, which is a bit back to front. Oh well glad you found the problem.

 

[pepone]

yeah sorry about that. Is because when I first wrote DrZ80 it had all of the memory handlers built in so I didn't care which came first, so it ended up being data first, which is a bit back to front. Oh well glad you found the problem.

​

I feel a little stupid to not find it before

 

[FluBBa]

Now, it seems to work perfectly I'll try to put a beta online tonight.

​

Sweeeeet
I've also optimised one the LD reg,reg and added some defines instead of raw values to the interrupt handler. But I think that can wait 'till later.

 

[Franxis]

yeah sorry about that. Is because when I first wrote DrZ80 it had all of the memory handlers built in so I didn't care which came first, so it ended up being data first, which is a bit back to front. Oh well glad you found the problem.

​

I feel a little stupid to not find it before

​

Congrats Pepone!!! :lol:

 

[Franxis]

The cycles stuff you did was only to be able to report back the number of actuall executed cycles? because I have another way to do that, which only needs code in the start and end of DrZ80_Run... or should it do anything else? Are there any specific games that use it?

​

No, they are the pending to be executed cycles. When the DrZ80Run() is executed, 'cycles' is the total number of cycles to be executed. When the opcodes are executed, 'cycles' are decreased until it reachs to cero (0). 'Cycles' is a field used by MAME in some drivers. Look at cpuintrf.c library, they are functions to derive the number of actual executed cycles, etc...

Regards.

 

[FluBBa]

Are there any specific games that use it?

​

'Cycles' is a field used by MAME in some drivers.

​

So can you tell one of those "some" drivers?

 

[Flavor]

I'm interested in using the DrZ80 core in a project. Who should I talk to, and where should I get the core? I know it's other project's source tree, but I am not sure that's the best/latest one and I don't know if it has been modified for use in that specific app.

I'm also interested in a version that would report back how many cycles the emulation actually took. I saw some discussion about this, but I don't know if it's actually implemented. I haven't looked closely at the src, and I'm not really that good with ARM ASM.