=========================================================================

INFO-ATARI16 Digest         Wed, 11 Apr 90       Volume 90 : Issue  436
 
Today's Topics:
                              'POOLFIX4'
                             Atari Japan
                           micro-emacs 3.10
                    MIDI at 500KHz ... IT WORKS!!!
                      Moving hardware to Europe
                   My experiences with PC-Ditto II
                             re-direction
                  yet another screen saver question
----------------------------------------------------------------------
 
Date: Wed, 11 Apr 90 11:16 N
From: <MFAGKCHR%HMARL5.BITNET@Forsythe.Stanford.EDU>
Subject: 'POOLFIX4'
 
ONM07%DMSWWU1A.BITNET@CUNYVM.CUNY.EDU (Julian Reschke) writes:
 
(much deleted)
 
>There is no reason why a hard disk driver should revector TRAP #1!!!
 
>> As always, users are forced to do the patching themselves. In this...
>Patch Your OWN brain-damaged software! :-)
 
>___________________________ cut here _____________________________________
>Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241
>eMail: ONM07@DMSWWU1A.BITNET, "Julian Reschke" @ MAUS MS  (++49 251 77216)
>____________________ correct me if I'm wrong _____________________________
 
I did post this readme file. Claus Brod does not read this newsgroup.
So he will not be able to react.
 
However, *I THINK* I know why CBHD redirects TRAP #1. With this driver
you can boot from all harddisk partitions. Which means that:
 
1) All auto folder programs are read from the boot partition
2) The same goes for the ACC's
3) And for the DESKTOP.INF
 
4) If you save the desktop it is saved on the boot partition.
 
The latter is new in CBHD 3.5. Formerly the desktop.inf was allways saved
on C. I think Claus had to redirect the TRAP #1 vector to make this possible.
Is there another way?
 
==============================================================
Dept. of Occup. &                    Chris Evelo
Environm. Health                     MFAGKCHR@HMARL5 (BITNET)
and Toxicology.
University of Limburg                Tel: 31-43-888635
P.O. Box 616                         Fax: 31-43-436080
6200 MD Maastricht
The Netherlands
==============================================================
 
------------------------------
 
Date: 11 Apr 90 03:24:54 GMT
From: voder!pyramid!cbmvax!daveh@ucbvax.Berkeley.EDU  (Dave Haynie)
Subject: Atari Japan
Message-ID: <10773@cbmvax.commodore.com>
 
In article <2856@sactoh0.UUCP> mfolivo@sactoh0.UUCP (Mark F. Newton) writes:
>I had read in comp.sci.japan that Commodore Japan closed it's
>doors, and it got me to thinking, how is Atari Japan doing? I have
>seen an article about the Atari Lynx in a Japanese magazine, but
>that's all I have seen about Atari in Japan.
 
Commodore Japan is still in existence, though they did down-size a few
years back.  Commodore hasn't marketed computers in Japan; the Japanese
office was used for purchasing and production engineering up until around
the time the C128 and Amiga 1000 were introduced.  Most of the production
engineering for Commodore is now done in the US and Germany.  The office
in Japan is now used for purchasing.  The reasoning for this is obvious:
doing any kind of business in Japan these days is just plain expensive.
 
>                             Mark Newton-John
 
--
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   ?uunet|pyramid|rutgers?!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough
 
------------------------------
 
Date: 11 Apr 90 07:35:01 GMT
From: mcsun!inria!irisa!decouty@uunet.uu.net  (Bertrand DECOUTY, Atelier, AB112,
 p. 430)
Subject: micro-emacs 3.10
Message-ID: <1990Apr11.073501.6680@irisa.fr>
 
In article <11572@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu)
 writes:
| In article <2657@calvin.cs.mcgill.ca> depeche@calvin.cs.mcgill.ca (Sam Alan
 EZUST) writes:
| %on atari st 3.10, this is not recognized. I put it in my emacs.rc,
| %do describe-bindings, see it listed there, and del still does a delete-left.
| %I do a bind-to-key delete-next-character and then hit the <DEL> key,
| %and for the duration of my session, it works fine.
| %I do a describe bindings, and I see
| %
| %bind-to-key delete-next-character ~?
| %bind-to-key delete-next-character ~?
| %
| %so obviously, the ~? I created in the session and the one in the
| %emacs.rc file are not the same.
|
| Just use the quote character. (In gulam/ue, this is ctrl-Q. It's probably
| the same in most other emacs' as well.) Edit your emacs.rc file and type
|       (Ctrl-Q)(Delete) and you'll see '~?' echoed.
| --
|   -- Howard Chu @ University of Michigan
 
 
In emacs3.10, you must use the 2 characters sequence ~ and ? in
startup file (.emacsrc, emacs.rc). It is clearly written in 3.10 doc, page
 15-29:
"... control D character in the startup file is represented visibly as an
uparrow key followed by a capital D." (to explain a bind-to-key using ~D).
 
This works for me, under various machines. ~Q<del> did not work.
 
Bertrand Decouty
 
--
$ Bertrand DECOUTY             | EMAIL : decouty@irisa.fr, decouty@irisa.uucp  $
$ IRISA - INRIA (Atelier)      |         ?uunet,mcvax,inria?!irisa!decouty     $
$ Campus de Beaulieu           | PHONE : +33  99 36 20 00                      $
$ F-35042 Rennes Cedex - FRANCE| FAX : +33  99 38 38 32 | TELEX: 950473 UNIRISA$
 
------------------------------
 
Date: 10 Apr 90 17:27:50 GMT
From: ingr!b11!jmack@uunet.uu.net  (Cery McCormick)
Subject: MIDI at 500KHz ... IT WORKS!!!
Message-ID: <7809@b11.ingr.com>
 
>       You can disable the interrupts quite easily; just mask off the
> appropriate bits on the MMU (I think that's the chip; it's one of those)
> and all interrupts will be ignored.  Or you can re-vector them to short
> little routines that increment a counter and return.  I'd suggest the
> former, because it probably doesn't matter whether the machine keeps
> track of, say, mouse movement while data is being transmitted.
 
        The way to insure that NO interrupts are serviced (including
MMU), is to mask off the interrupt bits in the STATUS register.  I have
written a program to talk to the old 8-bit atari SIO bus through the
printer port which required that I read the port every 52.2 usec
(19.2kbaud).  The disabling of all interrupts worked very well in this
case.  The biggest drawback however is that the mouse is temporarily
frozen.
 
------------------------------
 
Date: 11 Apr 90 08:47:27 GMT
From:
 zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!cs325ec@tut.cis.o
 hio-state.edu  (Gregory Lemperle-Kerr)
Subject: Moving hardware to Europe
Message-ID: <1990Apr11.084727.22399@ux1.cso.uiuc.edu>
 
        I live in Switzerland and study in the USA, and have had no problems
        using a step down transformer to run monochrome, but in colour,
        I replace the TOS chip with one available at most dealers over
        there that changes the move #sync,$ffff820a instruction.
 
        -- Greg
 
------------------------------
 
Date: 11 Apr 90 04:44:18 GMT
From:
 pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ni
 c.MR.NET!ns!logajan@tut.cis.ohio-state.edu  (John Logajan)
Subject: My experiences with PC-Ditto II
Message-ID: <1990Apr11.044418.29687@ns.network.com>
 
lawrence@isc-br.ISC-BR.COM (Lawrence Kelley) writes:
>It does seem like a heat problem, but I have trouble beleiving the 68000
>generates enough heat to put much stress on those connector pins.
 
Logic circuits (poorly designed) ARE subject to heat.  The propogation
delays get worse and the logic voltage levels degrade.  This can put
poorly designed circuits over the edge.
 
Since PC-DITTO-II supposedly had timing problems initially, perhaps this
is just a borderline symptom.  Then again, it could be something completely
different.
 
--
- John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428
- logajan@ns.network.com, john@logajan.mn.org, 612-424-4888, Fax 424-2853
 
------------------------------
 
Date: 11 Apr 90 08:14:44 GMT
From: eru!luth!sunic!mcsun!unido!laura!heike!klute@bloom-beacon.mit.edu  (Rainer
 Klute)
Subject: re-direction
Message-ID: <2094@laura.UUCP>
 
In article <1602@electro.UUCP>, ignac@electro.UUCP (Ignac Kolenko) writes:
|>
|>what is the "official" method of doing io-redirection in software.
|>what i want is for program A to run. It prints to the screen using Cconws();.
|>In the course of running A, it will invoke B, which also prints with Cconws.
|>Before B is called, the user has the option of redirecting B's
|>output anywhere (screen, printer, file, modem). After B runs, control is
|>returned to A, which will then continue printing to the screen as before.
 
 
Here is what I use in Arcgsh for io redirection to call Zoo (hence
some names) as a dependend program (partly cited). "zoo_stdin" and
"zoo_stdout" are filenames, the "...descriptors" are ints, STDIN is 0
and STDOUT is 1.
 
/*      redirect standard input:        */
save_stdin_descriptor = Fdup (STDIN);
my_stdin_descriptor = Fopen (zoo_stdin, 0);
if (my_stdin_descriptor >= 0)
        Fforce (STDIN, my_stdin_descriptor);
 
/*      redirect standard output:       */
save_stdout_descriptor = Fdup (STDOUT);
if (append_to_stdout_file)
        ?
        my_stdout_descriptor = Fopen (zoo_stdout, 2);
        if (my_stdout_descriptor >= 0)
           Fseek (0L, my_stdout_descriptor, 2);
        else
           my_stdout_descriptor = Fcreate (zoo_stdout, 0);
        ?
else
        my_stdout_descriptor = Fcreate (zoo_stdout, 0);
if (my_stdout_descriptor >= 0)
        Fforce (STDOUT, my_stdout_descriptor);
 
/*      call the program now... */
 
/*      undo the redirections:  */
Fforce (STDIN, save_stdin_descriptor);
Fclose (my_stdin_descriptor);
Fforce (STDOUT, save_stdout_descriptor);
Fclose (my_stdout_descriptor);
 
  Dipl.-Inform. Rainer Klute      klute@heike.informatik.uni-dortmund.de
  Univ. Dortmund, IRB             klute@unido.uucp, klute@unido.bitnet
  Postfach 500500         |)|/    ...uunet!mcvax!unido!klute
