HDTenEightyP/NetNews huggingface dataset:
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: IDEA->Macro prog w/joystick movements
Date: 26 Dec 92 17:50:48 PST
Organization: BBS

> > AmigaDos 2.0 has a shell text-clipping feature that only works
> > with other Dos windows.
 
> Actually, as long as you are running the background program
> 'conclip', which is supplied with 2.04 and is started by default in
> the startup-sequence, the shell copy/paste uses the Amiga system
> clipboard.  Other programs that can use the clipboard (VLT,
> MicroEmacs, Baby!, etc) can get and put the text you clipped.
 
And with the program ClipFile, you can swap any text between the
clipboard and ram disk files.  I used this, for instance, to hack up
right-amiga-C and right-amiga-V keystrokes in Uedit.
 
But the other day I wanted to paste something from the text editor
into a string gadget... couldn't figure another way to get
nonstandard IBM characters into it.
 
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Fri, 25 Dec 1992 15:44:00 GMT

In <92359.214301LEEK@QUCDN.QueensU.CA> <LEEK@QUCDN.QueensU.CA> writes:
>Now all the hacker has to do is to download the JEDEC fuse map to
>'emulate' the ID that the software was written for.

Provided that someone knows the ID. While it isn't impossible to
crack a read-protected PAL one could use a more complex FPGA
which can't be cracked in a reasonable time (that's what many
dongles use).

>The ID code thingy is more a problem than a solution in the long run.

This is definitely true for personal computers.

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: benjamin@cs.UAlberta.CA (Ben Ferreira)
Subject: problems with gcc222-fix1.lha
Organization: University of Alberta, Edmonton, Canada
Date: Tue, 29 Dec 1992 22:54:08 GMT

After many attemps to install gcc on my system, the first fix file (fix-1.bak)
always fails at the same point..

Right after the question:

"Due to a name collision an important object file in libgcc.a was missing. 
 Should it be added back? [yN] y"

after I enter 'y' I get:

"found string >)6<
 ranlib: gcc:lib/libgcc.a: inappropriate file type or format"

and it keeps going.. after all 3 fix files have been executed I can only
compile c and not c++ code properly.  Could someone tell me what's going on 
here?

By the way, I DID assign all the proper dirs and paths as in the README file.

Thanks for any help,
Ben Ferreira
From: glewis@pcocd2.intel.com (Glenn M. Lewis - ICD ~)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Going to the metal
Date: 29 Dec 92 22:39:35 GMT
	<C01BK6.ApK@unx.sas.com> <lk1di9INNrsa@exodus.Eng.Sun.COM>
Reply-To: glewis@pcocd2.intel.com
Organization: Intel Corporation, Folsom, CA
X-Posting-Software: GNUS 3.14.1


	First off, it is good to see you back on the net, Chuck!  And
thanks for a very interesting post.

	On this same topic, a developer has created a sound sampler
called the DSS-8 that I wish to use with Richard Horne's AniMan and
VCLI programs for speech recognition.  However, GVP seems unwilling to
help out us programmer-types.  I would like to find out what is
traversing across the parallel port in both directions so I can see
how to control the device.

	I have talked to  Carolyn Scheppner at CATS about her "CMD"
program which snoops the parallel port, but unfortunately it just
snoops the Exec calls and won't intercept data that "Goes to the Metal".
:-)

	So do any of you programmers know of a good way to snoop what
the parallel port is doing other than hooking up some sort of logic
analyzer to the pins?

	Thanks mucho!

						-- Glenn Lewis
--
Glenn Lewis | glewis@pcocd2.intel.com | These are my opinions...not Intel's
From: brianr@tekig1.PEN.TEK.COM (Brian E Rhodefer)
Newsgroups: comp.sys.amiga.programmer
Subject: Help sought for use of RectFill()
Date: 29 Dec 92 06:39:13 GMT
Distribution: na

I'm trying to concoct a simple program for a fellow member of my
user's group, involving annunciating selected screen areas by
drawing simple rectangular boxes around them.  I'd have used
Move() and Draw() operations (or possibly even  DrawBorder()),
except that I wanted a two-pixel-wide border, and I thought it'd
be more expedient to render the boxes as four rectangles.

My problem is that the resulting "line segments" are coming out
FOUR pixels wide, not two, and I can't figure out why.  The call
to RectFill() for the top line segment is of the form:

