Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!YALE.ARPA!FISCHER-MICHAEL From: FISCHER-MICHAEL@YALE.ARPA Newsgroups: net.micro.atari16 Subject: Re: HD and Reset Survivable Ram Disk, And MW C review wanted Message-ID: <8610010714.AA07549@ucbvax.Berkeley.EDU> Date: Wed, 1-Oct-86 03:14:58 EDT Article-I.D.: ucbvax.8610010714.AA07549 Posted: Wed Oct 1 03:14:58 1986 Date-Received: Thu, 2-Oct-86 21:05:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 61 First, after installing an Atari Corp. 20 megger HD on my Atari520st (w/1 meg upgrade), I'm no longer able to acces the RAM disk. I'm using the RAM disk posted some time ago that was in ASCII hex format (640 byte .prg file). The hard disk seems to insist on being drives C: D: (conficts with RAM disk) and E:. I tried patching the hex code to read BSET #5,D0 to provide me with a drive F: ram disk. No go. Drive F: IS recognized but pulling a SHOW INFO says it's got 6meg available (not quite right 8^) ). Anyone have this RAM disk living happily with an Atari Hard Disk? If so whats the correct formula? Who should be first in the AUTO folder? Is there a sequence of adding drive icons to the desktop? Maybe that's where I blew it? No. The problem is that the ramdisk drivers only intercept calls to drive 3 (= D:); simply patching the BSET is not enough. I have disassembled the whole thing and am in the process of rebuilding it in a slightly more general way. (For example, I prefer that it get the ramdisk size from a file.) I'll post it whenever I get around to finishing the job. Finally, saw MW C being advertised in this months Dr. Dobbs Journal. Does anyone have the package? A small review would be nice. I have it. It's a very promising packing, but... 1. The object files are incompatible with the ones used by everybody else (i.e. different from the developer's kit and from OSS Pascal). They provide a utility to convert developer's format to their own but not the other way around. Thus, I can't use MWC to write Pascal-callable utilities. 2. The MW argument passing conventions also seem to be subtly differnt from the standard. I wrote an OSS Pascal program that takes command line arguments and tried to call it from "msh", the micro C-shell that comes with the MW package. No go; the arguments never made it through. However, it works fine called as a .TTP file or from the PD COMMAND2 shell. Going the other way around, I recently got Beckemeyer's Multi-Tasking C-Shell and tried to call the micro emacs editor that came with MW. Also no go. It started up okay but it couldn't find its command line arguments. 3. The symbolic debugger that comes with the package is very nice and seems to work with MWC programs. However, I tried it with a random .PRG file and it refused to load it. I of course didn't expect symbols from such a file, but I did expect to be able to use the disassembler. 4. There are a number of annoying little bugs in the micro C-Shell that are not worth going into here and hopefully will be fixed in future releases. In summary: If MWC will be your ONLY software construction package, the I recommend it. The book that comes with it is nicely put together and seems pretty complete and accurate. However, the gratuitous incompatabilities with the rest of the world make it much less useful in a mixed environment that it ought to be. Do they provide a resource construction set? No. --Mike Fischer -------