HDTenEightyP/NetNews huggingface dataset:
From: mglew@laurel.ocs.mq.edu.au (Michael Glew)
Subject: Re: Pascal
Followup-To: mglew@laurel.ocs.mq.edu.au (Michael Glew)
Organization: Macquarie University, Australia.
Date: Mon, 28 Dec 1992 22:41:48 GMT

I have been using PCQ Pascal for about 2 years privately, and 6 months
professionally.  It is a very good package for developing software
and I thoroughly advise getting it.  It can be ftp'ed from amiga.physik
and wuarchive.wustl.edu, or archie.au in Australia.

I aggree about it not supporting sets, but you can get around that quite
easily.  You could probably implement it yourself.


Regards,

	Mike.
 -----------------------------------------------------------------------------
 Internet:	mglew@laurel.ocs.mq.edu.au
    Phone:	+61 43 841525

                     "I have a cunning plan..."	- Baldrick (Black Adder)
 -----------------------------------------------------------------------------
     Michael Glew - School of Math Phys Comp & Elec - Macquarie University
 -----------------------------------------------------------------------------

Newsgroups: comp.sys.amiga.programmer
From: mt87692@cs.tut.fi (Mikko Tsokkinen)
Subject: Re: Memory copy via blitter
Organization: Tampere University of Technology
	<1992Dec22.145856.26691@rzu-news.unizh.ch>
Date: 23 Dec 92 00:14:04


In article <1992Dec22.145856.26691@rzu-news.unizh.ch> cschneid@amiga.physik.unizh.ch (Christian Schneider) writes:

> Dave Plummer (plummer@hercules.cs.uregina.ca) wrote:
> : Could someone email a short example of how to copy 512 bytes within Chip
> : memory using the blitter?  It's totally unrelated to graphics, but since
> : I want a fast way to copy 512 or 1024 bytes, I'd like to use the blitter,
> : but all the documentation I can find refers to BitMaps and such.

> I'd use CopyMemQuick() from exec... (Your data is long word aligned,
> isn't it?)
> CopyMemQuick is probably as fast as blitter for 512 or 1024 bytes on
> 68000 and certainly faster on A3000/A4000 ;-)
> - Chris

While CopyMemeQuick() is good answer. However it is wrong to say if it
is faster to use cpu even on A4000 because you can leave blitter doing
it and do something else in the same time. It depends on the situation.


--
 Mit
xxxxx
"Any sufficiently advanced technology is indistinguishable from magic."
From: exuhag@exu.ericsson.se (James Hague)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: How should I learn C?
Date: 29 Dec 92 16:29:49 GMT
Reply-To: exuhag@exu.ericsson.se
Organization: Ericsson Network Systems, Richardson, TX
X-Disclaimer: This article was posted by a user at Ericsson.
              Any opinions expressed are strictly those of the
              user and not necessarily those of Ericsson.

Rich Carreiro writes:
>
>Isn't C older than Pascal?  In any case, get a copy of Brian Kernighan's classic
>_Why Pascal Is Not My Favorite Programming Language_ (or some similar title).
>It's available somewhere; it was posted to alt.folklore.computers a month or
>so ago.  It's a wonderful point-by-point listing of the serious things that
>are wrong with Pascal.

Of course, no one uses 100% standard Pascal for anything but computer
science courses or relatively simple programs.  But with a few decent
extensions, like those in Turbo Pascal for the PC, Pascal becomes very
useful and basically equivalent to C.  You lose portability, naturally.

Most of these extensions are those introduced in Modula-2:  a generic
parameter type, type transfer functions, open-ended arrays, etc.  The
advantage being that you get a cleaner syntax (I much prefer pointer
indirection as a postfix operator, for one).  Again, this is less portable,
especially when it comes to standard library functions (which Pascal
provides very few of).

--
James Hague   
exuhag@exu.ericsson.se
From: Paul_Trauth@agwbbs.new-orleans.LA.US (Paul Trauth)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Subliminal Messages
Distribution: world
Date: 3 Jan 93 19:38:09 CST
Organization: The Amiga GateWay BBS * New Orleans, La.

