[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] update:WRITE_BOOT,ALLOW_TRP_CHG
Peter Persson, 04.10.2012 14:57:25:
Currently all Setexc are blocked. Of course it can be changed, but only
if
there is another reason to do so.
It is also used to access the GEM system vectors etc. I don't know how
"clean" this is nowadays, but it's probably the "cleanest" way to
install a VBL timer service.
Ok - guess I'll change this:
- only block trap-vector-change
- implement a mode for Ssystem to ask for the status
- add that VBR-thing. How would you call Setexc to change it, so I know
how to block it?
Me neither. XBRA offers the next address in the vector chain + a 4
byte ASCII name of the app. The problem with it is that it is still up
to the coder to traverse the vector chain when removing your trap
patch, and generally people tend to forget that part.
The only way to have it foolproof would be to always block these
addresses, but then you'd certainly lose too much features.
I think there are, or used to be, some dead/commented-out code for
this. At least I've seen some document in the CVS which describes
parts of a possible implementation, don't know if it's in source or
txt form though. Maybe it has been removed.
Never seen something like that.
It would be extremely neat to have this on the AES level, since it
could enable windowed applications to detect multiple simultaneous
keypresses. I made it possible to run several of my emulator ports in
Once the kernel has such an interface (Xbconin ;-)), I guess using it in
the AES is no big deal.
No, VBR. Vector Base Register. It determines the location of the trap
vectors in memory. On 68000, it's implicitly zero since there is no
VBR, but on 010+ it can be changed.
Where is it?
--
Helmut Karlowski