[comp.sys.amiga] Another 1.3 wish.

peter@sugar.UUCP (Peter DaSilva) (07/14/87)

How about a system calls "DisableRequestors();" or even a
"DisableRequestors(FindTask(0))" to disable any requestors
cause by your actions, so you can run the damn thing
unattended. The latter might be hard, but the former would
be easier. Might even be able to do an Amiga based mini
SCADA system. Pretty good sized market.
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)

bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (07/19/87)

In article <397@sugar.UUCP> Peter da Silva typed:
> How about a system calls "DisableRequestors();" or even a
> "DisableRequertors(FindTask(0))" to disable any requestors
> caused by your actions, so you can run the damn thing
> unattended. The latter might be hard, but the former would
> be easier. Might even be able to do an Amiga based mini
> SCADA system. Pretty good sized market.

I posted the equivalent of DisableRequestors() a while back to this very
newsgroup.  It took about 80 bytes of code.  A newer version of that program
is forthcoming.


> "DisableRequertors(FindTask(0))" 

This is even easier, in 68000:

----------------------------------------------------------
		move.l	4,a6		;Prepare to call the exec library
		suba.l	a1,a1		;Set A1 to zero
		jsrlib	FindTask	;FindProcess, really
		move.l	d0,MyProcess
;-- Disable requestors --
		move.l	pr_WindowPtr(MyProcess),WindowSave
		moveq	#-1,d0
		move.l	d0,pr_WindowPtr(MyProcess)

;
; Insert your code here...
;

;-- Restore requestors --
	       move.l  WindowSave,pr_WindowPtr(MyProcess)

----------------------------------------------------------

pr_WindowPtr can be found in the process structure.  It is described in the
AmigaDOS technical reference manual.  Also see the include file libraries/
dosextens.i.

Conversion of this routine to C is quite easy.


> Might even be able to do an Amiga based mini
> SCADA system. Pretty good sized market.

What's a SCADA system??? Please explain.

-----------------------------
|\ /|  . Ack! (NAK, EOT, SOH)
{o O} . 
( " )	bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
  U	"Success leads to stagnation; stagnation dgekin)kin)know!now

peter@sugar.UUCP (Peter da Silva) (07/26/87)

In article <8707190424.AA10158@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes:
> In article <397@sugar.UUCP> Peter da Silva typed:
> > How about a system calls "DisableRequestors();" or even a
> > "DisableRequertors(FindTask(0))" to disable any requestors
                                                ^^^
> > caused by your actions...
> 
> I posted the equivalent of DisableRequestors() a while back to this very
> newsgroup.  It took about 80 bytes of code.  A newer version of that program
> is forthcoming.

Please. As long as it's not something like:

> > "DisableRequertors(FindTask(0))" 
> 
> This is even easier, in 68000:
> 
> [change your pr_WindowPtr to 0]

That's nice, but it won't (as has been explained a thousand times) disable
system requestors (bad disk, disk full, etc...) caused by your actions.

[Flame-throwers on "stun", captain]

And why explain in 68000 code?

	MyProcess = FindTask(0);
	WindowSave = MyProcess->pr_WindowPtr;
	MyProcess->pr_WindowPtr = 0;

I bought this machine because the operating system requires an absolute
minimum mucking about in assembly. Ther's no reason on god's green earth
why that code had to be in assembly.

> Conversion of this routine to C is quite easy.

Right. da Silva's rule #0x7FFE: if conversion of some example from assembly
to some high level language is easy, then it should have been expressed
in high level language in the first place.

Fear not, you're in good company. Donald E. Knuth (yes, that Knuth) is one
of the worst offenders. His "Art of computer programming" is almost useless
for day-to-day use because of "MIX". I use Horowitz and Sahni, myself,
simply because I save the time it would have taken to convert from MIX to
anything real. Not to mention the fact that they are capable of actually
getting books published at a reasonable interval.

> > Might even be able to do an Amiga based mini
> > SCADA system. Pretty good sized market.
> 
> What's a SCADA system??? Please explain.

SCADA: Supervisory Control and Data Acquisition. It's real-time control with
no super tight response time requirements. Oilfeild, energy management, power
plant and chemical process control. Where you can wait half a second or so
without causing problems. Also known as soft real-time, to contrast it with
tight real-time tasks like jet engine controllers. AmigaDOS is a pretty good
soft real-time operating system.
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)

