[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Future (was Re: MiNT 1.16)
> 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.
Yeps, but in reply to my mail :-)
> > 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.
Great. But MiNT which does not boot from the bootsector doesn't in fact
really need that. At the other hand, if we want MiNT to boot (not just
load from auto), a form of hddriver inside is necessary.
> 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.
Yes, but the fvdi, IIRC, is loaded AFTER MiNT. This means, that MiNT
doesn't have control on the VDI trap. So, everyone who telnets to you, can
use your VDI, even if he's a restricted user. This is baaaad :-)
Of course, this also applies to NVDI, currently.
Apart of that, I don't see why an 'integrated vdi' cannot be modular
simultaneously. The integrated part would be just a VDI kernel (even fvdi
has a kernel, right?) plus most basic driver(s). The rest would have to be
loaded from the disk.
> > 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.
This is discussable :-)
> 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.
Sounds bad. Which compiler has such a startup code? BTW. in an extreme
case, fixing this could be automated (a program which patches this), but I
of course admit this would be harmful for everyone of us.
> Seems like giving up on virtual memory would be easier than patching all
> of our TOS software base :)
I.e. we have to drop the progress in this direction and stay with bad
programs forever. Not good.
--
Konrad M.Kokoszkiewicz
mail: draco@atari.org
http://draco.atari.org
** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospolstwa, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.