Conference 7.286::atarist

    Easy,
    		$ vmssweep modula2.zoo
    ---or---
    		$ vmssweep modula2
    then at the
    		ARC, ZOO, LBR file [L]?
    prompt, type Z (and return of course).
    
    	Ray

    ah, yes, well, my vmssweep only offers me the arc and lbr choices,
    not zoo.  sorry for the annoyance.
    
    					dd

It turns out that the version of VMSSWEEP I use is a newer version (V3.5)
than the version I have in [.PUBLIC.ST] (V3.4) and your correct V3.4 does
not support ZOO but V3.5 does.

So feel free to copy the newer version (V3.5) which is now in 
	LEDDEV::DISK$USER9:[WALLACE.PUBLIC.ST]

  Ray

    VMSSWEEP V1.5 doesn't seem to want to de-ZOO the MODULA2 file. I
    have no idea whether it is VMSSWEEP or the ZOO file that is at
    fault.
    
    	Ray

Dave Conroy and I were able to unpack and run this Modula-2 system. 
It's pretty neat!  Looks very complete.  It appears to include full
GEM support.  It has FAST prototyping - seems to be utilizing run-time
linking of only the module(s) that changed and stuff.  A day with a
German-English lexicon and a resource editor, and you will have a very
useful Modula-2 system.

It also generates genuine .PRG files, but some (all) of the run-time linking
code remains.  (A call is always three instructions.  Global data is A4
relative.)

Some hints for getting started:

To unzoo it, you have to say:

		cd a:\			(default directori is an empty disk)
		zoo x// modula2.arc

In order to create folders and for all the files to land in their
proper folders.

If you are using the Mark Williams shell, the "/" is a quote character,
so you have to quote it in single quotes as follows:

		zoo 'x//' modula2.arc

zoo needs to see TWO /'s.  If you leave off the quotes, it only sees one.

There is a file that contains some sort of search path that has hard
references to drive A:, so you have to either edit this file, or use
drive A.  It won't work if you just dump everything into one folder with
a simple:

	zoo -extract

You start by running M2LOADER.PRG, and always take the default of
"M2SHELL.OBM", which is the development environment.

If you put a copy of microemacs on the disk as "editor.prg", the
"editor" option in the "file" (Datei) menu will work.  I suspect it
would work with SEDT also.  (I'm going to build a German Microemacs 3.10_J
just for use with this system.  Seems fitting.)

We modified and recompiled the HELLO.MOD file with success.
If you put a call to "HALT;" in your program, it calls up the debugger,
and you can look at all the data in a VERY fancy multi-window
environment.  There doesn't appear to be any stepping.  You can contine
the program, and it will stop at your next hard-coded HALT;.  However,
if you keep your module size small, the recompile step needed to add
breakpoints shouldn't be too bad.

