View Single Post
Old 05 August 2014, 17:19   #8
Toni Wilen
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 20,657
Originally Posted by phx View Post
Just realized that I have no information about the bits P5_REG_ENABLE at all. Is this correct?
Bit 7 set/clear
Bit 3 PPC to M68k interrupt request? (active low?)
Bit 2 PPC to M68k interrupt enable (active low?)
Bit 1 SCSI interrupt request (active low?)
Bit 0 SCSI interrupt enable (active low?)
Both interrupts are mapped to the level 2 interrupt line?
I think so. Only proof I have so far is powerup interrupt handler code (level 2) that exists immediately if bit 2 or bit 3 is not cleared. (Same test method as SCSI river does, only different bits). If both are cleared, request bit is set and interrupt is handed.

Ok, great! That could make sense.
So P5_ENABLE_IPL=0 enables the function of IPL_EMU and INT_LVL. But which part of IPL_EMU are you talking about? M68K_IPL or PPC_IPL?
PPC_IPL (low 3 bits). I think M68K_IPL is always mirror of m68k physical line state.

So this is probably the only kind of interrupt the PPC has to handle under WarpOS?
Probably. It sets level 1 interrupt (SOFT, INTENA bit 2) and PPC code simply writes 0x8004 to INTREQ when it wants to interrupt m68k. Very simple and basic stuff here.

So P5_INT_MASTER is 1 under WarpOS, as expected?
Yes. m68k is always master, warpos or powerup. (at least so far it seems to be true)

The INT_LVL bits are always set to 0x7f under OS4 and NetBSD. No idea what happens when you manipulate them there with a PPC interrupt master.
Thats a good question but should be easy to test, write something to INT_LVL and see if kernel complains about spurious interrupts?

I guess that P5_ENABLE_IPL was inactive, when INT_LVL was used to store keycodes?
Yes and PPC CPU is also in stopped state (reset line active) until first PPC program gets executed so it shouldn't matter even if ENABLE_IPL is active.
Toni Wilen is online now  
Page generated in 0.18222 seconds with 9 queries