In a message dated Sun  4 Jan 93  2:19, Sjchmura@kimbark.uchicago.edu (stev
wrote:
 S> Paul_Trauth@agwbbs.new-orleans.LA.US (Paul Trauth) writes:

>I remember one utility for the C64 that attempted to include a subliminal.
>Every so often, it would flash, for one frame, the words "Support
>Shareware!" at a point on the screen. Once i discovered this, i quit using
 S>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>it...
 S> ^^^^
 S> Why?  Are you scared of your computer?

No, i just don't want to use a utility that attempts to fuck with my tiny
little mind. (Besides, Lynx was exceedingly bug-ridden anyway...)

-- Via DLG Pro v0.995

- be zorch, daddi-o --------------- paul (raccoon) trauth ----------------
--------------------------------------------------------------------------
Internet -> paul_trauth@agwbbs.new-orleans.LA.US        \\\///\\\///\\\
Usenet   -> rex!agwbbs!paul_trauth                      \\\///\\\///\\\
--------------------------------------------------------------------------
  "eagles may fly, but a weasel will never get sucked into a jet engine"
Newsgroups: comp.sys.amiga.programmer
From: gbrandt@muug.mb.ca (Gregor Brandt)
Subject: IFF HUNK types, recent info?
Summary: ?Need recent info on IFF hunks
Keywords: IFF, CLUT, ASDG
Organization: Manitoba Unix User Group, Winnipeg, Manitoba, Canada
Date: Mon, 28 Dec 1992 19:24:49 GMT

Hello,
 
   I need some information on IFF hunks.  In particular the format and
   meaning of a CLUT, and perhaps ASDG (if its public).  Better yet would
   be a pointer to the newest IFF docs, that list these and other new hunks.
    
    Thanks,
    
    Gregor
    
Newsgroups: comp.sys.amiga.programmer
From: danb@shell.portal.com (Dan E Babcock)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)
Date: Sat, 2 Jan 1993 00:35:10 GMT

In article <paulk.31gk@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
> 
>It's simple.  If chunky was universally better in every way, then no
>planar systems would have been built.  Think about it.

Well, sure there is a perfectly good reason to use planar: it lets you use
non-power-of-2 bits per pixel. The Amiga makes good use of this, for example in
dual playfield which uses 3-bitplanes per playfield. Of course, if the Amiga
were "done over" it would use VRAMs with chunky pixels...which is I believe
what the "high end" chipset is supposed to be doing. Or so we hope. :-)

Dan

Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Fri, 25 Dec 1992 00:15:58 GMT

In <dougp.725175366@sbphy.physics.ucsb.edu> dougp@sbphy.physics.ucsb.edu ( Doug Peale) writes:
>Gee, I can't get RoboCity to work, and the Mandrell picture just displays
>garbage on my system. I have an A1000 with a rejuvinator, ECS chipset, 2megs of
>chip ram, and 2.04 in ROM.

Robocity and Mandrill require to have their data in chip mem. Since they
are pre 1.1 there was no way to inform the LoadSeg() routine that certain
hunks have to be loaded into chip memory. If you patch the executable
accordingly then both programs will run.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Mon, 28 Dec 1992 12:31:42 GMT

In <jbickers.0m7s@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:
>    Yes it is. For a 320x200 screen it's a maximum of 64000 byte reads
>    and writes with chunky pixels, supposing all pixels turned out to
>    need replacing. How can you get better than that with planes?

I didn't say: get better. They are about the same speed.

>    Any particular advantages? I can't think of any. If you want to
>    draw a horizontal line to fill a shape, you don't have to mask off
>    each end with chunky pixels. You do with bitplanes.

Fortunately this is a no-time operation. :)

>> :) Hmm, the classic method is using Flood(). There's nothing that forbids
>> the graphics.library to access the hardware and use every optimization.

>    And it will (or should) be faster with chunky pixels than with
>    planes! Chunky pixels rule ok!

I can't see why it should be faster..

>    Well, that kills that idea. :) Non-scrollable screens will be nice
>    though, sort of like the switching between modes that PCs do, so
>    that the different displays can share the monitor with the OS
>    knowing about it, instead of a human having to flip a switch :).