#define BOXLINEWIDTH 2

UpperLHCornerX = mumble1 + mumble2 * mumble3;
UpperLHCornerY = mumble4 + mumble5 * mumble6;

RectFill (myWindow->RPort,
	  UpperLHCornerX,
          UpperLHCornerY,
	  UpperLHCornerX + BOXWIDTH + 2 * BOXLINEWIDTH
	  UpperLHCornerY + BOXLINEWIDTH);

I can't see why the above call would produce a four-pixel-wide "line",
but it does.  Can someone point out the obvious thing I'm overlooking?

The Window whose RastPort I'm rendering into has been opened on a
custom screen opened using the OpenScreenTagList() call.  The
screen tag arguments list included an SA_DisplayID/HIRESLACE_KEY pair.
Thinking that the system might be throwing in a gratuitious 1-pixel
border around my box, I tried throwing in a BNDRYOFF(myWindow->RPort)
operation, to no avail.

Thanks in advance,

Brian Rhodefer
From: Jesper_Jensen@iluvatar.bbs.bad.se (Jesper Jensen)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: How to write handlers?
Date: 22 Dec 92 03:41:20 GMT
Reply-To: Jesper_Jensen@iluvatar.bbs.bad.se (Jesper Jensen)
Organization: Iluvatar BBS, Vallensbaek S, DENMARK
OD-Comment-To: Adam.costello


 A> me at the time, but I may be wanting to write a handler soon. Where
 A> do programmers get information about handlers? I've glanced at the

I don't know, if it's much help to you, but I saw an example in the RKM:
devices for 2.0.

It was something about switching the left and right mouse buttons in a
window.

Hope it helps you.

Jesper, Radagast@iluvatar.bbs.bad.se
---
Xref: sparky comp.sys.amiga.programmer:17756 comp.sys.amiga.misc:19011
From: stern+@pitt.edu (Eric G Stern)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
Subject: Re: Advice to SAS/C 5.10b users
Date: 23 Dec 92 19:18:18 GMT
Followup-To: comp.sys.amiga.programmer
Organization: University of Pittsburgh

In article <Bzpywu.85G@unx.sas.com> walker@twix.unx.sas.com (Doug Walker) writes:

>Remember the original posting that started all this was by someone
>who was advising others not to upgrade to V6 because of all the 
>bugs people were talking about on the net.  This is partially
>because only "bad news" is discussed here, but it is also partially
>due to the fact that people tend to blame the compiler when their
>code acts funny. [...]
>=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =



Well, I'll say something good about SAS/C 6.1.  I was trying to port
the latest bison version 1.19 (the GNU project replacement for YACC)
and had had weird problems with memory overwrites and crashes with
6.0.  I didn't bother pursuing it at the time because I knew that 6.1
was coming out imminently.  When I upgraded to 6.1, all my problems
went away and bison worked identically with its UNIX version on a
silicon graphics.

				Eric Stern
From: cliffwd@soda.berkeley.edu (Cliff Draper)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AllocRemember - how does it work?
Date: 4 Jan 1993 02:55:43 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
Distribution: inet
NNTP-Posting-Host: soda.berkeley.edu


Sorry about that typo.  "FreeRemember(*remkey, TRUE);"  should actually read
FreeRemember(&remkey, TRUE);

You need to pass in the address of the key.  FYI, if the second argument is
FALSE when you call FreeRemember() the allocations will still be allocated,
but Intuition will free its little tags it uses to remember the allocations.
Basically it will then be like you had used AllocMem instead of AllocRemember.

-Cliff
 cliffwd@soda.Berkeley.Edu        UC Berkeley
From: john@pluto.Jpl.Nasa.Gov (John R Veregge)
Subject: Re: Is utility.library/Stricmp() broken?
Reply-To: john@pluto.Jpl.Nasa.Gov
Organization: Jet Propulsion Laboratory, Pasadena CA
Date: Tue, 29 Dec 1992 05:20:57 GMT

In article <1992Dec25.225239.27584@llyene.jpl.nasa.gov>, john@proteus.jpl.nasa.gov (John Veregge) writes:
|> Is the AmigaDOS 2.04 utility.library/Stricmp() broken?
|> ... (much drivel deleted)
|> ____________________________________________
|> 
|> John R Veregge  -  john@pluto.jpl.nasa.gov

