HDTenEightyP/NetNews huggingface dataset:
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: Defect: SAS/C "se" (screen editor)
Originator: walker@twix.unx.sas.com
Date: Mon, 12 Oct 1992 13:17:10 GMT
Organization: SAS Institute Inc.


In article <18734.2ad894a8@ecs.umass.edu>, bell@ecs.umass.edu writes:

|> What I see is the following
|> 	012345
|> 	612345
|> 	^ cursor is here.
|> 
|> What's going on here???  Does SAS know about this bug??
|> I'm glad I expand tabs to spaces :-)
|> 
|> 		Shane L. Bell

Yes, we know about the bug.  It will be fixed in the first patch
release, which will be available in a few weeks.

For now, either expand tabs to spaces or disable auto-indent mode.

-- 
  *****
=*|_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
From: ecarroll@maths.tcd.ie (Eddy Carroll)
Subject: Re: Wolf3D -- programming aspects
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.
Date: Sat, 10 Oct 1992 02:18:08 GMT

oahvenla@silver-surfer.cs.hut.fi (Osma Ahvenlampi) writes:
>This may have nothing to do with anything, or this may be pure BS, but I was
>talking to a friend of mine tha other day (yes, I have PC-using friends! gack!)
>and he said Castle Wolfenstein 3D actually uses a non-documented bitplane mode
>found on almost every VGA/SVGA-implementatation. He told me that VGA boards
>are basically programmable to various non-documented resolution/color modes,
>and that they do have a bitplane fetch mode in addition to the usual chunky
>pixel fetch, but that these modes are not specified nor very much used (there
>are thousands of variations, as you can imagine). [ ... ]
>I still can't understand how that would make that bitmap scaling possible, it
>should be slower if anything. My friend said that addressing the VGA in this 
>way is faster, so that could make up for what is lost in more complex
>calculations, but I don't know.

An educated guess: VGA cards in planar mode allow you to set up a data
value (mask, if you like) that applies to all bitplanes so that a single
16 bit write to VGA memory can update all bitplanes in one go. This
would give you 8 times the bandwidth of a chunky mode, since you can
update 16 pixels per write instead of just two. Maybe this is what your
friend is referring to? It wouldn't necessarily help for rendering, but
it would certainly help for screen clears when double-buffering.

Eddy
-- 
Eddy Carroll      ----* Genuine MUD Wizard  | "You haven't lived until you've
Internet: ecarroll@maths.tcd.ie             |  died in MUD!" -- Richard Bartle
From: Frank.Neumann@arbi.informatik.uni-oldenburg.de (Frank Neumann)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Problems with RKM Libs example and Dice
Date: 16 Oct 92 13:42:21 GMT
Organization: University of Oldenburg, Germany

Hi,
casey@lexmark.com (Patrick Casey) writes:

[...my problem with Dice deleted..]
>It had something to do with the A4 register usage for the small-code
>model.  I think I was able to solve the problem by using a compiler
>flag that turned off the small-code model.  Sorry about being so
>imprecise, but I could look at it tonight on the Amiga.

Fortunately, with help of Stefan Becker, I found this out myself yesterday -
the problem is that A4 has to be prepared to point at the (data ?) section
of the program, and if you use a C function as a task or process, this
condition is normally not fulfilled. By adding a __geta4 keyword to the
function, like in
__geta4 void mytask(...)

the compiler will add the neccesary code to initialize A4 at every entry of
the function. This is generally used in any function that is used as interrupt
server, tasks or process (function that are subject to context switches).

Thanks for investigating,
Frank
-- 
+ Frank Neumann, Hauptstr. 107, 2900 Oldenburg, FRG   The Amiga is it.   +
+       InterNet: Frank.Neumann@arbi.informatik.uni-oldenburg.de         +
+       UUCP: neumann@uniol.uucp   \\//    InHouse:amigo@faramir         +
+ Zerberus: neumann@uniol.zer BitNet:295391@DOLUNI1.BITNET IRC: Franky   +
+ "All die Manta-Computer-User - Hauptsache vorne leuchtet 33Mhz auf..." +
+        - Stefan Schulze in fido.ger.amiga, 04.08.1992                  +
Newsgroups: comp.sys.amiga.programmer
From: john@pauli.lv-physics.nevada.edu (John Kilburg)
Subject: Re: Writing a postscript interpreter
Organization: UNLV Department of Physics
Date: Thu, 15 Oct 92 00:24:24 GMT

