neil@cs.hw.ac.uk (Neil Forsyth) (03/03/88)
We recently got Landon Dyers MADMAC assembler for the ST and with it is a file of definitions (atari.s), a portion of which is shown below:- (risky?) _sysbase = $4f2 ; -> base of OS _shell_p = $4f6 ; -> global shell info end_os = $4fa ; -> end of OS memory usage exec_os = $4fe ; -> address of shell to exec on startup scr_dump = $502 ; -> screen dump code prv_lsto = $506 ; -> _lstostat() prv_lst = $50a ; -> _lstout() prv_auxo = $50e ; -> _auxostat() prv_aux = $512 ; -> _auxout() Question 1: Are the last five entries officially supported? " 2: If so can we have some clear documention please? (some seem fairly obvious but "Give us News before we abuse" :-) These variables don't exist in the Bios Listing (Rev A) that came with the dev-kit and lie in "No mans land" , but if Landon put them in a file for distribution ... Another issue: If the Developers Kit is now being shipped with the Mark Williams C Compiler instead of the Alcyon C Compiler where do we now stand with respect to link formats? ALCYON C,AS68,LINK68,MADMAC & ALN use DRI/CPM68K object file formats but MWC use their own (as does MEGAMAX, METACOMCO/GST etc grrr!). MWC does comes with an assembler (with pretty some stange syntax eg. a $ not a # for immediate) and a utility to convert DRI to MW link format (one way arrogance :-). To make a composite program with this mess one would have to: Assemble with MADMAC do a Partial link with ALN (I like the -i option) Convert DRI to MWC object file (Assuming of course DRTOMW.PRG likes ALN) Compile the C and link the final beast with MWC to be able to get the full benefit from MADMAC,ALN & MWC. Imagine trying this with a ram disk instead of a hard disk. :-( And speaking of ram disks: If you know anything please help Mr. Franco to fix ETERNAL2 to work with the new roms. ------------------------------------------------------------------------------- "I think all right thinking people in this country are sick and tired of being told that ordinary decent people are fed up in this country with being sick and tired. I'm certainly not and I'm sick and tired of being told that I am!" - Monty Python - "SPAM SPAM ... BAKED BEANS SPAM SPAM ... AND SPAM" Neil Forsyth JANET: neil@uk.ac.hw.cs Dept. of Computer Science ARPA: neil@cs.hw.ac.uk Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil Edinburgh Scotland -------------------------------------------------------------------------------
landon@Apple.COM (Landon Dyer) (03/05/88)
MadMac 1.0 is capable of generating MWC object files just fine, thank you. (The most recent version I'm aware of is 1.04 -- I just called it "1.0" and more or less done when I left Atari). The MWC assembler is a horror, and their linker is slow. If you're an assembly-language-only kind of person, MadMac and ALN in the MWC enviroment make a pretty good team. I used Alcyon C and ALN, which wasn't too bad. The printer variables you discovered in the "atari.s" equates file that's included with MadMac are indeed reality. -Landon -- I speak for me.
rosenkra@Alliant.COM (Bill Rosenkranz) (03/07/88)
regarding the topic of linking and compilers:
i have been using the original devkit compiler/linker (i.e. Alcyon) for
almost 2 years now. yes, yes i know that mwc:
1) is faster at compiling
2) makes smaller executables
3) documented (:^)
i have had only limited experience with mwc v1.x and (eventhough i used to
live in Chicago not far from mwc hq) i still prefer alcyon (i'm generally
using v4.14). does mwc support bit fields? how about LARGE arrays (>64k)?
i know when i was shopping megamax did not and mwc was not around.
anyway, with the advent of aln (thank you Mr. Pratt...), alcyon is at least
bearable (acutally pretty good, if you know the traps :^). alan released
aln to me generally early when the project i was working on could no longer
be linked with link68 (just tooooo B I G).
my only beef with alcyon (and it is a real annoyance) is with the inability
to redirect compiler msgs to a file (apparently it writes to CON: directly).
this is a major hassle since you have to watch the screen during EVERY compile.
i can only think of 2 ways around this: 1) set up a TSR which monitors
writes to CON: and redirects to a log file ONLY during compiles 2) hack
and slash the c{p,0,1}68.prg files to get them to use stdout.
obviously 2) is a real pain (and probably illegal). has anyone tried 1)
or another alternative? i spoke to alcyon and they have no remedy ( i asked
for src to do it myself :^). did they write gemlib? if so this is especially
stupid. does anyone know if mwc now outperforms alcyon (v2.x or new v3.0)?
seems like i remember it was slower in execution than alcyon, my highest
priority.
i generally use a homegrown cc and a (modified) make that (i believe) was
originally posted on the net, gulam the shell of choice (though i wish
it had pipes....).
thanx a priori...
-billwes@wsccs.UUCP (Barnacle Wes) (03/12/88)
In article <1351@alliant.Alliant.COM>, rosenkra@Alliant.COM (Bill Rosenkranz) writes: > does mwc support bit fields? how about LARGE arrays (>64k)? Yes, MWC supports bit fields, and Yes, MWC supports LARGE arrays. The compiler occasionally complains about large arrays, but it generates the code just fine. You can turn off the complaints with a command-line option. I have a Mega 2 at work; I use a 1 meg ram disk, and have an SH204. I put the library directory (which includes the C compiler passes), the temp directory, AND the include directory on the ram disk, and keep the source files on the hard disk. This system is not only workable, it is a joy to work with. Now, for a nice slick integrated development environment - something like a GEM-based version of make and cscope pounded together. -- /\ - " Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes