Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 115
=========================================================================
INFO-ATARI16 Digest Mon, 29 Jan 90 Volume 90 : Issue 115
Today's Topics:
Monitor Burnout/ Should got a MAGNAVOX!
Problem with asm in MEGAMAX-C
Sozobon <time.h> question
Words of wisdom on MWC behaviour needed
----------------------------------------------------------------------
Date: 29 Jan 90 02:24:36 GMT
From: dsl.pitt.edu!pitt!cuphub!kar7481@PT.CS.CMU.EDU (Dan
Karbowsky;AtariEliteOfPghPa bbs412-384-5609)
Subject: Monitor Burnout/ Should got a MAGNAVOX!
Message-ID: <3694@cuphub.cup.edu>
In article <15294@orstcs.CS.ORST.EDU>, warningm@prism.cs.orst.edu
(MICHAEL WARNING) writes:
> My monitor (SM1224) was acting flakey for a week or so when all of the
> sudden it decided to completely die on me. I traced the problems to what
> seems to be one bad part in the power supply (the board number is TH901).
> could somebody tell me exactly what the thing is and where I can get a new
> one so I can replace it?
>
> Mike Warning
> warningm@prism.cs.orst.edu
You Shoulda gotten a MAGNAVOX 14" 8cm515 monitor...
2 years Parts/Labor included--standard warranty!!!
Has ANALOG-RGB, TTL-RGB, and COMPOSITE (I'm on my 124 now watching Cinemax
on my MAGNAVOX....)
640x240 resolution.....great for TV-useage via a VCR or as a monitor.
BEST PART: Only runs round $239.00 compared for what I hear mos dealers
asking for a 1224!
Just thought I'd mention an affordable alternative to the netbase....
+-----------------------------------------------------------------------------+
| Dan Karbowsky kar7481@pitt!cuphub / S U P P O R T T H E S T ! ! ! |
| 102 Lee Drive ___________________/Call the ATARI ELITE of PITTSBURGH'S |
| Belle Vernon, PA / BBS (Forem-ST,fnet node 19) at (412) 384-5609 at 300 |
| 15012 U.S.A. / thru 19.2k baud 24 hrs./day 7-days/week Mention this |
| / message at logon. |
+-----------------------------------------------------------------------------+
------------------------------
Date: Mon, 29 Jan 90 10:20:47 GMT
From: Michael Mueller <K298027%CZHRZU1A.BITNET@CUNYVM.CUNY.EDU>
Subject: Problem with asm in MEGAMAX-C
I'm usually progamming in C, but sometimes I need to code some routines in
assembler. As I am working with the MEGAMAX-C compiler this is very
easy. Now my problem:
asm ?
init: move.l #1234,A0
move.l #init,A0 ; this is not accepted !!!!!
bra init ; this is OK
?
Why is the second mnemonic not accepted ? Has anybody an idea how to use
labelled adresses ?
---------------
Michael Mueller, Brain Research Institute, Zuerich, Switzerland
EARN/BITNET: K298027@CZHRZU1A.BITNET
------------------------------
Date: 29 Jan 90 07:17:20 GMT
From: cs.umn.edu!thelake!steve@ub.d.umn.edu (Steve Yelvington)
Subject: Sozobon <time.h> question
Message-ID: <0029900117203830@thelake.mn.org>
[In article <9001272330.aa22145@BRL-VGR.APG-EMH5.APG.ARMY.MIL>,
ddavis@APG-EMH5.APG.ARMY.MIL (Dave Davis) writes ... ]
>
> Can anyone supply a short example of working code which uses the
> 'start_timer' and 'time_since' functions? I've been playing around
> trying to time the execution of some code, but haven't been able to get
> a working program as of yet. (Probably due to a lack of understanding
> of the correct syntax needed). Thanks in advance!
>
This is why it's good to have a copy of the sources to dLibs, and keep
them handy. timer.c, the module that defines start_timer and time_since,
also includes the source code for two functions that call start_timer and
time_since. For those who don't have the sources, here is the relevant
module:
#include <time.h>
clock_t clock()
/*
* Return current value of 200Hz timer. This is the ANSI compatible
* timer function. The number of seconds elapsed between two events
* can be determined by calling this function twice and dividing the
* difference between the two times by CLK_TCK (200L).
*/
?
asm(" clr.l -(sp) ");
asm(" move.w #$20,-(sp) ");
asm(" trap #1 "); /* enter supervisor mode */
asm(" addq.l #6,sp ");
asm(" move.l $4BA,-(sp) "); /* save system clock value */
asm(" move.l d0,-(sp) ");
asm(" move.w #$20,-(sp) ");
asm(" trap #1 "); /* exit supervisor mode */
asm(" addq.l #6,sp ");
asm(" move.l (sp)+,d0 "); /* return system clock value */
?
clock_t start_timer(t)
clock_t *t;
/*
* Start a 200Hz timer. This timer value can later be checked with
* time_since() to determine elapsed time. These functions provide
* a very low-overhead way of timing events.
*/
?
asm(" clr.l -(sp) ");
asm(" move.w #$20,-(sp) ");
asm(" trap #1 "); /* enter supervisor mode */
asm(" addq.l #6,sp ");
asm(" move.l $4BA,-(sp) "); /* save system clock value */
asm(" move.l d0,-(sp) ");
asm(" move.w #$20,-(sp) ");
asm(" trap #1 "); /* exit supervisor mode */
asm(" addq.l #6,sp ");
asm(" move.l (sp)+,d0 ");
asm(" move.l $8(a6),a0 "); /* grab pointer to timer */
asm(" move.l d0,(a0) "); /* return clock value */
?
clock_t time_since(t)
clock_t *t;
/*
* Returns the number of 200Hz ticks since start_timer() was called
* for timer <t>.
*/
?
asm(" clr.l -(sp) ");
asm(" move.w #$20,-(sp) ");
asm(" trap #1 "); /* enter supervisor mode */
asm(" addq.l #6,sp ");
asm(" move.l $4BA,-(sp) "); /* save system clock value */
asm(" move.l d0,-(sp) ");
asm(" move.w #$20,-(sp) ");
asm(" trap #1 "); /* exit supervisor mode */
asm(" addq.l #6,sp ");
asm(" move.l (sp)+,d0 ");
asm(" move.l $8(a6),a0 "); /* grab pointer to timer */
asm(" sub.l (a0),d0 "); /* return elapsed time */
?
sleep(dt)
int dt;
/*
* Suspend operation for <dt> seconds. This is implemented as a
* start_timer()/time_since() tight loop waiting for the specified
* amount of time to pass. In a multi-tasking environment, this
* function should be replaced by a call which will de-activate
* this task for a period of time, allowing other tasks to run.
*/
?
clock_t t, start_timer(), time_since();
register clock_t tt;
tt = ((clock_t) dt) * CLK_TCK;
start_timer(&t);
while(time_since(&t) < tt)
;
?
usleep(dt)
int dt;
/*
* Suspend operation for <dt> microseconds. Works like sleep().
*/
?
clock_t t, start_timer(), time_since();
register clock_t tt;
tt = ((clock_t) dt) * (CLK_TCK / ((clock_t) 100));
start_timer(&t);
while(time_since(&t) < tt)
;
?
--
Steve Yelvington at the (thin ice today*) lake in Minnesota
UUCP path: ... umn-cs.cs.umn.edu!thelake!steve
*16 cars through the ice so far this year! Yes, you, too, can
have that sinking feeling....
------------------------------
Date: 29 Jan 90 07:34:50 GMT
From: cs.umn.edu!thelake!steve@ub.d.umn.edu (Steve Yelvington)
Subject: Words of wisdom on MWC behaviour needed
Message-ID: <0029900134503832@thelake.mn.org>
[In article <20216@watdragon.waterloo.edu>,
swklassen@tiger.waterloo.edu (Steven W. Klassen) writes ... ]
> In article <633294579.26980@myrias.com> mj@myrias.com (Michal Jaegermann)
writes:
>>
>>All test programs work beautifuly, echoing nicely input, until they
>>hit exit(). THE CRASH does not happen when there are run under msh, OR
>>when run under msh or gulam but were compiled with MWC-zed dLibs
>>libraries. But I need a floating point, which dLibs does not support.
>>An attempt to use MWC printf with dLibs was partially successful in
>>that the the program behaves nicely and exits in a clean manner but it
>>does not print anything at all (probalby due to incompatible internal
>>structures).
>
> To be honest I had a hard time understanding your post. Perhaps you
> could repost, rewording things so it is a bit clearer.
>
> One thing that I did understand is that you are having a problem
> printing floating point from MWC.
No, that's not what he said, and that's not the problem at all.
The floating-point problem stems from a version of dLibs converted for the
Mark Williams compiler. The use of dLibs was an attempt to avoid a system
crash that appeared to come from the MWC exit() function.
Michal wrote:
>Setting: Mega ST with TOS 1.4, gulam shell and MWC 3.0.6 compiler.
>Any program compiled with supplied MWC libraries which reads stdin.
>
>An attempt to redirect on a command line stdin to come from a file
>causes an 'exit()' routine to bomb out in the most interesting and
>unusual manner.
This gets down to the issue of redirected file handles that has been
mentioned recently in posts from Dale Schumacher, Allan Pratt and Ken
Badertscher.
The GEMdos way of redirecting standard file handles, Fforce(), is
unreliable at best and broken at worst. I've had all sorts of horrible
things happen lately because of it, *including* running out of memory. On
more than one occasion I've even been unable to launch coldboot.prg to
slap the system out of its silly state.
Mark Williams uses a strange method of passing extended arguments that
encodes redirection in environment variables. The child process then
handles any necessary redirection. The parent does not call Fforce() and
then exec the child.
MWC's workaround requires that both the parent and the child know about
the method and agree to use it. When you launch an MWC-compiled program
with the Mark Williams msh shell, the parent and child agree. If the
parent is not msh or running under msh, tough cookies.
Apparently gulam uses Fforce() to redirect input. There may be something
in the MWC exit() code that pushes TOS over the (very narrow) edge. You
might escape the grim reaper by calling _exit() or Pterm(). (Perhaps Dan
Glasser can provide some insight?)
Dale and John Stanley and J. Bammi have been kicking around a really nifty
(if you like black magic) workaround that allows the parent to cleverly
change file handles around **in the child's context** just before the
child begins to run. It appears to fix ALL these problems without
requiring that the child process know anything about the method.
I'm not going to even try to describe how it works, but since kbad has
more or less publicly blessed it, perhaps Dale or John will post some
code.
--
Steve Yelvington at the (thin ice today*) lake in Minnesota
UUCP path: ... umn-cs.cs.umn.edu!thelake!steve
*16 cars through the ice so far this year! Yes, you, too, can
have that sinking feeling....
------------------------------
End of INFO-ATARI16 Digest V90 Issue #115
*****************************************