Right. That's already supported (look at A2024 screens).

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 26 Dec 92 17:54:02 PST
Organization: BBS

> > > or controlling the display registers and also trying to use the
> > > OS for double-buffering may be out of the question
 
> > Why try to mix both approaches at once?  That gives you no
> > advantages of either approach.
 
> So you're advocating not using the OS for double-buffering?
 
Where did you get THAT??  I'm un-advocating the use of hardware
banging mixed with otherwise OS-friendly stuff.

My whole position on the hardware-manual issue is that I don't want the Amiga
to be "crippled by compatibility".  I want programs that we write NOW to work
on future incompatible hardware.
From: bj@cbmvax.commodore.com (Brian Jackson - Amiga Networking)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: What is htonl() ?
Date: 23 Dec 92 16:29:18 GMT
Reply-To: bj@cbmvax.commodore.com (Brian Jackson - Amiga Networking)
Organization: Commodore, West Chester, PA

Benjamin Reich writes:

>I am stumped by one line of code:
>
>     *lmark = htonl(*lmark);
>
>I have no idea what this function is or does.  
> [...]
>I would appreciate any info as to what this function does, so that
>I may either emulate it or throw it out.
>
>Benjamin Reich
>Counsellor@cup.portal.com

Eric G Stern replies:
>
>htonl() is a function from the BSD networking library.  It converts
>a long from "host byte order" to "network byte order".  This is to
>deal with certain architectures that store four byte objects with
>the least significant byte in the lower byte address, while the
>(BSD) network specifications say that four byte objects (network addresses
>for instance) are stored and transmitted with the most significant byte
>first.  For the Amiga, and most unix-boxes (except DEC) this function
>is probably a no-op.
>
>				Eric Stern
                    
Yup. 

#ifdef AMIGA
#define htonl(x)        (x)
#define ntohl(x)        (x)
#endif

       +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
       Brian Jackson    Amiga Networking Group, Commodore-Amiga Inc.
                        bj@cbmvax.commodore.com
     {uunet|rutgers}!cbmvax!bj    or   networking@cbmvax.commodore.com
                       uva uvam vivendo varia fit 
Newsgroups: comp.sys.amiga.programmer
From: mtpins@icaen.uiowa.edu (Michael T Pins)
Subject: Re: AMOS - is it any good?
Date: Thu, 31 Dec 1992 19:52:11 GMT
Organization: University of Iowa, Iowa City, IA, USA
X-Newsreader: NN version 6.4.19

crystal@glia.biostr.washington.edu (Crystal) writes:

>I've been told that AMOS is some sort of "easy to program" language and that
>demos and "real" programs can be created with it.  

>Is it a compiled language?  Or an interactive one?

>If I write a program in it, does the person who tries to run it also need to
>have AMOS on their system?  (Like GWBASIC...*washes mouth out with soap*)

The short answer is, no, it's not any good.
I have yet to see a single AMOS program that doesn't have massive amounts of 
Enforcer hits.  Considering the amount of AMOS programs that people have sent
me, it would certainly indicate that the problem is with AMOS itself.

-- 
*****************************************************************************
* Michael Pins                |   Internet: amigapd@isca.uiowa.edu          *
* ISCA's Amiga Librarian      |         #include <std.disclaimer>           *
*****************************************************************************
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: Formatting strings, sprintf() <-> RawDoFmt()
Originator: walker@twix.unx.sas.com
Date: Tue, 22 Dec 1992 13:52:37 GMT
Organization: SAS Institute Inc.


In article <OD.6badnetOA92-910-101_0F8AEBAC@piraya.bad.se>, Adam_Sjoegren@thesystem.bbs.bad.se (Adam Sjoegren) writes:
|> 
|> Why does the same formatting string used in sprintf() and RawDoFmt()
|> not result in the same?

RawDoFmt() assumes SHORT integers, no matter what your compiler
options are.  (How could it know what your compiler options
are?)  You need to use %ld to format a four-byte integer.