bryce@cogsci.berkeley.EDU (Bryce Nesbitt) (08/03/87)

In article <434@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>In article <>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes:
>>In article <397@sugar.UUCP> Peter da Silva typed:
>
>> [incoherent junk deleted]
>
>That's nice, but it won't (as has been explained a thousand times) disable
>system requestors [sic] (bad disk, disk full, etc...) caused by your actions.

Exactly.  As was explained a thousand times, setting pr_WindowPtr will NOT
ensure that a requester from some weird source might not show up.  I know this.

In fact, in that discussion it was decided that a program would be needed.
Apparently you missed something, because the program I posted ensures that
*all* requesters from *all* tasks are turned off when you want them off.  It
SetFunction()'s AutoRequest() and BuildSysRequest() and Cancel!'s them for
sure, every time.

Search backwards for the word "Cancel".  (from rn type "?cancel?rh").  Or look
to comp.sources.amiga and comp.binaries.amiga.

BTW:  Setting pr_WindowPtr will *not* catch most bad disk requesters, but
*will* catch disk full.  For some requesters it's probably impossible to
determine what actions, or set of actions, caused the problem.


>[Flame-throwers on "stun", captain]
>
>And why explain in 68000 code?

Probably because I wrote the requester canceling code in 68000 and was in that
frame of mind.  I program in C also, but not that day.


>	MyProcess = FindTask(0);
>	WindowSave = MyProcess->pr_WindowPtr;
>	MyProcess->pr_WindowPtr = 0;

That's an incorrect conversion.  To silence DOS generated requesters you set
that to -1.  0 selects the Workbench screen.  A pointer is taken to point
to a window structure, the requesters will open in that window (and thus
screen).


>I bought this machine because the operating system requires an absolute
>minimum mucking about in assembly. Ther's [sic] no reason on god's green earth
>why that code had to be in assembly.

I prefer assembly.  So there.
--Really, no religious wars intended--


>SCADA: Supervisory Control and Data Acquisition....

Thank you.


>AmigaDOS is a pretty good soft real-time operating system.

Strange, I think of AmigaDOS as a relatively well designed, but poorly
implemented "Disk Operating System".  It controls the disk and file system.

The whole ball of wax that contains exec, Intuition, graphics, AmigaDOS, etc.
has, or should have, another name.  "AmigaDOG" and such derogatory terms
are amied only at the Tripos influenced file system.  (Flames welcome on this
point, especially if I'm wrong!)


>-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)