In article <bobt.0242@bbs1984.chi.il.us>, bobt@bbs1984.chi.il.us (Bob Tomasevich) writes:
|> How difficult is it to write a Postscript interpreter?  I've seen the Adobe
|> Postscript reference manual and Postscript seems to need a lot of math and
|> parsing.  

I don't know.  I have never written a postscript interpreter.

|> I would be using C to write it.  I figure it can't be too difficult.  Am I
|> right or wrong?

You could port ghostscript to the Amiga (I don't think its been ported
yet).  It is a postscript compatible
interpreter.  There is also a viewer called ghostview.  It runs
on UNIX boxes with X and on PCs (maybe Macs, too).  I have it running
on RS/6000s and I haven't had any problems.  It is available on
prep.ai.mit.edu, I believe.

If you want to experience the thrill of doing it from scratch, ignore this.

						-john
Newsgroups: comp.sys.amiga.programmer
From: boberg@lysator.liu.se (Stefan Boberg)
Subject: Re: A4000 and Programming
Organization: Lysator Academic Computer Society, Linkoping University, Sweden
Date: Thu, 15 Oct 1992 15:41:56 GMT

bh00+@andrew.cmu.edu (Brian Hawkins) writes:

>Hello all,

>I own an Amiga 3000 and I am thinking of upgrading to an Amiga 4000. 
>However I have a few questions concerning programming on the 4000 before
>I decide.

>1)  Can I still program it using the 2.0 includes for Aztec C?

  Sure can. No problems.

>2)  When will 3.0 includes and other stuff be available?

  I think they are available already. I know the KS3.0 native developer
disks are available for all registered developers at least. Don't know
about the status for non-registered people though.

>3)  Can the Haitex X-Specs3D glasses be used with the 4000?

  If they work on an A3000, they should work on an A4000. I see absolutely no
reason why they would not work.

>4)  What are the input/output ports on the 4000?

  Same as A3000 except there is no SCSI port.

>5)  (This one is not really about programming)  How well do programs
>written for 1.3 and 2.0 work?

  As well as on an A3000 except for some hardware-banger software that
can be made to work by putting the computer into ECS mode (is done from
the boot menu).

>Brian Hawkins (bh00@andrew.cmu.edu)
-- 
Stefan Boberg - AP & EE student at Linkoping Institute of Technology, Sweden
 Author of LhA, ArjA and LhArcA. Co-author of Alien Breed, Project X ...
  EMail: boberg@lysator.liu.se, lha@augs.se           FIDO: 2:204/404.7
    UUCP:  {uunet|pyramid|rutgers}!cbmvax!cbmehq!cbmswe!team17!boberg
Newsgroups: comp.sys.amiga.programmer
From: ron@vicorp.com (Ron Peterson)
Subject: How to get Intuition to send button clicks from overscan area?
Organization: V. I. Corporation, Northampton, Massachusetts
Date: Mon, 12 Oct 1992 21:05:16 GMT

I've just finished writing a program under contract and am troubled
by one last bug I haven't been able to track down.  The program
displays graphics over genlocked video using an overscanned screen.
Whenever I try to read a button click while the cursor is in the
overscanned region, Intuition stops sending my program mouse events
without even sending the button press report.  It's as though
Intuition thinks I've clicked on a menu bar or on another window
so it starts grabbing events for itself and doesn't pass them on
to my application.  If I move the cursor down into the normal,
non-overscanned area and click again a button click is reported
(with a mouse X, Y location set to where I clicked in the overscanned
region) and things return to normal.

