Re: [MiNT] MiNT on Coldfire

[Norman Feske <nf2@inf.tu-dresden.de>]

Dear Frank,

> You speak against yourself :-) You already complained in private e-mails 
> about all the hazzle and ugly code we have in bios.c and biosfs.c that 
> is necessary to use the TOS-BIOS devices. It's slow and inefficient too 
> as the BIOS device are not interrupt driven and need to be polled.

Yes. This is true. The code in bios.c and biosfs.c is really
shocking. But the interface that is actually used as 'backend'
of biosfs is quite small. (only a dozen system calls and some
system variables - as I documented in my article) A replacement
of bios.c and biosfs.c could use the same interface during the
startup (until native drivers are loaded via a driver module).

> E.g. all the reasons for implementing native drivers for the serial 
> ports you can perfectly apply to the remaining console device too.

But then, you needed to include routines for init video (for the
different platforms), drawing characters (for the different video modes)
etc. into the MiNT kernel just for starting it up. Wouldn't it be nicer
to leave all this crap to a boot-loader and care about these things when
the rest of the kernel is up and running?

> Btw. FreeMiNT already catch keyboard input by hacking into TOS, just to 
> catch ctr-alt-del (I'm sure you aggree that this is a very good idea) 
> and for scan code mapping (keyboard language mapping).

I have not looked about the ctr-alt-del handling but
I noticed the keytbl-thing. But this is no hack at all.
You use a well documented system call (Keytbl) to request
the keyboard tables, which is just great.

> For a new hardware you always need to write new drivers. And things are 
> much easier if you use and advanced interface to the kernel instead 
> using a single-tasking designed API from TOS from the year 1985.

Yes, of course. I strongly agree with you. MiNT needs
to provide decent driver interfaces. My argumentation was
just about the bootstrapping. For the actual working-state,
I wish to have custom drivers for all devices, managed by
the MiNT kernel.

For example, once the MiNT kernel booted up, it should
take over the serial interface (by an optionally loadable
driver), which was previously just used as boot-console
and managed by the boot loader.

> You do this over which interface? TOS-BIOS?

MiNT requests the Iorec buffer for the keyboard from
TOS via the Iorec system call and then polls it periodically
within _mint_vbl. In my serial interrupt, I just feed
this Iorec buffer. That is all - much easier than I
thought.

Greetings,
Norman