klamer@mi.eltn.utwente.nl (Klamer Schutte) (05/02/91)
The atari ST hardware supplies a keyboard proccessor for the user. This
keyboard proccessor has the following output:
1) key presses
2) mouse events
3) clock output.
4) joystick output
In the current minix setup, 2) and 3) are suppressed, 4) is discarded
(in kernel/stkdb.h) and 1) is guided to the consoles. I now suggest the
following changes:
Let 1) go to the consoles as long as they are displayed. When a graphical
screen is displayed, let it go together with 2) and 4) to another
device (which can be a terminal in raw mode IMHO).
(graphical screen such as gscreen, posted recently by Bert Laverman).
This leaves us with 3). This one can be off use. It has a clock which keeps
counting as long as the hardware is not switched off. This means that its
value is kept between switches between minix and tos. (And thus between
reboots of minix *). Reading the value involves giving the command (easy)
and picking the BCD digits which give the answer from the keyboard processor
(also easy). But what to to with this output? A good choice is IMHO to
make another device (again ...) which reads this data. (And the same device
can be used to set it ). Another choice would be to do the conversion
from BCD to minix time in kernel space and incorporate the device in
the clock. This would be hairy because reading the keyboard clock is not
immediate; it involves one write and than a hardware interrupt to stkbd.c,
which than reads the data, which should go to the clock, which then is
ready. Yechh.
Comments, anyone???
Klamer
*) Where with normal minix it is not possible to reboot without switching
the machine off, this is not to difficult. All you have to do is set
memory position 0x426.l (from memory) to anything but 0x31415926
(from memory). This can be done by writing in /dev/mem.
I will post a (small, trivial) program to do this soon.
--
Klamer Schutte
Faculty of electrical engineering -- University of Twente, The Netherlands
klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamerbert@arrakis.nl.mugnet.org (Bert Laverman) (05/07/91)
In article <klamer.673169352@mi.eltn.utwente.nl>, klamer@mi.eltn.utwente.nl (Klamer Schutte) wrote: > The atari ST hardware supplies a keyboard proccessor for the user. This > keyboard proccessor has the following output: > 1) key presses > 2) mouse events > 3) clock output. > 4) joystick output > [ some lines deleted ] > This leaves us with 3). This one can be off use. It has a clock which keeps > counting as long as the hardware is not switched off. This means that its > value is kept between switches between minix and tos. (And thus between > reboots of minix *). Reading the value involves giving the command (easy) > and picking the BCD digits which give the answer from the keyboard processor > (also easy). But what to to with this output? A good choice is IMHO to > make another device (again ...) which reads this data. (And the same device > can be used to set it ). Another choice would be to do the conversion > from BCD to minix time in kernel space and incorporate the device in > the clock. This would be hairy because reading the keyboard clock is not > immediate; it involves one write and than a hardware interrupt to stkbd.c, > which than reads the data, which should go to the clock, which then is > ready. Yechh. > > Comments, anyone??? The PCers use a program called readclock, which reads their hardware RTC, and prints the result in MMDDYYHHMMSS format (or "-q" if the time is found to be zero) to stdout. Maybe something comparable is possible. Hardware level: ikbd interrupt driver Driver level: /dev/kbd, /dev/mouse, /dev/joystick and /dev/rtc. Looks feasable to me. Bert ===================================================================== Bert Laverman email: bert@arrakis.nl.mugnet.org tel.: +31 50 - 733587 or: laverman@cs.rug.nl =====================================================================
gert@targon.UUCP (Gert Kanis) (05/17/91)
In article <9105072564@arrakis.nl.mugnet.org> bert@arrakis.nl.mugnet.org (Bert Laverman) writes: >In article <klamer.673169352@mi.eltn.utwente.nl>, klamer@mi.eltn.utwente.nl (Klamer Schutte) wrote: >> The Atari ST hardware supplies a keyboard proccessor for the user. This >> keyboard proccessor has the following output: >> [..] >> 3) clock output. > >> [ some lines deleted ] > >> This leaves us with 3). This one can be of use. It has a clock which keeps >> counting as long as the hardware is not switched off. This means that its >> value is kept between switches between minix and tos. (And thus between >> reboots of minix *). >> >> Comments, anyone??? >The PCers use a program called readclock, which reads their hardware >RTC, and prints the result in MMDDYYHHMMSS format (or "-q" if the time >is found to be zero) to stdout. Maybe something comparable is possible. > > Bert Laverman email: bert@arrakis.nl.mugnet.org Accidentily we happen to even a couple of these program for different *real time* clocks. e.g. megarct (builtin clock of MEGA ST series) weiderct (add on of Weide Electronics), something for SUPRA clocks (found in some hard disks). 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. So it could be of limited use for those who don't have a REAL real time clock :-) (and reboot a lot). Cheerio, -- Gert Kanis, AP SWZ SWP +----------------------+ Siemens Nixdorf Information systems | I do not represent | P.O.box 29, 4130 EA Vianen, Netherlands. | anyone elses opinion.| E-mail: outside Europe: kanis.via@sni-usa.com +----------------------+ Europe: gert@targon.UUCP Alternative: kanis.via@sni.de
dave@msb.com (Dave Lockwood) (05/18/91)
In article <1747@targon.UUCP> gert@targon.UUCP (Gert Kanis) writes: [ list of unimpressive :-) real-time clock products for the ST deleted ] > 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. c) You have the "Time Saver" product which (using NiCd batteries) keeps the IKB clock live even if you switch the power off. > So it could be of limited use for those who don't have > a REAL real time clock :-) (and reboot a lot). I don't reboot alot, but as long as I use my machine for 3 hours a week, my IKB clock stays accurate. Wouldn't it be nice if Minix knew that. Cheers! -- "So many have bled for you...frozen cold | dave@msb.com (Dave Lockwood) ...or gone to particles not even enough | UUCP: ...!uupsi!mpoint!dave to find. You don't know the ways you | Sysop of Meetpoint Station BBS can die out here." C.J. Cherryh(Pyanfar) | cat flames | mail santa@north.pole
adamd@rhi.hi.is (Adam David) (05/19/91)
Klamer Schutte wrote about the IKBD processor in the ST: > It has a clock which keeps counting as long as the hardware is not > switched off. This means that its value is kept between switches > between minix and tos. (And thus between reboots of minix). 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. In <1747@targon.UUCP> gert@targon.UUCP (Gert Kanis) writes: [Bert Laverman mentioned RTC programs in PC Minix] >Accidentily we happen to even a couple of these program for different >*real time* clocks. e.g. megarct (builtin clock of MEGA ST series) >weiderct (add on of Weide Electronics), something for SUPRA clocks >(found in some hard disks). >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. >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). 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. It would simply ensure that the long word stored in the TOS system variables at $426 (resvalid) has the value $31415926 (resmagic), and the long word at $42A (resvector) points somewhere sensible like a reboot address for TOS or Minix. It may prove necessary to configure the TOS image base address (which varies between versions) into this setup. At offset $18 from this base is a long word which contains the default TOS date (after cold boot) in BCD format MMDDYYYY. If the IKBD date is sufficiently close to the default then the user will be prompted for the correct date. If this works and no-one else beats me to it or tells me not to, I will post the patch after a few days. -Adam David- adamd@rhi.hi.is
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (05/20/91)
bert@arrakis.nl.mugnet.org (Bert Laverman) wrote: > In article <klamer.673169352@mi.eltn.utwente.nl>, klamer@mi.eltn.utwente.nl (Klamer Schutte) wrote: >> The atari ST hardware supplies a keyboard proccessor for the user. This >> keyboard proccessor has the following output: >> 1) key presses >> 2) mouse events >> 3) clock output. >> 4) joystick output > >> [ some lines deleted ] >> Comments, anyone??? > The PCers use a program called readclock, which reads their hardware > RTC, and prints the result in MMDDYYHHMMSS format (or "-q" if the time > is found to be zero) to stdout. Maybe something comparable is possible. > > Hardware level: ikbd interrupt driver > Driver level: /dev/kbd, /dev/mouse, /dev/joystick and /dev/rtc. > > Looks feasable to me. hell- you even implemented it :-) Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands "An Operating System is what the _USERS_ think of it- me"
bert@arrakis.nl.mugnet.org (Bert Laverman) (05/22/91)
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) wrote: > bert@arrakis.nl.mugnet.org (Bert Laverman) wrote: >> Hardware level: ikbd interrupt driver >> Driver level: /dev/kbd, /dev/mouse, /dev/joystick and /dev/rtc. >> >> Looks feasable to me. > > hell- you even implemented it :-) Yeees, only to get a system that crashes on floppy use. :-( I admit; I have a working version of the above mentioned devices (apart from the joystick), and I even wrote a small readclock(1) that does the same as the AT one. This will allow STers to retain date/time over re-boots, even if they don't have a diskclock or Mega ST. The problem is that SCATTERED_IO requests from FS to the floppy driver now (sometimes) seems to be messed up: bad byte counts, silly block numbers, etc. I haven't the slightest idea how this problem is created. Appearently it doesn't happen for Harddisk requests. Typical situation where it goes wrong: "cp minix.img /dev/sd0". The effects range from error messages from FS, to attempts by the floppy drive head to escape from my drive. :-( I checked for interrupt problems, but that seems (no longer) to be the cause.... Ideas anyone? Greetings, Bert ===================================================================== Bert Laverman email: bert@arrakis.nl.mugnet.org tel.: +31 50 - 733587 or: laverman@cs.rug.nl =====================================================================
bert@arrakis.nl.mugnet.org (Bert Laverman) (06/01/91)
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 =====================================================================