From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz)
Newsgroups: comp.sys.amiga.hardware,comp.sys.amiga.advocacy,comp.sys.amiga.programmer
Subject: Re: Atari Falcon (wasn't: Amiga Falcon)
Date: 8 Apr 92 02:58:32 GMT
Distribution: world
Organization: Amiga makes it possible
X-NewsSoftware: Amiga GRn V1.28 2/25/92 (Beta) by Mike Schwartz

In article <4wZQq*7t1@swinjm.UUCP> forgeas@swinjm.UUCP (Jean-Michel Forgeas) writes:
>In article <mykes.2019@amiga0.SF-Bay.ORG>, Mike Schwartz writes:
>
>> I also DO
>> learn the use of all the function calls in the OS.  It is HARD.
>
>It is normal, learning new things is hard and requires time.

I never said it wasn't normal, just hard.  You agree.

>
>> many of the OS function calls require you to call a bunch of others to
>> make it work.
>
>Fortunately each OS call is a part of a harmonious multi-purpose system.

I didn't say it was unfortunate, just makes extra work and more places
to make programming errors.

>
>> But there are huge advantages to writing your own function calls instead
>> of just using existing functions.
>
>It depends on the function call, and on the application you are doing, and
>under which environnement your application runs, and on the total time you
>have to do the application, etc...

Total time is less to write a flood fill routine than it is to set up all
the stuff needed to make the OS routine work.

>
>> When =RJ= programs the Amiga these days, he uses his own enhanced
>> and improved windowing system,
>
>I'd like very much to see this, how can I ?

He works at NTG in Palo Alto.  I visited him there and saw his work.

>
>> If I have to add an OpenLibrary() call and do error checking for it in
>> my program, that's stuff that has ZERO to do with the guts of my application.
>
>Yes it has to do with your application because the way the system works
>(no absolute address unless one...) has so many other advantages that you
>certainely are happy with them and 'jsr ...' and 'tst.l' seem jokes.
>

I am NOT expressing dissatisfaction.  Check the Subject: line above.  I am
saying that there is benefit to programming a machine like the Atari Falcon,
if it ever sees the light of day, too.

>> I choose the Amiga
>> because I CAN diddle the parallel port hardware with a handful of instructions
>> (WITHOUT using the OS) instead [...]
>> I'll also diddle the parallel port in assembly or 'C' without using
>> the parallel.device [...]
>
>So you seem to write generalities about programing the Amiga, but you
>have a very specific use of your Amiga, and a very specific way of
>programming it.
>When you write something about the OS, it seems that you always think
>about the same type (yours) of application in your mind.
>Since when I read your postings I attach (as for others postings) their
>meaning to standard Amiga types of applications, this creates confusion...
>
>Can you say that all what you wrote in this posting applies to an
>application displaying interactive graphics (font sensitive gadgets,
>lists, ...) into a resizable window which opens on the Workbench
>screen (can be obscured by other windows), with an ARexx port, a
>clipboard handling, using user keymap, and having other user's
>applications running at the same time?
>I think that you cannot say that.
>

Please look at my credits in my .sig.  You don't want E-Mail from all the
GRn and MailMinder users telling you that I DO write code that does use
the OS well.  GRn uses gadtools.library and is font and window size sensitive.
MailMinder uses workbench.library.  GRn opens about 11 different .libraries.
That's a lot of stuff it's using.

>> Imagine the guts of DPaint
>> in ROM. [...] And DPaint can still get better since
>> you can do SetFunction() or SetPatch.
>
>It's hard to follow you: you wrote above (I didn't quote it) that:
>    "Also, an OS routine that is in ROM is permanent and can't be enhanced
>     without replacing the ROM" (<mykes.1651@amiga0.SF> line 133)
>And now you write the opposite. Or did I miss the context ?
>

DPaint is NOT OS code.  It is application code.  The Mac has application
code as part of its OS, which makes all apps benefit.  I think you miss
the context.  I also point out that whatever part of DPaint is diskbased
can choose to call the ROM or implement newer/better routines.

>> I'll publish my 'C' multitasking kernel for the Sega right here, since
>> it is so small and trivial (also maybe others will enjoy it):
>
>Seems very nice and (for me) not trivial at all !
>Thank you very much for this code.
>

Those routines represent a trivially small amount of assembly coding.  If you
can't fathom it (not saying you can't), you ought to learn from it.  The reason
I posted it is so you can see for yourself that multitasking, especially non-
preemptive, is TRIVIAL and not some magic that real programmers can't do themselves.


--
Author of Amiga GRn, MailMinder, Budokan, Beyond Dark Castle, Dark Castle,
and Genesis Dick Tracy and Marble Madness.
Mike Schwartz  (ames!zorch!amiga0!mykes or mykes@amiga0.sf-bay.org)
1124 Fremont Ave.
Los Altos, CA 94024