View Single Post
Old 05 August 2014, 11:43   #6
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 986
Quote:
Originally Posted by Toni Wilen View Post
F60008 bits 2 and 3 are most likely PPC to M68K interrupt output enable and active bit (just like bits 0 and 1 are enable/active bits for SCSI interrupt), causing m68k int level 2 when both are active.
Just realized that I have no information about the bits P5_REG_ENABLE at all. Is this correct?
Code:
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?


Quote:
Originally Posted by Toni Wilen View Post
It seems INT_LVL isn't for allowing/not allowing interrupts, I think it is used to activate PPC interrupt: If any bit 0 to 6 is active in INT_LVL AND IPL_EMU is less than any active INT_LVL interrupt number AND P5_ENABLE_IPL is active: PPC CPU interrupt line becomes active. (active as in bit is cleared, active low).
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?


Quote:
This allows WarpOS test to work. It sets INT_LVL to 0x7f (all inactive), enables P5_ENABLE_IPL, sets IPL_EMU to 7 (IPL level 0). Later when 68k code wants to wake up PPC code, it clears INT_LVL bit 0. PPC interrupt code runs which sets it back to one.
So this is probably the only kind of interrupt the PPC has to handle under WarpOS?


Quote:
btw, I guess this method only works when 68K is interrupt master. (68k gets "real" Paula interrupts)
So P5_INT_MASTER is 1 under WarpOS, as expected?
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. I guess that P5_ENABLE_IPL was inactive, when INT_LVL was used to store keycodes?
phx is offline  
 
Page generated in 0.05306 seconds with 9 queries