jdg@elmgate.UUCP (Jeff Gortatowsky) (09/29/86)
Two questions for the 'in the know'.
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?
Finally, saw MW C being advertised in this months Dr. Dobbs Journal. Does
anyone have the package? A small review would be nice.
Do they provide a resource construction set?
--
Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg
Eastman Kodak Company
<Kodak won't be responsible for the above comments, only those below>Lynn%PANDA@SUMEX-AIM.STANFORD.EDU (Lynn Gold) (09/30/86)
If you wish to have a RAM disk living happily with an Atari 20mb hard disk, you have to "install" it as drive F in addition to having it come up as drive F:. I've gotten a ramdisk to work with a hard disk this way. --Lynn -------
FISCHER-MICHAEL@YALE.ARPA (10/01/86)
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 <fischer@yale.arpa>
-------daford@watdragon.UUCP (Daniel Ford) (10/01/86)
I have both the 20 meg hard disk and the MW compiler. I'm quite pleased with both. As far as ram disks go I had the same problems with trying to install it as C D E or F. These seem to be reserved for the hard disk in some way (Magic?). If you install it "anywhere" after F there are no problems (provided your ram disk software lets you do that), I have mine installed as "M". The Mark W. stuff seems to be as close to a UNIX C environment as you can get without UNIX. It has a complete UNIX "MAKE" and comes with a version of uEMACS that is quite usable. If you put most of the stuff in a ram disk most compiles are faster than on a VAX. It also comes with all the GEM stuff you need. What they really need is a good debugger like "dbx". I'd buy it again. Dan Ford
dclemans@mntgfx.UUCP (Dave Clemans) (10/06/86)
A couple of miscellaneous notes about ST C compilers... Mark Williams and David Beckemeyer are supposedly working together to make their use of environment variables (and on how they store environment variables in memory) compatible so that programs can be called from either shell regardless of what compiler/runtime package was used. One reason for the difference in ST object file formats is that the "standard" GEMDOS format has a pretty limited symbol table (only eight character names & the Alcyon compiler prepends a character to externals so that you are limited to seven characters). The GST linker provides 32 significant characters; Mark Williams provides 16 significant characters; Megamax provides 10. dgc