Re: [MiNT] Future (was Re: MiNT 1.16)

[Johan Klockars <rand@cd.chalmers.se>]

> Generally, I tend to think, that software that modifies trap vectors
> should be loaded before MiNT. I even though of disabling the code that

Once MiNT is self-contained as far as GEMDOS/BIOS/XBIOS is concerned,
those earlier modified traps won't ever be called...

> > Privilege enforcement could be done inside fVDI, if necessary.
> 
> How would you check the privileges from outside the MiNT? AFAIK, an
> external program could do it only via trap calls, and this is sloooow :-)

There's no real need for a Trap to be slow. The trap itself is about
30 cycles on a 68000, 20 on an '030 and 16 on an '040.
If you're already in supervisor mode, like inside fVDI, you can fake
the trap a lot faster still (and MiNT could provide a directly
callable interface for kernel modules (perhaps it already does?)).

The design of TOS has not made it easy for MiNT, though, which makes
for some serious overhead. I'm sure it must be possible to improve
on the current state for at least certain operations, though.

By the way, I'm somewhat surprised that noone has done anything about
the calling methods. After all, there are lots of free traps that could
be used to provide a smarter interface to MiNT, for programs that are
aware of it. Enforce usermode only calls on the new traps and it should
be possible to simplify things significantly, I think.

> > IMO, the VDI definitely should not be part of MiNT (or any other
...
> This is the problem of answering the question, whether we want MiNT to be
> a complete self-contained OS, or rather we want it to rely on underlying

Why would anyone want that?

> components. In the first case it must contain VDI. Also, if MiNT would be

And an AES and a desktop, I presume?
How about a built-in web browser?

> self-contained, it would be more portable.

I'd break it into as small parts as possible, not having a single
thing built in that could be a device driver or similar.

> Let's face it, Atari hardware is dead. Eventhough these are great machines
> (if I thought something else, I wouldn't be using one of them to this time

I agree that it's dead, but not that they were ever great machines
(I still program mainly for them, though). Not that it matters.

> :-)), no new ones will get produced. So, if MiNT and GEM has to be
> preserved and avoid the death, it must migrate to another hardware. Petr's

Personally, I don't think there's much point in migrating GEM to other
hardware, as long as you can have native code drivers for graphics.
There simply isn't much else in there that takes any time worth
mentioning to execute, so emulation doesn't hurt much.
(I'm assuming you still want emulation for old applications, since I
 honestly don't see anything worth preserving in TOS/GEM themselves.)

For the time being, the same probably applies to MiNT itself, but if
virtual memory support ever comes to pass, that would change. I doubt
it would be possible to make JIT compilation work reasonably well
with MMU support.

> Aranym sounds very promising, but at the other hand the more functions

If you haven't tried it yet, I really recommend it.

> As for MiNT, it currently has a keyboard handler integrated, and it will
> get developed to completely replace the TOS code. If you want anything the
> handler could do for fvdi (the *.xdd version), just tell me. It is not

I've not looked deeply into what the VDI actually expects from the
mouse/keyboard yet (there are some decidedly strange functions), but
I'll check out the EmuTOS VDI code.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |
                        | so hard to do |  WWW:      http://217.215.149.49
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)