Is there some trick to reading button clicks in overscanned areas of 
the screen?  I know there is a way to get raw (unintercepted by Intuition)
menu button events but I haven't seen a way in the docs to get raw events 
from the left mouse button.
ron@vicorp.com or uunet!vicorp!ron
Newsgroups: comp.sys.amiga.programmer
From: rock@lakes.trenton.sc.us (Rockerboy)
Subject: Diplaying ILBM's
Organization: Lakes Public Access
Date: Tue, 13 Oct 1992 19:27:50 GMT

Does anyone out there have source (c or assembly, though I would prefer 
assembly if you happen to have both...;)  ) to display an ILBM IFF file?  
Libraries claims this is a very easy thing to do (and so does devices, 
for that matter) but it has not been very easy for ME.  My problem is 
that I am uncertain if I am not getting the IFF data properly, or if I am 
not setting up my screen properly, or BOTH.  A piece of code to examine 
for proper technique would be very educational, and I would be eternally 
grateful...;)
Xref: sparky comp.sys.amiga.programmer:14552 comp.sys.amiga.tech:118 comp.sys.amiga.misc:15210 comp.sys.amiga:300
From: d92ponha@IDA.LiU.SE (Pontus Hagland)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.tech,comp.sys.amiga.misc,comp.sys.amiga
Subject: Re: : -( Contest - win your own A4000 :-(
Date: 15 Oct 92 16:01:07 GMT
Organization: CIS Dept, University of Linkoping, Sweden


   > I haven't heard a price on A4000 here in Sweden yet, but what about 
   > this: A3000 25 MHz, 100 MB HD, 2 MB RAM for 15495 SEK (plus taxes gives 
   > 19369 SEK -> 3874 USD). I wonder what A4000 will be priced like...

I just got one; 29000 SEK. Commodore did it again. <sigh>

/Pontus
--
/Pontus
law@lysator.liu.se
From: ross@cbmvax.commodore.com (Ross Hippely - Manuals)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: HDMem vs GigaMem for virtual memory on Amigas?
Date: 7 Oct 92 15:15:04 GMT
Organization: Commodore, West Chester, PA
Summary: A4000 *could* have EC040

x.commodore.com>
Reply-To: ross@cbmvax.commodore.com (Ross Hippely - Manuals)
Followup-To: comp.sys.amiga.misc
Distribution: world
Organization: Commodore, West Chester, PA
Keywords: a4000 ec040 manual

In article <35633@cbmvax.commodore.com> mks@cbmvax.commodore.com (Michael Sinz) writes:
>markus@techfak.uni-bielefeld.de (Markus Illenseer) writes:
>>
>> Peter, i am just wondering... The german manual of the A4000 states that the
>> A4000 has an 040EC build in (ok, i must admit: it's mentioned 'probably'),
>> [...]

Actually, the English manual says (in English, anyway) "A4000 models shipped
with a 68040-level microprocessor on the processor module may have the
68EC040 variation of the chip."  This leaves the possibility of a less-
expensive EC040 model without requiring a manual errata, as Mike notes
in his response (below).

If the the German translation of the manual really does say "probably has" 
instead of "may have" in this line, please let me know, Markus, so we can 
speak to our translation agency about it.

>The english manual also has this section.  It was written when it was
>thought that it may be useful to sell two versions of the A4000, one
>with the high-cost full 68040 and one with the low-cost (relative to
>the real one) 68EC040.  The same manual would be used in both cases.

[...]

>It is invalid to assume that because we tell how to do something that it
>is something you need to do.

Couldn't have put it better myself, Mike.
>
>/----------------------------------------------------------------------\
>|      /// Michael Sinz  -  Senior Amiga Systems Engineer              |
>|     ///                   Operating System Development Group         |
>|    ///   BIX:  msinz      UUNET:  mks@cbmvax.commodore.com           |
>|\\\///    By doing the impossible one just proves the point           |
>| \XX/     that one can not do the impossible.                         |
>\----------------------------------------------------------------------/

-- 
----------------------------------------------------------------------------
Ross Hippely:                                               Technical Writer
employed by, not speaking for:              Commodore Business Machines Inc.

Newsgroups: comp.sys.amiga.programmer
From: cpage@esk.compserv.utas.edu.au (Christopher John Page)
Subject: Help : Devpac
Organization: /etc/organisation
Date: Mon, 12 Oct 92 04:26:07 GMT


I recently bought the latest Amiga Format, and in doing so got Devpac 2. So
over the past week or so I have been converting my own source code from A68k
format into devpac. However, I have a problem as some of my code requires
linking (Blink is included on the disk) but as minimal  instructions are
included with the package I can find now way of using them except by modifying
the source of the required module and using it as an include file.
By experimentation I have found that there is an instruction 'link' ,
but I do not know the required syntax.

Any help would be appreciated,

Chris

cpage@esk.compserv.utas.edu.au
From: griffin@eecae.ee.msu.edu (Danny Griffin)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: How to drop DTR
Date: 11 Oct 92 16:50:42 GMT
Organization: Michigan State University

rwm@atronx.OCUnix.On.Ca (Russell McOrmond) writes:

>  Here
>is some code that I use myself.  Hopefully CBM will fix this 
>short-sightedness soon in a new driver for the internal and A2232 ports.

Thanks.  I had a lot of replies saying the only way to do it was to close
the serial device, but I have to put data out *through* the serial device
while DTR is dropped, so that is an unacceptable solution.  :)  I was 
going to buy the RKM: Hardware and see what could be done directly, but
you've included further non-CBM examples.  Thank you again!
-- 
Dan Griffin                    "You stand there with your fixed expression, 
griffin@egr.msu.edu             casting doubt on all I have to say..."
Newsgroups: comp.sys.amiga.programmer
From: alex@bilver.uucp (Alex Matulich)
Newsgroups: comp.sys.amiga.programmer
Subject: Need RELIABLE assembly blitter routine
Date: 10 Oct 92 15:10:17 GMT
Organization: W. J. Vermillion - Winter Park, FL


A friend of mine asked me to make this request, because he no longer has
an internet account.

He is developing a project that requires a fast assembly blitter routine
(there is too much overhead using the C blitter calls).  He needs to pass
the routine source and destination coordinates to blit an area that is 6
bitplanes deep.

He did have one routine that messed directly with the blitter registers,
until a phone call to Commodore Tech Support told him that this is not
recommended, and will likely mess things up if the program is run on newer
OS versions or newer hardware.  They told him something about using
DMA channels instead, but he wasn't sure what they were talking about (I
thought the blitter did that on its own, anyway).

So now he's back to using BlitBitMapMaskRastPort (or whatever it's
called!).

