🚀 go-pugleaf

In article <90339.161058DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes:
>In article <1990Dec5.114110.26904@cck.cov.ac.uk>, csg019@cck.cov.ac.uk
>(-~=Zaphod=~-) says:
>
>>karma!), or write a fast loader or anything else a it technical.
>
>By the way, I've yet to see a "fast loader" that's even slightly noticeably
>faster than trackdisk. (In fact, some of them that wait for the index are
>SLOWER!). I wonder why some smart programmer doesn't write a really really
>fast loader? I'll tell you why: it's not possible! The loading time is
>dominated by the rotation speed of the disk (200ms), so the decoding and
>other routines that make a loader unique are almost totally irrelevent to
>the loading time!
>
>People still make custom loaders though, because the OS is usually eliminated
>(another story).

	Quite true.  And if you use trackdisk, you pick up all the improvements
we made to it for 2.0.  It comes close to the fastest possible now, and even
can better 20K/s with FFS floppies.  It has all sorts of optimizations to make
it faster if you have fastmem, recover from errors better, etc.  Also, with 
trackdisk you're safe from people writing loaders (as has happened a number
of times in britain and the rest of europe) which don't work when commodore
changes drive manufacturers, or has a genlock installed, or has a system
that for other reasons runs a bit slow or fast (we allow +- 5%).  Then there
are all those loaders that break with '020's or higher, which are becoming
quite common in the USA, may even show up in low end machines before long,
since the price of an '020 is getting down there.

[Flame on!]

	Currently I'm annoyed because Ultima V (ported by a British firm for
Origins) a) doesn't work on anything except 68000's, b) doesn't work with
2.0, even though they take over the machine, because they didn't bother to
set up the CIA A modes they wanted, and assumed the values there (2.0 timer
uses the CIA's differently).  Their disk routines are full of dbra timing
loops.  We've been telling people how to avoid these problems for years,
with source code (see Bryce's and my articles in AmigaMail).

	From what I hear from European developers on our private UUCP net
for European Developer support is that most of the programmers in France (and
most other countries) never buy more than the hardware manual, if that.  Their
main source of docs are the Abacus (Data Becker) books, which include thing
direct ROM jumps that break on rom changes, mucking with the internals of
other tasks, innumerable hard-coded offsets (because some poor assemblers
couldn't deal with include files or such), etc, etc.
	
	You CAN write games that either take over cleanly and work on all
amigas, or better yet take over cleanly, and exit back cleanly, or even better
multitask (at least when paused), all while having smooth animation, sound,
etc.  Sure it takes work, but it produces a better product, one that won't 
piss off potential buyers, and will survive OS/machine changes.  Because of
the MASSIVE piracy problems in Europe, most manufacturers hope to make most
of their sales in the first month or two, and after that could care less if
it continues to work when the user upgrades their system.  If the piracy 
problems in Europe were more under control, publishers would have more
incentive to demand good programming from their developers.

	The Amiga is not a C64 with more colors, guys!

[Flame off for the moment]
-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)