|>  Adam Sjoegren   \O_ asj@thesystem.bbs.bad.se  \O_  +:+: The system :+:+

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.
From: Adam_Sjoegren@thesystem.bbs.bad.se (Adam Sjoegren)
Newsgroups: comp.sys.amiga.programmer
Subject: Formatting strings, sprintf() <-> RawDoFmt()
Date: Sun, 20 Dec 92 13:14:46 +0000
Reply-To: Adam_Sjoegren@thesystem.bbs.bad.se (Adam Sjoegren)
Distribution: world
Organization: The system, Frederiksberg Copenhagen, Denmark 
OD-Comment-To: All


Why does the same formatting string used in sprintf() and RawDoFmt()
not result in the same?

For instance:

 rawsprintf(buf, "%5.0ld - %4.1ld (%2.1ld%%)\n", x, y, z);
 /* Doug's magic */

Does not result in the same 'buf' as the same formatting string run
through standard sprintf(). How come? I thought that the
%<num>.<num><typ> was supposed to be some kind of standard?

Am I missing something?

  .
 /|dam
                .                             .
               -*-                           -*-
 Adam Sjoegren   \O_ asj@thesystem.bbs.bad.se  \O_  +:+: The system :+:+
 Copenhagen,      |  GCChost Support, Denmark   |   "The magician longs"
 Denmark, Europe / \  Still running A500 )-:   / \  BBS    +45-31-354775
---
From: jaker@csugrad.cs.vt.edu (Jake Rose)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: OS 3.0 Manuals
Date: 29 Dec 92 17:49:54 GMT
Organization: Virginia Tech Computer Science Dept, Blacksburg, VA

>release would be to relese them on CD (or floppys) in AmigaGuide format.
>If this format is used during development, small corrections can be made when
>the bugs are found, and the CD's/floppies then made.

I can't begin to describe to you how good this sounds.  I wish CBM would do
things like that - I would much rather have disk-based reference manuals than
paper ones (and AmigaGuide is just the thing for them, too), and CBM could
always offer paper ones to people who have never gotten used to doing things
in a modern way (eg people who still print out source listings every time they
find a bug, people who enjoy their normal eyesight... :) ).

>If you look at Microsoft's manuals and compare them with the contents of
>the help files on floppy, they contain the same information, but the
>books are much more out-of-date and full of errors.

>=============================================================================
> Tommy Petersson              tope@enea.se              Enea Data AB, Sweden
>=============================================================================
-- 
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Jake Rose               :: Every cloud has a silver lining.
jaker@csugrad.cs.vt.edu :: Every silver lining has a cloud inside it.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
From: fheitkamp@desire.wright.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Stupid C question
Date: 28 Dec 92 07:04:26 EST
Distribution: world
Organization:  Wright State University 

In article <ad99s461.037k@sycom.mi.org>, ad99s461@sycom.mi.org (Alex Deburie) writes:
> Okay, I've had SAS-C 6.0 for about 2 weeks and I'm very pleased. Between GST's 
> and the Workbench interface, I doubt I could ask for a better introduction to 
> C on the Amiga.
> 
> However, I have one very stupid (simple?) question. HOW DOES ONE COVERT A 
> FLOATING POINT VALUE TO AN INTEGER???!!!  I see functions like modf(), but 
> still that returns the integral part of the number as a float. And casting 
> seems to always return a 0!

	One simple way is to use a cast:

	float f1;
	int   i2;

	i2 = ( int )f1;
	you can also do a simple rounding that will work for positive
	numbers:
	i2 = ( int )(f1 + 0.5);

	This "casting" is very important to know with C.

> 
> What should I do? Go back to BASIC?? ;^)

	No.  Noooo.  Not BAAAASIIIC!!!

> 
>      -- Alex Deburie
>         ad99s461@sycom.mi.org
Fred Heitkamp,  ** Not an organization **
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Date: 30 Dec 92 22:22:57 PST
Organization: BBS

> Chunky _needs_ to write transparent pixels and _needs_ to care
> about alignment _if_ you do memory access larger than a pixel. You
> either have to use _8bit_ accesses or use the complete buswidth
> with the same constraints as in bitplanes.
 
