Re: [MiNT] update:WRITE_BOOT,ALLOW_TRP_CHG

[Peter Persson <pep.fishmoose@gmail.com>]

2012/10/4 Helmut Karlowski <helmut.karlowski@ish.de>:
>> Hmm... could you elaborate this a bit? Ssystem() offers stuff like
>> S_SETLVAL/S_GETLVAL to read the supervisor protected area, and so does
>
>
> Right - did not know about these. But it only allows to change addresses
> between 0x420 and 0xfffc. I guess the traps are below 0x420, so either this
> needs another treatment or could be handled by ALLOW_TRP_CHG? Not sure.

Oh, I thought it could be used to read any protected address. My bad.

Personally, I think it would be great if ALLOW_TRP_CHG just did what
it sounds ilke - permit/reject access to trap vectors. Don't know if
it should take the VBR into consideration; probably not since it would
ruin the possibility to run this stuff in some imaginary
virtualisation framework.

>> So how does Ssystem() change the behavior of Setexc()? Is this something
>> new?
>
> Ssystem(S_ALLOW_TRP_CHG, arg, 0);

ok ok, sounds good.

>> Probably a good idea, since "dirty" is often "the cleanest possible
>> way to do it" on this platform, since we lack APIs & proper mechanisms
>
> I cannot imagine a situation where it is possible to change the traps in
> serious usage.

Let's say you wish to install a new VDI or extend the XBIOS, or even
have access to make/break keyboard data (needed to detect multiple
simultaneous keypresses, which is a complete must if you want to play
games or emulators). These things aren't possible without adding
entries to the trap vector chains. XBRA exists for a reason :)

I wouldn't mind if there was an easy to use mechanism for this though,
one that could be cleaned up if the application crashes or for some
other reason gets killed.

I know Odd Skancke had some ideas for make/break keyboard codes
through evnt_mult()/evnt_keyboard(), but it was never implemented. So
right now, the only way to achieve that is to do something nasty.

Or maybe one could implement a device (/dev) for this kind of stuff. I
did so for joystick/joypads, but people wasn't satisfied with the API
at that point (it used the Linux v1.0 API, which is state-based, while
people wanted the v2 API, which is event-based. In retrospect,
"people" were right, but then again, "people" never wrote a driver).

-- PeP