[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Pá, 2002-11-01 at 15:15, Konrad M. Kokoszkiewicz wrote:
> Ok, but since I was asked (you said 'you', Petr, and English doesn't
> distinguish between 'you guys on the group' and 'you Konrad', so I think
> it was me who was asked; correct me if I am misled).

I am glad you asked but to be honest I originally meant "you" as in "you
all MiNT developers" - that's why I posted it to the list. I thought
that I would get several answers since each developer might have a
different view on the topic. So far only you answered so I am thankful
for that.

> So, since I was asked, I could try to describe the future as I see it.
> Naturally Frank can see it differently, and his sentence always prevails,
> because he is THE COORDINATOR :-) and a very good one, btw.

Sure. That's why I've been awaiting also his answer.

> The next step will be to design, write and integrate the hard disk driver,
> the VDI and a mouse accelerator (yes!)

As for writing and integrating the harddisk driver - I have nearly done
that yesterday, for aranym at least. It was just a matter of exporting
the XHDI interface from aranym via EmuTOS to MiNT.

As for integrating VDI and mouse accelerator, well. I have my mouse
accelerator in Clocky ;-) And fVDI (what else VDI would you integrate?)
is probably better on its own. At least Johan, its author, seems to like
the modularity better.

> The next step could be make MiNT up so that it could boot directly from
> the boot partition bootsector. This means we will probably have to build a
> simple bootselector, something like a lilo, which could allow to boot MiNT
> or TOS depending of the requirements.

I don't see the need for this. 

> In conjunction with Aranym all this would result in a simple, small and
> elegant Unix-like OS for everyone

Sounds great. BTW, right now I have no problem with booting EmuTOS and
running MiNT from the AUTO folder. But if you feel like booting from
MILO is the key, then why not :-)

> I hope Aranym works stable?

It's hell more stable than my Falcon with Afterburner :) Actually it's
as stable as the host machine is.

> because I will probably get my first 'any machine' and I definitely am
> decided to use Aranym on it.

great news.

> Anyways, there are still problems MiNT suffers. This is for example
> programs, which grab interrupt vectors. Such a program cannot be killed,
> because the system crashes then. On the other hand, there is no real way
> to prevent programs from grabbing vectors, because there is no harmless
> way to control what programs do after Super() or Supexec(). This is why
> supermode is so bad. This (supercalls) is probably the main problem of
> people who ever tried to implement virtual memory for MiNT.

If we wanted to get rid of supercalls we would have to patch each and
every existing program. You have no idea how many programs run an FPU
check in their startup C library. And it's always the same - jump to
Super(), set up bus error vector, try FFFFFA42 (or what's the address),
restore bus error, return from Super. Virtually each program does that.

Seems like giving up on virtual memory would be easier than patching all
of our TOS software base :)