I have seem some hints that this might have originally been done in
English, with German resource files added after the fact.  Perhaps the
English resource files will show up?  Who knows.

    ok, finally got it de-zoo'd and running and i'm very impressed.  let me
    make a few random observations (based on a bog-standard atari 1040)...
    
    o let's switch everything to zoo!  it's marvelous.  i didn't bother
    with booz, but went straight for zoo.ttp.  it sorts everything out into
    the proper directories, and was not at all difficult to use (at least,
    not after jeff gave the proper command :-{) )
    
    o to elaborate on .-1 a bit: place modula2.zoo and zoo.ttp in a
    suitably big ram disk, put a blank double-sided diskette in the drive,
    and de-arc as in .-1.
    
    o i'm not quite sure what the intention is when they suggest their
    organisation of files across two diskettes.  i tried it, and kept
    coming up with error messages about files not being found.  i don't
    think i've found the best way, but i have discovered that:
    
    a) files in the ram disk don't have to be in the diskette (obviously)
    
    b) you have to put m2loader.prg into the ram disk.
    
    c) the compiler "keeps" things in memory after having loaded them for
    the first time (i.e. m2shell, compiler.obm and some other .obm files)
    therefore, the system directory is needed at the start, but not after
    a few files are in memory (???? a guess???).  there are some flags you
    can set under the compiler, debbuger menu option which i think will
    change this (??? another guess ???).
    
    d) as the documentation says, putting the sbm directory in the ram disk
    will speed up the compiler.  however, no matter what i put in copy.lst
    (the list of files to auto-load to the ram disk) i can't get it to
    auto-load the directory.  note: the copy.lst they supply doesn't load
    the sbm directory either.
    
    o using microemacs as one's editor on a small system such as mine could
    lead to complaints like (translating roughly) "can't find editor or
    must do garbage collection (Speicherplatz?)"  i think this is telling
    me that due to all the stuff (compiler, debugger, ram-disk, etc)
    hanging around memory, it can't find room for the editor.  and i must
    say, i can't blame it:  at ~108,000 bytes, MICROemacs may be emacs but
    it isn't very micro.  if this causes me too much trouble, i'll have to
    look for a smaller editor, but i do like microemacs.  (as an aside, how
    come gulam, which has ue built in, is smaller than microemacs?...
    perhaps one could customise it by leaving things out that one doesn't
    use?  i'll be looking into this).
    
    o i've gotten a couple of very attractive form_alerts complaining about
    address errors and bus errors.  i think these have to do with lack of
    memory, and filling up the ram-disk.
    
    o they appear to have included many interesting modules.  as well as
    aes and vdi and xbios things, it seems to have a higher-level interface
    to aes/vdi called (i think) windowsba (just have a look around the *lib
    directories).  at a glance, it appeared to be the interface they use in
    the compilation system, so it's no wimp (or rather, it is, but that's
    another acronym).
    
    o the way i've been using it is to have the diskettes set up as they
    state, with the addition of sbm on the start-disk.  after booting, i
    copy my .mod program to work on onto the ram disk.  then i get into
    modula with the start-disk in the drive.  edit/compile/run my heart
    out.  if i want to make a standalone program, i have to place the
    standalone directory (with contents) into the ram disk, then choose the
    .PRG option.  if you don't do this, it gives an error stating that
    standalone must be located in the folder that m2loader was loaded from.
    
    o there seem to be 2 copies of some things, and a few files in the
    wrong folders.  i'll be playing with changing these.
    
    o although translating the system to english is obviously possible,
    after a quick scan of the .rsc files, i realised that most (if not all)
    of the error messages aren't in there (they must be done with
    form_alerts inside the program), so only a partial translation would be
    possible.  better, i thought, to leave the whole thing alone, learn and
    practise a bit of german, and get ready for 1992! (this "live and let
    live" attitude was only arrived at after several phone calls to a mate
    for whom english is a second language (no prize for guessing the
    first)).
    
    finally, well, it isn't ada, but i bet it's the closest i'm gonna get
    for free on the atari.  if it works out, my sozobon disks will start
    collecting dust.
    
    					dd
    
    

Gulam came from an old version of MicroEMACS that existed before Dan Lawrence
got his fingers in it, and added MACROs to it.

Dave Conroy's version is still nice and small.  You can't customize it
much, but if you have a C compiler...

Let me know if you want it, I'll hunt it down.

By the way, I wholeheartedly agree with your comments about ZOO.  I've
switched.  ZOO is good stuff.

Though who start using this, please let us know how it goes.  I am much more
interested in Module 2 than C and would rather do any programming on this
path.  I am interested in how complete the whole thing is.

Chad

    the best person to answer your questions is you!  we've told you
    how to get started (if i can get it loaded properly, anyone can)
    so get to it!  good luck...dd

re: -.1 