He'd greatly appreciate some help.  If you have an assembly blitter
routine that will do the job described above, could you send them along?
Thanks.

-- 
 _ |__  Alex Matulich    alex.matulich@oau.org
 /(+__>  Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817
//| \     UUCP:  alex@bilver.uucp   {peora|ge-dab|uunet!tous}!bilver!alex
///__)     Internet:  alex@bilver.oau.org | alex%bilver@peora.sdc.ccur.com
Newsgroups: comp.sys.amiga.programmer
From: umsmigi0@ccu.umanitoba.ca (Trevor Allan Smigiel)
Subject: CreateNewProc examples please?  Its drivin me crazy!
Summary: Asynchronous process that signals its parent when done, how?
Keywords: DOS, CreatNewProc, System
Organization: University of Manitoba, Winnipeg, Canada
Date: Fri, 9 Oct 1992 22:08:16 GMT

     I would like to start a new process, and when this child process
is done I want it to signal the parent process.  I would also like to
break the child process from the parent.  I can't seem to get anything
to work.  Any help would be greatly appreciated.  

Here is some code that I was experimenting with:
(It usualy produced guru 80000004 AT_DeadEnd, CPU ERROR)

#include <proto/exec.h>
#include <proto/dos.h>
#include <dos/dosextens.h>
#include <dos/dostags.h>
 
char Result[256];
 
struct Task *ParentTask = NULL;
struct Process *TstProc = NULL;
WORD TstSignal;
BPTR TstLock;
WORD data = 0;
 
void TstProject(void);
 
void __saveds
TstProject() {
	while (!(SIGBREAKF_CTRL_C & SetSignal(0, SIGBREAKF_CTRL_C)))
		data++;
	TstProc = NULL;
	Delay(50 * 3)
	Signal(ParentTask, 1 << TstSignal);
}
 
void
main(int argc, char *argv[])
{
	Execute("list all", NULL, Output());
	if (-1 == GetVar("sc/projdir", Result, 256, 0)) {
		strcpy("ram:", Result);
	}
	ParentTask = FindTask(NULL);
	TstSignal = AllocSignal(-1);
	if (TstSignal >= 0) {
		TstProc = CreateNewProcTags(
			NP_Entry, TstProject,
			NP_Name, "TstProject",
			NP_Output, Output(),
			NP_CloseOutput, FALSE,
			NP_Cli, TRUE,
			TAG_DONE
		);
		Delay(50 * 3)
		if (TstProc) {
			Signal(TstProc, SIGBREAKF_CTRL_C);
			Wait(1 << TstSignal);
			TstProc = NULL;
			FPrintf(Output(), "Good-Bye! %d\n", data);
		}
		VFPrintf(Output(), "Bye!\n", NULL);
		FreeSignal(TstSignal);
	}
 
}

Newsgroups: comp.sys.amiga.programmer
From: pmiller@csugrad.cs.vt.edu (Paul Miller)
Subject: SCMSG Arexx problem
Organization: The Ohio State University Department of Computer and Information Science
Date: Sun, 11 Oct 1992 19:30:08 GMT

This is in response to Fred M Hamilton's message concerning SCMSG and
his problems with QED..

Fred,

You might try removing the quotes from your GOTO and LOADFILE lines,
and perhaps even the \n. I had to do this to get SCMSG to work with XDME.
It seems some editors don't want the quotes or newline.

-- 
* Paul Miller                         |Nobody cares about my opinion anyway*
* INTERNET: pmiller@csugrad.cs.vt.edu |    - Have a JOLT and a smile! -    *
* "What IS it, man?"                                "Happy Happy, Joy Joy" *
Newsgroups: comp.sys.amiga.programmer
From: jamie@cdevil.unx.sas.com (James Cooper)
Subject: Re: SAS/6.0 Bugs...
Originator: jamie@cdevil.unx.sas.com
Date: Fri, 9 Oct 1992 14:15:31 GMT
Organization: SAS Institute Inc.


In article <107320003@hpfcso.FC.HP.COM>, aoe@hpfcso.FC.HP.COM (Alexander Elkins) writes:
>In comp.sys.amiga.programmer, walker@twix.unx.sas.com (Doug Walker) writes:
>
>>
>> Use the EMITS facility as described in the manual (under "contacting
>> technical support") to report bugs via email.
>>
>
>I tried that.  Here's the reply I got:
>
>-------------------------------------------------------------------------------
>Your registration request for Technical Support's Email Facility (EMITS)
>has been declined.  EMITS is for SAS Software Consultants and Installation
>Representatives. You were not listed as a SAS Software Consultant
>or Installation Representative for the site numbers you specified.
>If our records are inaccurate, please contact the Customer Service
>Department in Contracts Administration here at SAS Insititute. The
>phone number for Customer Service is (919) 677-8003.
>
>Supportively,
>Electronic Mail Interface to Technical Support (EMITS)
>SAS Institute
>-------------------------------------------------------------------------------
>
>I guess I'm just a lowly user :-{

No!  Don't say that - there's no such thing!

Your registration card just may not have arrived here yet, or may not
have made it through the registration process.  We don't enter your
registration number until we get your card back.

Please try again in about a week (to give proper "administration
propagation delay" :-) )

-- 
---------------
Jim Cooper
(jamie@unx.sas.com)                             bix: jcooper

Any opinions expressed herein are mine (Mine, all mine!  Ha, ha, ha!),
and not necessarily those of my employer.
From: mk59200@tut.fi (Kolkka Markku Olavi)
Newsgroups: comp.sys.amiga.programmer
Subject: Localized speech (was:If you use locale.library, read this)
Date: 13 Oct 1992 16:57:26 GMT
Organization: Technical University of Tampere, Dep. of Computer Science ,Finland 
Distribution: world
NNTP-Posting-Host: erakkorastas.cs.tut.fi
Keywords: locale.library, speech synthesis


In article <1992Oct10.045343.8416@vlsi.polymtl.ca>, sevigny@vlsi.polymtl.ca (Benoit Sevigny) writes:
|> Speaking of translation:
|> 
|> Wouldn't be nice to have a localised translator.library?

Nice, yes, but not enough. A localized narrator.device is also necessary.
 
|> If C= is not planning to do so, I think it would be great to patch it with
|> localised modules.  The actual entries would translate into english
|> phonetics (to avoid having non-localised program speak with a foreign
|> accent :)

Using the old narrator.device would result in speech output in a heavy
American accent, which is a foreign accent to most people outside the
U.S.A. :-). The current narrator doesn't even have all the phonemes necessary
for Finnish, for example.

--
	Markku Kolkka
	mk59200@cs.tut.fi
Newsgroups: comp.sys.amiga.programmer
From: fisherc@bohra.cpg.oz.au (Craig Fisher)
Subject: Re: Rexx
Keywords: Help me pleae!
Organization: Computer Power Software
Date: Thu, 8 Oct 1992 01:43:19 GMT

In article <6005RB1w165w@dogbox.acme.gen.nz> dave@dogbox.acme.gen.nz writes:
> I need to know an easy way that I can return a value to a Rexx program.
>
> I am working on a little program which needs to return a value/string to 
> Rexx, but I don't want to go through the process of setting up a Rexx 
> port and the like.  Can I just send the data somewhere, so that the 
> script picks up the data from RC?

Why not just write the result out to a temporary file (in RAM, say) 
and then read the contents of the file in your Rexx program?
-- 
=======================================================
| Craig Fisher                \ P.O. Box 686          |
| fisherc@bohra.cpg.oz.au      \ Woden, ACT 2606      |
| "Keep Yourself Alive" - Queen \ Canberra, Australia |
From: jcmurphy@acsu.buffalo.edu (Jeff Murphy)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: SANA II
Date: 8 Oct 92 22:55:29 GMT
Organization: UB




	oops. the post program apparently mangled that one. my question:
i am looking for programming info concerning sana ii. is there anything 
out there?

j murphy
--
From: Klaus_Seistrup@magneto.bbs.bad.se (Klaus Seistrup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: ftruncate(), getch() on the Amiga
Date: Sun, 11 Oct 92 11:43:12 +0000
Reply-To: Klaus_Seistrup@magneto.bbs.bad.se (Klaus Seistrup)
Distribution: world
Organization: Magnetic Ink, Copenhagen N, Denmark 
OD-Comment-To: Paul_Kienitz



In article <1992Oct9.020453.5058@cs.aukuni.ac.nz>, <paulk@terapin.com> (Paul 
Kienitz> wrote:


 >> - Truncate a file at an arbitrary position, like the Unix ftruncate(). 
 >> I can't just copy what I need to a new file and delete the original
 >> since this will be unmanageably slow on 10MB data sets, especially if
 >> it needs to be done often.

 PK> There is a DOS packet for setting file length.  It is NOT supported,
 PK> as I recall, on the 1.x Slow File System.  I think it first appeared
 PK> in the 1.3 FFS.

 PK> Ah, here it is -- ACTION_SET_FILE_SIZE == 1022 in dosextens.h


And, as you said, under 2.0 there is the dos.library SetFileSize() function to 
accomplish the thing.

Now, can anyone tell me how this function works? I need to resize a [log] file 
and wants to keep the last x kilobytes written to the log. But no matter how I 
foole around with different bytesizes and OFFSET_* the d?mn thing won't work!

A sample source will be greatly appreciated, fanx! :-)


  Bliss!

   /\                        : *** Magnetic Ink ***  .  FidoNet   2:230/119
  / kleis@magneto.bbs.bad.se : Ahornsgade 8A, 1.TH. -*- Tel: +45 35-372-171
 /____\                      : DK-2200 Copenhagen N  |  AmigaNet 39:141/110

 * *** "Walking back through the hills of dry grass - coming upriver" *** *

---