M68000 CPU type question

[AnimaInCorpore]

Hello guys,

while going through the PacMania sources some weeks ago I've found this strange part:

Code Select Expand

movea.l a0,a0
bne.s   LABEL

Obviously the purpose is to check if the address register A0 is set. However, typically the movea opcode doesn't affect the status register at all so I had to change this to cmp.l #0,a0.

So does anyone know what special kind of CPU has the X68000 compared to the standard M68000 types used in the Atari and Amiga machines?

Cheers
Sascha

[lydux]

Hi Anima,

I doubt such a common instruction could have a different behavior in x68000 than other m68k based machine...

The CPU that equip all X68000 in twin-tower models is an 68000 from Hitachi in PDIP package. For Compact XVI, it's the classic 68000 from Motorola in PLCC. The manufacturer choice is just a matter of form factor.

But just to be sure, I've checked on real hardware, and I confirm that as expected MOVEA.L A0,A0 does not affect any SR flags.

Maybe the comparison is related to an earlier instruction in your code flow, or the movea is here as a dummy instruction for an applied patch that will skip the bne ?


Good luck with your project !

[AnimaInCorpore]

Hi Anima,

I doubt such a common instruction could have a different behavior in x68000 than other m68k based machine...

The CPU that equip all X68000 in twin-tower models is an 68000 from Hitachi in PDIP package. For Compact XVI, it's the classic 68000 from Motorola in PLCC. The manufacturer choice is just a matter of form factor.

But just to be sure, I've checked on real hardware, and I confirm that as expected MOVEA.L A0,A0 does not affect any SR flags.

Maybe the comparison is related to an earlier instruction in your code flow, or the movea is here as a dummy instruction for an applied patch that will skip the bne ?


Good luck with your project !

Thanks for the testing.

This is where it appears. A 'simple' VDISP handler initialization subroutine.

Code Select Expand

SET_VDISP_HANDLER:
movea.l %A0,%A0
bne.s   L_00030908

lea     NULL_VDISP_HANDLER(%pc),%A0
L_00030908:
move    %sr,-(%A7)
ori     #0b0000011100000000,%sr
move.l  %A0,0x118
move    (%A7)+,%sr

rts

NULL_VDISP_HANDLER:
rte


So in conclusion it's most likely a bug.

I was also in doubt that this behaviour is different on the X68000 but I wondered why the appropriate VDISP routine was never set on the ported code. So it seems that it was only an unfortunate situation.

Cheers
Sascha

[lydux]

Humm...
You have probably found the result of a disabled code ported from the arcade version to the x68000 !
Most of the time, the change of an interrupt handler is done via the iocscall B_INTVCS (syscall 128), or doscall INTVCS (instruction 0xff25). So there is no need to write such a function.

Of course, this is just an assumption... Have you checked for a prior call to those system routines ?

Also, the vdisp handler might also be contain somewhere within a previously loaded human68k driver ! Be sure to check there too.

Or just leave your patched code... This is better I think : portable !

[AnimaInCorpore]

Humm...
You have probably found the result of a disabled code ported from the arcade version to the x68000 !
Most of the time, the change of an interrupt handler is done via the iocscall B_INTVCS (syscall 128), or doscall INTVCS (instruction 0xff25). So there is no need to write such a function.

Of course, this is just an assumption... Have you checked for a prior call to those system routines ?

Also, the vdisp handler might also be contain somewhere within a previously loaded human68k driver ! Be sure to check there too.

Or just leave your patched code... This is better I think : portable !

Well, don't get me wrong: PacMania X68000 already runs on the Atari and the subroutine is indeed in use but the desired handler was never set without the 'patch'.

Cheers
Sascha

[lydux]

Yes, I have seen your video. Nice job !

Anyway, I will remember this thread and if one day, I would like to play pac-mania, I will give an eye on the vdisp vector. Could be a bug as well for us yes...