D-4600 Dortmund 50        |\|\    Tel.: +49 231 755-4663
 
------------------------------
 
Date: Wed, 11 Apr 90 14:45+0200
From: Ritzert%DMZRZU71.BITNET@Forsythe.Stanford.EDU
Subject: yet another screen saver question
Message-ID: <900411124545.239107@DMZRZU71-UNI-MAINZ--GERMANY>
 
I am the one who asked the original quesiton. I would like to sum up the
answers and thank every contributor.
 
>...I wouldn't leave monitors on all the time, screen saver or no
>screen saver. The constant heat from the power supply etc will
>eventually dry out the electrolytic capacitors. It happens quite
>regularly with other makes (such as our Phillips-made Apollo 19" mono
>jobs)
 
Statements like these meet my own experience. I know of an installation
of about 70-80 STs, where the monitors are left on all the time. The
people frequently encounter monitor problems due to defect electrlytic
capacitors. There are a handfull problematic parts especially in the
"horizontal offset controller" (Horizontalablenkstufe). Among them are
C 915 (my own monitor), C 711 (had to be replaced in our old model sm124
in the office) and a few others. Some of these parts could easily be
replaced by non-electrolytic capacitors to increase the long term
stability of the sm124. Hey Atari, this is Your job!
 
My conclusion from all the contributions:
 
Switch the monitor off when You are running a long and stable job (like
Metafont or long compilations). The time should be measurable in hours.
Then it will be harmless to both the ST and the monitor.
The argument that switching electronic equipment on and off frequently
could damage the equipment is surely true. But in the case of a tv or
computer monitor frequently means every few minutes, like a screen
saver and not every few hours. So I think it is useful to do both
things: install a screen saver program (something like idle12 or pyro)
and switch the monitor off when You don't need it for a long time.
 
Thanks,
Michael Ritzert
mjr@dmzrzu71.bitnet
 
------------------------------
 
End of INFO-ATARI16 Digest V90 Issue #436
*****************************************
