Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven.umd.edu!mimsy!nocusuhs!nmrdc1!minixug!arrakis!bert
From: bert@arrakis.nl.mugnet.org (Bert Laverman)
Newsgroups: comp.os.minix
Subject: Re: Minix-ST keyboard / mouse / clock
Message-ID: <91060111345@arrakis.nl.mugnet.org>
Date: 1 Jun 91 11:01:32 GMT
Organization: Alphasoft Nederland
Lines: 55

adamd@rhi.hi.is (Adam David) writes:
> If I have understood correctly, this implies that the 6301 keyboard processor
> does not clear its internal RAM when it receives a reset pulse from the ST.
> The rest of my comments here depend on this being true.
The simplest way to check this is with one of the many TOS clock programs.
I did this: reboot to TOS, set time, reboot to Minix, reboot to TOS. The
IKBD clock was still active and counting (and correct :-)).

> In <1747@targon.UUCP> gert@targon.UUCP (Gert Kanis) writes:
> >All those clocks keep the right time even if you switch the computer off.
> >The Atari keyboard (processor) clock keeps the *right* time only if
> >a) you set it first (once every power up)
> >b) you don't power down.
> Very true.
I would comment: extremely true ;-)

> >So it could be of limited use for those who don't have
> >a REAL real time clock :-)  (and reboot a lot).
> I propose that it is extremely useful for systems without a battery-backed
> clock, Minix is quite capable of being rebooted without switching off the
> power to the ST (see below).
Hear hear! I rarely switch my ST off these days, but reboots do happen
(especially when trying kernel changes ;-)). Sometimes these reboots happen
so aften I get a little pissed at having to type date & time again and
again (partly caused by the somewhat silly format date(1) requires).

> You seem to have missed the patch which was posted around this time for making
> a controlled reboot on CTRL-ALT-DEL reset or when the reset button is pressed.
> I think I lost my copy but it's real easy to figure out from scratch. 
I haven't seen it as a patch. But it's in 1.5.10, unless this patch fixes the
bug that disables rebooting when starting Minix with MINIX.PRG from TOS,
in which case I'ld be interested (be it mildly. I have Minix as auto-boot
on my HD, thanks to the stpart utility).

By the by, I _did_ build a driver that enables using a readclock(1) to
read the ikbd clock. I tested it, and that part works fine. This new
driver also creates devices for the mouse and joystick (though the latter
isn't activated), and has a /dev/kbd that could be used some time in the
future to split the keyboard from the tty stuff. The mouse driver currently
uses the absolute mouse mode which is stable but silly. (main disadvantage
is that reads allways succeed, so you can't let a program wait on mouse
events) I plan on trying relative mode soon.
  The main problem with this new driver is that stfloppy starts acting
up. For some (unfathomable) reason calls by FS (prompted by a sync(2)
no doubt) to do SCATTERED_IO sometimes fail. debugging prints show that
certain fields in the io request records get clobbered. I haven't had
any problems with the winchester driver, which makes it even more a mystery.

  If anyone is willing to help me find the cause, mail me.

Greetings, Bert

=====================================================================
    Bert Laverman		email: bert@arrakis.nl.mugnet.org
    tel.:  +31 50 - 733587	   or: laverman@cs.rug.nl
=====================================================================