Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!ukc!dcl-cs!bath63!pes
From: pes@bath63.ux63.bath.ac.uk (Paul Smee)
Newsgroups: comp.sys.atari.st
Subject: Re: ACTION, C compilers, and ROM cartridges
Message-ID: <684@bath63.ux63.bath.ac.uk>
Date: Mon, 22-Dec-86 06:47:28 EST
Article-I.D.: bath63.684
Posted: Mon Dec 22 06:47:28 1986
Date-Received: Tue, 23-Dec-86 18:38:15 EST
References: <1881@batcomputer.tn.cornell.edu>
Reply-To: pes@ux63.bath.ac.uk (Paul Smee)
Organization: AUCC c/o University of Bath
Lines: 21


Mostly I'd agree with Moshe, that the primary function of cartridges in
this modern high-memory age is as a copy-protection device.  In fact,
some of the cartridges now out (e.g. Backpack) seem to me to be
patently ludicrous -- virtually everything it does (with a couple exceptions,
sure) requires that you put its data disk into the drive.  If you're going
to have to insert a disk anyway, seems to me you might as well just run
the program from the disk.

There is, though, one thing I'd *reealy* like to see put onto a cartridge.
That's a *really good* debugging package.  There would be several benefits.
First, it'd always be there when you need it -- with no danger of mucking up
the one critical bit of info in the corpse by having to do disk I/O.  Second,
it would, by definition, be out of the way totally of the address space of
the program under test, meaning (a) you wouldn't have to leave room for it,
and (b) the failing program couldn't garbage it.  The latter, particularly,
is a hazard with RAM-resident debuggers.
And, with a whole 192K of potential ROM to play in, it could be be made
incredibly powerful.

So, howbout it, you 'registered software development houses'?