Whoa!  Somebody finally pointed out the ugly secret hiding in there
which never seemed to occur to anybody ......
 
Using chunky display memory with a word length longer than the chunk,
*IS* in some ways a planar display and has the same disadvantages.
One can only get the full advantage of chunky display if you either
access your (for example) 32 bit memory with 8 bit reads and writes,
which could be a significant loss compared to plane-oriented hardware
that always uses whole words, or use a number of bits per pixel equal
to the full width of your memory, which if more than 8 bits is
presumably going to be true-color, which becomes rather awkward due
to the lack of modern CPUs with a wordlength which is a multiple of
three bits ... or then you start having the word value for each pixel
divided into separate bitfields (masks, dual playfields, etc) which means
that in order to work on the actual picture you now have to, in a sense,
do the reverse of what planar systems have to do to access individual
pixels: you have to separate your chunks into layers in order to tease
out the different numbers.

So: chunky is way better than planar with no disadvantages, if you are
building a display for an 8088 system, or if you are an ant or red-green
colorblind or otherwise have a power-of-two number of primary colors
in your eyeball.
Newsgroups: comp.sys.amiga.programmer
From: danb@shell.portal.com (Dan E Babcock)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)
Date: Tue, 29 Dec 1992 10:24:32 GMT

In article <1992Dec29.010853.12840@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
>In <doiron.0k4a@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
>
>Chunky wins slightly in most operations IF you use a 256 color image.
>It looses with a depth != 8. BTW, 32x32 blit is tiny, what about 50x50
>or 156x200 ? And since we were talking about 'image processing'. Most tools
>have some sort of GUI which eats some of the 256 colors. The easiest
>way is to go down to 128 colors. Bitplanes will then be faster for 12.5%.

Huh? That doesn't follow, except for trivial operations like clearing the whole
screen. Another big advantage for chunky/8-bit displays is fast "cookie-cut"
blitting. On the Amiga a cookie-cut blit requires 4 memory accesses (source,
mask, dest, and dest) per word transferred. On a TI graphics chip it requires
only 2 accesses, source and dest, because it can avoid disturbing the destination
byte if the source byte is 0 (transparent). It's inherently twice as fast.

Dan
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AmigaDos Assign command
Date: 28 Dec 92 19:18:10 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

jdickson@jato.jpl.nasa.gov (Jeff Dickson) writes:
>In article <37922@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
>>
>>	while (1) {
>>		dp = GetDeviceProc(path,dp);
>>		if (!dp)
>>		{	/* getdevproc freed dp for us */
>			   ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>	How? Before getdevproc returned dp?

	Read the autodocs.  When making multiple calls to GetDeviceProc, the
end of the list is signaled by GetDeviceProc returning NULL.  You pass in your
old dp (a) so it can decide what to give you next, and (b) so it can free it
if you've hit the end.  If you have the autodocs, always check them before
posting questions about routines - it saves everyone (including you) time and
trouble.

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: How should I learn C?
Originator: walker@twix.unx.sas.com
Date: Tue, 29 Dec 1992 19:35:30 GMT
Organization: SAS Institute Inc.


In article <rlcarr.09er@animato.network23.com>, rlcarr@animato.network23.com (Rich Carreiro) writes:
|> You now can use foo[6] to foo[26] to access the arrays.  By extension you
|> can even use negative subscripts (you can in theory -- I don't know off-hand
|> if the language spec allows for it).

The language does allow for it.  However, I do not recommend that you
use this technique - it's confusing.  Do it the C way, don't try to
coerce C into allowing you to do it the Pascal way.

|> > I have to use global variables a lot (taught as a no-no at GT) and it just
|> 
|> There's nothing in C that should make you use globals where you did not use
|> them in Pascal.  I don't understand this complaint.

Probably the scoping problem - you can declare a "local" in a pascal
procedure, and then use it in subprocedures.  The answer is to use
statics instead of globals, or to place all such variables in a
structure and pass the structure to all subroutines.

|> Rich Carreiro                                  Home: (401)841-8514

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.

Newsgroups: comp.sys.amiga.programmer