(Incidental music please... Elmer Fudd laughing will do {-; {-; {-;)

I always use the Aztec 5.2a C glue routines, instead of the pragma's,
when testing because it speeds up the builds. I tested Stricmp() using
the pragma's after I posted the aformentioned message. The pragma's
worked fine. The problem was not in the AmigaDOS routine Stricmp(),
but Aztec's 5.2a glue routine for it. Ummm, err, never mind...

I think I'll go back to the safer world of X11 development. {-; {-; {-;
____________________________________________

John R Veregge  -  john@pluto.jpl.nasa.gov
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sun, 3 Jan 1993 20:48:43 GMT

In <doiron.0kl6@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
>Yes, but you could use 256-color chunky pixels instead of 1024 color planar
>pixels and chunky would be faster.

Simply to get more colors when needed.

>I still, however, don't understand why
>you are using scaling like it's the next best thing since the Amiga, you
>are operating under reduced capacity.

Because often you don't need full capacity. Using screens with different
resolutions is one solution to the problem. Having layers that simply
leave bitplanes untouched is another solution.

A very popular example for this is a text window on top of a coloured
background.

>(inner loop)
> x'=x * (1/xscale)
> y'=y * (1/yscale)	;which does scaling
> getpixel(x',y'): putpixel(x,y)

Well, this isn't really scaling (which would need to calculate new
pixel values, f.e. with a linear filter). However, you wouldn't use
this algorithm in the form given as you want to avoid multiplications
and divisions.

> xrot=cos(theta)/xscale
> yrot=sin(theta)/yscale
>(inner loop)
> x'=x * xrot
> y'=y * yrot	;which will do your scaling and rotation in one fell swoop. 
> getpixel(x',y'): putpixel(x,y)

>The key to why chunky is so much faster lies in the last getpixel/putpixel
>pair.

Both examples use very expensive operations for each pixel. The rendering
is only a small fraction and splitting a pixel value into bits is only
a small part of the rendering operation.

>I've put up an algorithm that clearly shows why chunky is ridiculously
>faster, using a general purpose algorithm that can scale/magnify/rotate any
>image to any degree (no sanity checks :).  You're welcome to continue to
>argue, but I really think that for all intents and purposes I've proven my
>point.

Can't see that. You get to the point where you use single writepixel
and readpixel operations where you don't need that just because this
is the optimal case of chunky and the worst case of bitplanes. And you
simply 'forget' that your calculations take more time than the pixel
operations.

>OK, ok, take your depth scaling.  Your welcome.  As I said before, if you
>want to cut down to 128 colors, why not just go to 16?  Chunky would be
>faster THEN.

16 might be to small, and 16 color chunky is still quite slow as no
processor used will support nibble operations. Most advantages of chunky
displays come from the fact that the processor explicitely supports
operations on a 'chunk' (8 bits in most cases).

>Bingo.  Chunky is still faster.

Why faster ? Same operation, same amount of data, same speed.

>Your correct, the _ratio_ is still the same, but the _amount of time_
>wasted goes up incrementally, 2x, 4x, 8x etc.

Can't follow your argument here.

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: cschneid@amiga.physik.unizh.ch (Christian Schneider)
Subject: Re: App(Icon|Window) and Style Guide.
Organization: ICU - University of Zurich, Dept. of Computer Science
X-Newsreader: TIN [version 1.1 PL8]
Date: Tue, 22 Dec 1992 14:48:14 GMT

Gregory R Block (bloc1469@ee.ee.uwm.edu) wrote:
[things about AppIcon tool type deleted]
: That's how _I_ think it should work.

Agree.

: "lipping" windows and icons should become the standard look for

Hmm.. Anyone cares to write a Workbench enhancement/replacement?
I'd vote for an Arexx port ;-))))

- Chris

-- 
Chris Schneider - cschneid@amiga.physik.unizh.ch BIX: hschneider IRC: cschneid
It's impossible to enjoy idling thoroughly unless one has plenty of work to do
Newsgroups: comp.sys.amiga.programmer
From: Todd_Lewis@unc.edu (Todd M. Lewis)
Subject: Re: Simple C question
Organization: UNC Office of Information Technology
Date: Wed, 30 Dec 1992 14:06:40 GMT

In article <C02JCH.pC@ccu.umanitoba.ca> umbadiu0@ccu.umanitoba.ca (Ted Babiuk)  
writes:
>A have a main program which creates a child task using createtask()....
>The child task runs TO FASSST! (its a color cycling routine....)

Yes, those little tasks can really scream.  (And you didn't even
have to throw out the OS to do it. :-)

>I've  tried using a Delay(x) or wait(x) function to slow it down and make
>it delay/wait...but this either stops the task entirely (no cycling
>occures?...strange.....with Delay(10) i believe....) or crashes the
>system....:(...

That's because you are a Task, not a DOS Process.  Delay() is
a DOS function, and wait() is built on top of Delay() I think...

>I've been able to do it with a loop as follows:
>   for (count=0;count<8000;count++);
>   cycle colors....etc.
>BUT this takes processor time.....
..which is a evil thing to do.  Stay away from that.

>I could use the timer.device to do a timed wait but...
>there must be an easier way.....

Actually the timer.device is pretty easy to use.  About eight lines
of code would take care of it for you.  Sorry I don't have an example
handy right now.

>Is there something simular to a sleep() command which puts a task to sleep
>for 'x' ticks? (and uses little/no cpu time?)

Since you are color-cycling, you probably want something tied to
the video system anyway.  Why not just throw in a couple of WaitTOF();
calls?  They will guarantee you at least one frame update delay 
per call, and there is very little overhead.  You have to have
the graphics library open, but it sounds like you already do.
--
 _/_/_/  _/     Todd_Lewis@unc.edu          You can lead a horse to 
  _/    _/     utoddl@guitar.oit.unc.edu   Mohammad, but you can't make
 _/    _/_/_/                             a mountain drink a mole hill.
From: mbs@adastra.cvl.va.us (Michael B. Smith)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: GCC wont create executable
Distribution: world
X-NewsSoftware: GRn-beta 1.16g (26.12.92) by Michael B. Smith & Mike Schwartz
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: 26 Dec 92 17:28:23 EST
Organization: Well, I haven't decided on a name yet...

In article <paul.043m@dragons.DIALix.oz.au> paul@dragons.DIALix.oz.au (Paul O'Neill) writes:
> R(0);9:05AM> gcc hello.cc -lg++ -v
> Reading specs from gcc:compilers/amiga/2.2.2/specs
> gcc version 2.2.2
>  gcc:compilers/amiga/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2
> -D__cplusplus -Dmc68000 -Damiga -Damigados -DMCH_AMIGA -DAMIGA -D__mc68000__
> -D__amiga__ -D__amigados__ -D__MCH_AMIGA__ -D__AMIGA__ -D__mc68000 -D__amiga
> -D__amigados -D__MCH_AMIGA -D__AMIGA -Dmc68010 hello.cc t:cc599160.i
> GNU CPP version 2.2.2 (68k, MIT syntax)
>  gcc:compilers/amiga/2.2.2/cc1plus t:cc599160.i -quiet -dumpbase hello.cc -version -o
> t:cc599160.s
> R(1);9:05AM> _
>
> As you can see it ran 'cpp' and 'cc1plus' but then stopped with return code 1.
>
> Any suggestions anyone?

How much contiguous memory have you got when you start the g++ compile? Just
to hazard a guess, you need between 2-3 MB for a "hello world", without any
include files at all.
--
  //   Michael B. Smith
\X/    mbs@adastra.cvl.va.us  -or-  uunet.uu.net!virginia.edu!adastra!mbs
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
From: jbickers@templar.actrix.gen.nz (John Bickers)
Date: 28 Dec 92 17:58:39 PST
 <jbickers.0m2n@templar.actrix.gen.nz> <72410@cup.portal.com>     
 <1992Dec26.170503.14668@mpifr-bonn.mpg.de>   
 <jbickers.0m3z@templar.actrix.gen.nz><1992Dec27.011313.18163@mpifr-bonn.mpg.de
 > <jbickers.0m50@templar.actrix.gen.nz><1992Dec27.155756.23491@mpifr-bonn.mpg.
 de> <jbickers.0m6w@templar.actrix.gen.nz><1992Dec28.000531.26783@mpifr-bonn.mpg.de>
Organization: TAP

Quoted from <1992Dec28.000531.26783@mpifr-bonn.mpg.de> by mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst):
> In <jbickers.0m6w@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:

    [About replacing pixels of one color with those of another]

> No kidding. You are right that it is _easier_ with chunky pixels, but it
> isn't necessarily slower. At some point memory bandwidth determines

    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?

> >> Yep, drawing thin lines is a plus on chunky pixel architectures. Floodfills
> 
> >    Any kind of lines.
> 
> Nope. When you start to make lines thicker than 1 pixel you have to
> fill polygons which has some advantages on bitplanes.

    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.

> :) 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!

> True. But the WritePixel() (noone will use WritePixel !) part is only a
> small part of the rendering operation.

    Not in my limited experience.

> exernal card. It is also quite impossible to mix different scan frequencies.
> If your high-end graphics board does 1280x1024 you can't mix that with
> native Amiga screens.

    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 :).

> Michael van Elst
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: CreateNewProc NP_Arguments
Date: 3 Jan 93 08:25:33 PST
Organization: BBS

> Has anyone ever used the NP_Arguments tag using CreateNewProc or
> CreateNewProcTags.  The Bantam dos manual makes reference to
> needing to put the length of the argument string in one register
> and the pointer to it in another.  This makes no sense as the
> registers would hold info based on the CreateNewProc call and not
> on the specific tags you did or did not happen to specify--these
> are on the stack.
 
The argument pointer and length go in A0 and D0  => at the time the
new process is started up <=.  That's how a new program (except BCPL
programs) find out what the arguments are.  CreateNewProc puts the
right values there as part of what it does for you.
 
