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'?