Not necessarily true.  That is why people post their reviews and opinions.
That is why there is Consumer's Report magazine :-)   So that people can learn
from others experiences.  Currently I don't have the time to delve into it
but later this summer I will have some time and I want that time to be
quality time.  That means I don't want to waste lots of time on something
that does not provide reasonable support on the ST.  I don't know Modula 2 yet
but do work a lot with Pascal and would like to do Modula.  I would like to
hear others opinions on the completeness of this package, including GEM and
MIDI support, as that is where I would like to program.

Anyway, hoping to hear your experiences with the package so that when I do break
it out, I can complete my opinion with my own experiences.

Chad

der gerne auch Module lernen m�chte und dankbar ist, etwas kostenloses
ze bekommen, da er schon allen Geld schuldet und nichts anders kaufen kann.

    I don't know much about Modula. But I've got this PD Modula 2 piece
    too. The documentation seems to be very poor. That means you have to
    know already, how Modula works, before you can use it (?).
    
    I have translated the (german) RSC files to englisch. That is:
    NEWSHELL.RSC, FSEL_BOX.RSC and DEBUG.RSC. (except the copyright text
    parts of course). Is anyone interested in this? I could make it
    available on ENet.
    
    
    Regards. / Hilmar.
    

    Yes I'm interested! Please make the modified files available on
    the net.
    
      Thanks,
    	Ray

    Hi Ray,
    
    I have translated now not only the RSC files but also the .PRG, .OBM
    and .OBX files, where german text string are contained in. 
    
    But at this point, I got some doubts, if I can make those modified
    files available. I'm affraid that I would break the Copyright of the
    author (Technical University (TU) of Munich). I'm not officially
    authorized to do this.
    
    If you're still interested, pls. send me mail.
    
    
    Sorry and regards.
    
    Hilmar.
    

    i've recently found a couple tools and a couple techniques which
    make using this modula2 compiler very nice and easy, i'll tell you
    what they are:
    
    1.  there is a program called pack2 (see note 9), which will squish
    an executable by about 30% in size, but it remains runnable.  i
    ran microemacs thru this and it went from 108K to about 69K!  this
    means i save 80K in memory whilst running it (40K in the ram disk,
    and 40k in the executable).  i've packed alot of other programs
    with this, like the sozobon compiler, linker, assembler, etc...
    the only programs which i've had errors packing are my own programs
    compiled thru sozobon (which is odd since the sozobon stuff is
    supposedly compiled with their compiler, which i WAS able to pack).
    
    2.  there is another ram disk which stores the data in a compressed
    format.  i replaced the ram disk supplied with the modula2 with
    this one (maxidisk), and i seem to save a bit of space.  it appears
    to squish text files most, with binary files not achieving very
    much compression, but still, every little bit helps.
    
    3.  i still get the editor not found, or out of memory error every
    once in a while, but by playing around, it usually goes away.  playing
    around consists of: running the compiler, or running a foreign program
    (like the editor! for example). so either i don't understand something,
    or there is an occasional bug in that part of the m2shell, or it
    may have to do with the m2paths.txt file, which i've played with,
    but not much.
    
    4. i've even been able to create a standalone program.  the hangup
    there seems to be that the standalone folder must be located in the
    folder that m2loader was initially run from (which is nearly clearly
    stated, in german, in the warning box).  this is not exactly the way i
    had read the instructions in the readme file. 

    5.  after a compilation which produced errors, m2shell automatically
    calls up the editor passing it the error file, and the source program
    file.  (i don't know if it passes it a -E switch or not.).  so i've
    been doing something like this in emacs:
    
    ^x2 (create two windows)
    ^xo (switch to other window)
    ^xb (switch to buffer (should default to program name)) <CR>
    
    that gives me the errors in the top window, and the program in the
    bottom.  unfortunately the errors look like this:
    
    ^Q^R^^S^R 55 you made a boo-boo
    
    where 55 is the error number.  you'd think they'd tell you the line
    number where the error occurred, well that's what that trash at
    the front is.  just take the ascii code for the characters and subtract
    16, and you'll figure out what it should say is:
    
    12^32 55 you made a boo-boo
    
    ie, line 12 column 32 error #55, you made a boo-boo.
    
    i'm working on an emacs macro to do lse-style "goto error", when it's
    finished i'll post it here.

    i really think this compiler is nice.  i have the usual reservations
    about being "stuck" in their shell, but once i gain some more
    experience, i'm going to try to make stand alone programs of the
    compiler and loader, etc.  the best part about having the shell
    is it can keep the compiler memory resident, and if you keep your
    source code on the ramdisk, can make compilation very fast indeed.
    
    if even one c programmer uses this compiler and becomes a fan of
    decent programming languages, it will have achieved some purpose.
    
    					dd

     By the way, there is a new version available of the modula 2 compiler
which just came accross usenets comp.binaries.atari.st.  I don't know what
the new version number is.

Bill Powers

    re: .-1, ummm, errr, any of the usual pd sw providers willing to do the
    snatch and grab on this one?  or alternatively tell me how to do it
    myself? 
    
    after the mega-praise (or, indeed, the mega-2 or mega-4 praise)
    of .-2, i've come across certain deficiencies in the provided packages.
    for example, there's no BIOS package, and XBIOS is not complete.
    Not that i'm the type that needs to jump right into the innards
    on the first go, you understand, but using XBIOS midiws, or BIOS
    Read/Write appear to be the only ways to get to the midi ports. 
    
    also, their system pseudo-package is undocumented, but appears to
    have an interesting INLINE procedure, with which one could, conceivably
    write one's own BIOS interface.  also, of course, one would have
    to know exactly how procedures pass arguments and return results.

    so, the first person to upload this will receive...my undying
    gratitude.  try stuffing that in a coffee machine.
    
    				-- dd

    OLDTMR::$1$DUA8:[WALLACE.PUBLIC.ST]MODULA2.ZOO
    
    	Ray

    all right, who's listening?  all those things i mentioned as not
    being in modula2, are in the latest version.  it has a bios module
    (with which i was succesfully able to create "music"), and masses
    and reams of documentation, including the list of procedures and
    types in the system pseudo-module.  the documentation (or at least
    my translation of it) is wrong in at least one place, so let me
    mention:
    
    they now have a built-in editor.  very slick, actually.  it is an
    .obm file, and may be kept in memory like the compiler and debugger.
    it has certain lse-like features for helping you with language syntax
    (ie hit two characters and help and it types out the language
    statement) and helping you find and correct errors.  there is an
    editor option on the options menu where you say whether you want
    to use this editor or "TEMPUS", which i assume is some other editor,
    so if you want to use emacs you have to name it tempus.prg (which
    is not what the documentation says to do.)
    
    the editor menus etc are in english.  the compiler shell is in
    german.  the documentation is in german.  some module comments are
    in english, some in german.  pretty tough on a guy who learnt spanish
    in junior high school.
    
    				--dd

     Well, there is a new modula 2 compiler, etc being sent over usenet
agian, this appears to be different from the one which came from germany.
This is a shareware compiler.  There are 28 parts to it, so it will take
a couple of days to get the whole thing, as typically the moderator of
comp.binaries.atari.st only sends 5-8 parts a day.  here is the description
the the moderator posted.

> This is a Modula-2 distribution I download from GENIE. It is a shareware
>MODULA-2 compiler.
>
>This is one of five archived files which make up the ana-systems
>Atari ST M2\68 Modula-2 Development System, SHAREWARE distribution
>version 1.0.  For full information see the .DOC files in ANA_M2_1.ARC.
>
>Archive contents:
>                   ANA_M2_1.ARC   Graphical Development Shell
>                   ANA_M2_2.ARC   Modula-2 Compiler
>                   ANA_M2_3.ARC   Modula-2 Linker
>                   ANA_M2_4.ARC   Library .DEF, .SYM , and .OBJ files
>                   ANA_M2_5.ARC   microEmacs editor
>
>First distribution: January, 1989.

  FWIW

  Bill Powers