I just tried a test program that did CreateNewProcTags(..., NP_Arguments,
"string\n", ...) and it worked fine.  DO remember to end the argument
line with a \n, because the arg lines passed by the shell have one.
 
Newsgroups: comp.sys.amiga.programmer
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
 <jbickers.0m2n@templar.actrix.gen.nz> <72410@cup.portal.com>       
 <1992Dec26.170503.14668@mpifr-bonn.mpg.de>     
 <jbickers.0m3z@templar.actrix.gen.nz><1992Dec27.011313.18163@mpifr-bonn.mpg.de> <jbickers.0m50@templar.actrix.gen.nz><1992Dec27.155756.23491@mpifr-bonn.mpg.de> <jbickers.0m6w@templar.actrix.gen.nz><1992Dec28.000531.26783@mpifr-bonn.mpg.de> <jbickers.0m7s@templar.actrix.gen.nz>
 <1992Dec28.123142.5096@mpifr-bonn.mpg.de>
Date: 29 Dec 92 11:38:10 PST
Organization: TAP

Quoted from <1992Dec28.123142.5096@mpifr-bonn.mpg.de> by mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst):
> 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.

    How are they about the same speed? The easiest method I can think
    of, to make a mask of the pixels you need to change, then AND and
    OR the mask back in to get the new color, requires much more data
    movement.