|\ /|  . Ack! (NAK, EOT, SOH)
{o O} . Use the address below, and no other!
( " )	bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
  U	"Success leads to stagnation; stagnation leads to failure."

ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (08/03/87)

[ Followups redirected to comp.misc, where they like to talk about such
things. ]

In article <434@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>[Flame-throwers on "stun", captain]
>
>And why explain in 68000 code?  [ ... ]
>I bought this machine because the operating system requires an absolute
>minimum mucking about in assembly. Ther's no reason on god's green earth
>why that code had to be in assembly.  [ ... ]
>Right. da Silva's rule #0x7FFE: if conversion of some example from assembly
>to some high level language is easy, then it should have been expressed
>in high level language in the first place.
>
	AHEM!

	I am of the opinion that assembly code is *not used enough* these
days.  The assumption that high-level languages are "good enough" simply
does not jibe with me.

	Expressing a new or complicated algorithm in a high-level language
is a useful endeavor.  It allows you to clearly formulate and express the
problem/procedure in machine-interpretable form.  However, once you have the
basic algorithm down, your next step should logically be to translate that
algorithm into assembly by hand.  Compilers can do a good job, but never as
good as a human.

	I point to accomplishments of the past.  SpaceWars fit in 4K of core
on the PDP systems (as I understand it).  I have a copy of a very powerful
music program for the 8080 that runs in 4K.  I have a copy of an 8080 BASIC
interpreter that has multi-line user-defined functions, IF-THEN-ELSE,
automatic structure indenting, error trapping, formatted I/O, and matrix
functions.  It's 15K in size, and runs great in 32K.  Sonix is all assembly
code, and its core is 29K in size (I think).

	Meanwhile, MicroSlush is proud of the fact that the core of their
AmigaBASIC interpreter runs in "only 80K" of RAM.  Truly pathetic.

	I'm not knocking high-level languages.  I use them a lot, and would
be very lost without them.  In fact, if you know how a particular compiler
behaves, you can get some very efficient code out of it.  But it should be
agreed that assembly has its place in the world, and should not be
arbitrarily poo-poohed.

	I really should hone my 68K assembly skills.  I think I'm getting
lazy....

>Fear not, you're in good company. Donald E. Knuth (yes, that Knuth) is one
>of the worst offenders. His "Art of computer programming" is almost useless
>for day-to-day use because of "MIX".  [ ... ]

	You didn't read his introduction to the book.  It's a cookbook of
algorithms, with sample implementation in a hypothetical language.  It's up
to you to translate the *algorithm*, not the code, over to what you want.  I
suspect he invented a hypothetical language to force his readers to use the
algorithms he presented, not just his code.  If he'd written it in Pascal or
something, people would be tempted to drop the code into a machine
unmodified, and they wouldn't learn anything.  Anyone can transliterate
code, but can you use the *algorithm*?

	Final note:  This is not a personal attack.  I simply feel that
assembly code should be used more often than it is currently.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\
 \_ -_	 Bike shrunk by popular demand,	      dual ---> !{well,unicom}!ewhac
O----^o	 But it's still the only way to fly.  hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor

bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (08/03/87)

[ Sigh, UCB's net news disk filled up.  I got numbers, but no actual text
to go with them.  Sorta like the lineeater's big brother :-) 
Or perhaps Robert W. Skyles; his company sends me royalty reports...
but no checks!  :-( ]


In article <434@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>In article <>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes:
>>In article <397@sugar.UUCP> Peter da Silva typed:
>
>> [incoherent junk deleted]
>
>That's nice, but it won't (as has been explained a thousand times) disable
>system requestors [sic] (bad disk, disk full, etc...) caused by your actions.

Exactly.  As was explained a thousand times, setting pr_WindowPtr will NOT
ensure that a requester from some weird source might not show up.  I know this.

In fact, in that discussion it was decided that a program would be needed.
Apparently you missed something, because the program I posted ensures that
*all* requesters from *all* tasks are turned off when you want them off.  It
SetFunction()'s AutoRequest() and BuildSysRequest() and Cancel!'s them for
sure, every time.

Search backwards for the word "Cancel".  (from rn type "?cancel?rh").  Or look
to comp.sources.amiga and comp.binaries.amiga.

BTW:  Setting pr_WindowPtr will *not* catch most bad disk requesters, but
*will* catch disk full.  For some requesters it's probably impossible to
determine what actions, or set of actions, caused the problem.  Several
tasks may have contributed... it's turn them all off, or leave them all
on.


>[Flame-throwers on "stun", captain]
>
>And why explain in 68000 code?

Probably because I wrote the requester canceling code in 68000 and was in that
frame of mind.  I program in C also, but not that day.


>	MyProcess = FindTask(0);
>	WindowSave = MyProcess->pr_WindowPtr;
>	MyProcess->pr_WindowPtr = 0;

That's an incorrect conversion.  To silence DOS generated requesters you set
pr_WindowPtr -1.  0 selects the Workbench screen.  A pointer is taken to point
to a window structure, the requesters will open in that window (and thus
that window's screen).


>I bought this machine because the operating system requires an absolute
>minimum mucking about in assembly. Ther's [sic] no reason on god's [sic] green
>earth why that code had to be in assembly.

I prefer assembly.  So there.
--Really, no religious wars intended--
--Then again, your comment about God's green earth...]


>SCADA: Supervisory Control and Data Acquisition....

Thank you.


>AmigaDOS is a pretty good soft real-time operating system.

Strange, I think of AmigaDOS as a relatively well designed, but poorly
implemented "Disk Operating System".  It controls the disk and file system.

The whole ball of wax that contains exec, Intuition, graphics, AmigaDOS, etc.
has, or should have, another name.  "AmigaDOG" and such derogatory terms
are amied only at the Tripos influenced file system.  (Flames welcome on this
point, especially if I'm wrong!)


>-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)

|\ /|  . Ack! (NAK, EOT, SOH)
{o O} . Use the address below, and no other!
( " )	bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
  U	"Success leads to stagnation; stagnation leads to failure."