> >    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. :)

    Masking off each end takes no time? Really? How?

> >> :) 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..

    Faster AND smaller. :) Hopefully at least the folks writing the OS
    routines will have access to hardware documentation, and thus be
    able to write code Amigans can be proud of.

> Michael van Elst
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
From: cs_e445@ceres (Vlod Kalicun)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Freezing for debugging
Date: 23 Dec 1992 15:50:21 GMT
Organization: Kingston University
Distribution: world
NNTP-Posting-Host: ceres.kingston.ac.uk
X-Newsreader: Tin 1.1 PL4

uphyf594@unibi.hrz.uni-bielefeld.de (Carsten Hammer) writes:
: 
:  Does anyone know of a programm that dumrpbs the whole memory and all cia
:  registers and graphic registers into a file and is able to load this 
:  into memory so that you have exactly (or nearly) the same situation
:  as you had before you dumped? I want to test a programm and need to have 
:  very precisely matching configurations. 
: 
:  ciao
: 
: -- 
: Carsten Hammer         UPHYF594@unibi.hrz.uni-bielefeld.de

The Action Replay device does exactly this. Check out the latest version tho.

Regards..

Vlod
-Amiga Advocate.
----------------------------------------------
Amiga - Anything else isn't worth considering
----------------------------------------------
Newsgroups: comp.sys.amiga.programmer