[comp.sys.atari.st] Sozobon C

hofer@lan.informatik.tu-muenchen.dbp.de (Robert Hofer) (02/08/89)

I have some Problems with Sozobon C and hope someone outhere can help
me. I use the compiler with my Mega ST 2, 1 MB Ramdisk and the gulam   
shell.

The first problem: Sometimes i invoke cc from gulam, jas print the 
message "cant't open object file for writing". After i have exit gulam
and restart it, jas has no problem anymore. 

The second problem: After i have invoked cc -v t.c (The -v flag isn't
nessecary to get this problem) the following text is on my screen:
  cc -v t.c
  d:\sozobon\bin\hcc.ttp t.c
  d:\sozobon\bin\jas.ttp -l -u t.s
  d:\sozobon\bin\ld.ttp -p -u _main -o t.ttp -f ldfile.tmp
  Undef _main from \sozobon(main.o)
  Bad sym type
  cc: loader failed
  cmd exit code 1

The source of t.c is:
  #include <stdio.h>

  main()
       {
       int a;

       for(a=0; a<10; a++)
            printf("%d ",a);
  }

I hope anyone can help me.
-- 
|  Robert Hofer TU Muenchen         local: lan.informatik.tu-muenchen.dbp.de
|  DFN: hofer@{local}               UUCP: hofer%{local}@unido.uucp 
|  ARPA/CS: hofer%{local}@relay.cs.net

to_stdnet@stag.UUCP (02/11/89)

From: thelake!steve@stag.UUCP (Steve Yelvington)


Two would-be Sozobon C users, markr@resrch and
hofer@lan.informatik.tu-muenchen.dbp.de, posted questions:

> From: markr@resrch.UUCP
> Subject: Sozobon C - best setup?
> 	Recently I got the Sozobon C, the dlibs package and the
> 	gemfast libraries off the net. I am looking for suggestions
> 	as to the way to configure these on my system. I have a 
> 	standard 520 with a 1/2 meg and a single sided drive.
> 	The compiler, dlibs and gemfast will not fit on one disk.
> 	Oh, I also want to use Gulam as my shell. Any suggestions?
> 	
You really need another drive or an SF314.

You may be able to get cc, hcc, top, jas and ld onto a Twister-formatted
SSDD disk along with dLibs, the header files, the startup module and
GEMFAST. You could boot Gulam from a separate disk, then swap to the
compiler. Unfortunately, that doesn't leave any space for the program that
you're writing. Depending on how much RAM is eaten by Gulam, you may be
able to get a small RAMdisk installed and still leave enough for Sozobon
to run -- I think it takes about 230K of free memory. You also may find
that it just can't be done.

I'm running with two single-sided drives. I have the compiler stuff on A:
along with MicroEMACS 2.19 (about 61K) and have to put the GEM libraries
on B: with my .c files. 

> From: hofer@lan.informatik.tu-muenchen.dbp.de.UUCP
> Subject: Sozobon C

> I have some Problems with Sozobon C and hope someone outhere can help
> me. I use the compiler with my Mega ST 2, 1 MB Ramdisk and the gulam   
> shell.
> 
> The first problem: Sometimes i invoke cc from gulam, jas print the 
> message "cant't open object file for writing". After i have exit gulam
> and restart it, jas has no problem anymore. 

That sounds like a Gulam problem, possibly with reading the environment.

> 
> The second problem: After i have invoked cc -v t.c (The -v flag isn't
> nessecary to get this problem) the following text is on my screen:
>   cc -v t.c
>   d:\sozobon\bin\hcc.ttp t.c
>   d:\sozobon\bin\jas.ttp -l -u t.s
>   d:\sozobon\bin\ld.ttp -p -u _main -o t.ttp -f ldfile.tmp
>   Undef _main from \sozobon(main.o)
>   Bad sym type
>   cc: loader failed
>   cmd exit code 1

The main.o module in dlibs does some setup work, then calls _main: (in
assembler), which is main() (in C). My guess is that ldfile.tmp isn't
being written correctly by cc, and isn't including your t.o file. Try
halting the process (cntrl-C) before cc has a chance to delete ldfile.tmp,
and take a look.

One other thing: You almost always should run with the optimizer enabled.
The main compiler (hcc) writes completely ass-backwards assembly language,
requiring the CPU to play leapfrog while executing code. Tony's optimizer
(top) untangles all that. You can just add -O to the cc command line (note
that it should be capitalized), or you can recompile CC to hard-wire
optimization "on" (which is what I did).

The exception to the rule is when you wish to include in-line assembler.
If you do something like
a001()
{
	asm(".dc.w $A001");
}
  the optimizer won't know how to handle it. In that case, run hcc and jas
to compile the module separately.


*   Watch that return address! Reply to:
*   stag!thelake!steve@bungia.mn.org  (UUCP)
*   crash!pnet51!steve@trout.nosc.mil (ARPA)

stevens@prlhp1.prl.philips.co.uk (Francis Stevens) (07/27/89)

I have a 520ST and have recently been given a copy of the Sozobon C compiler,
so far I have been using this with some success to write some small C programs.
One thing that didn't come with the disk (or on it) was any form of 
documentation for the compiler etc.. (OK I know it was free, so what do I 
expect)  But just on the off chance.... is there any one out there who knows
of any such documentation (even if it's just the name of a book I need to buy)
or if anyone has any usefull information about the compiler (like is it possibleto compile a program on another (RAM) disk ?) I would be grateful for the info.

Should I receive anything I will of course summarize it for the net !!

Many thanks.

Francis Stevens
stevens@prl.philips.co.uk
(New ST owner)    

steve@bungia.mn.org (Steve Yelvington) (07/30/89)

 stevens@prlhp1.prl.philips.co.uk (Francis Stevens) writes...
>
>I have a 520ST and have recently been given a copy of the Sozobon C compiler,
>so far I have been using this with some success to write some small C programs.
>One thing that didn't come with the disk (or on it) was any form of 
>documentation for the compiler etc.. (OK I know it was free, so what do I 
>expect)  But just on the off chance.... is there any one out there who knows
>of any such documentation (even if it's just the name of a book I need to buy)

There are 20 pages of documentation on the compiler and utilities. The
library (dLibs, by Dale Schumacher) is very well-documented separately --
30 pages or so, I think. And, of course, SOURCE CODE for everything is
published.

The whole shebang is available on the panarthea file server, or from:

Tony Andrews
5902E Gunbarrel Av.
Boulder, CO 80301 USA

I think he wants $10 (bargain of the century) for making disk copies and
mailing it to you. For a non-USA address, you probably should add
international postage.

In the meantime, you can use any good modern C reference book -- dLibs is
very complete. Do not, however, try to use ANSI-style function prototypes.

>or if anyone has any usefull information about the compiler (like is it 
>possible to compile a program on another (RAM) disk ?) 
>I would be grateful for the info.

Sure.

If you run cc with no args, it will give you an explanation.

cc -O -o d:\fubar.tos c:\fubar.c b:\neatstuf.s a:\morestuf.o
    ^  ^     ^            ^            ^            ^
    |  |     |            |            |            |
    |  _______           c source      |          object file on drive a:
    | output this        on          asm file on drive b:
    | program on         drive c:
    | drive d:
    |
   run the
   optimizer
 
Note: hcc.ttp (the preprocessor-parser-code generator) writes totally
bass-ackwards assembler code and expects you to run top.ttp to optimize
it. The only time I do not run the optimizer is when I'm messing round
with line A (illegal opcodes), which choke the optimizer. I recompiled cc.c
to force the -O switch to be TRUE even when I forget to type it.

If you're using a RAM disk, it's best to put the compiler and/or libraries
there, using the PATH and LIB environment variables to point to them, and
keep your C code and output program on real media. If your test program
crashes the system, you really don't want to lose the work you've done.

Since the original release of Sozobon, a couple of useful third-party
add-ons have surfaced: Ian Lepore's GEMFAST bindings (two libraries,
AESFAST.A and VDIFAST.A), and David Brooks' FPLIB replacement
floating-point mathematics library. They also are on the panarthea file
server.


  -- Steve Yelvington, up at the lake in Minnesota
  ... pwcs.stpaul.gov!stag!thelake!steve

david.megginson@canremote.uucp (DAVID MEGGINSON) (07/30/89)

Where is the panartha file server, and how can I communicate with it
from BITNET?  Thanks.
---
 * Via ProDoor 3.01R 

UK14@DKAUNI2.BITNET ("O. Steinmeier") (02/07/90)

Hi!
A few weeks ago I got a copy of Sozobon C V1.01 (including
DLibs V1.2). Does anyone know if there is a new release
available? If it exists - how can I get it?
Thanks in advance,
Oliver

-----------------------------------------------------
Oliver Steinmeier        (uk14@dkauni2.BITNET)
Waldhornstr. 4-8
D-7500 Karlsruhe 1
-----------------------------------------------------

dhe@uafhcx.uucp (David Ewing) (02/21/90)

      Does anyone out there have any source code that would allow Sozobon C to
use the A-Line functions and AES?  I've gotten version 1.2, but it seems to be
lacking in a few areas, like support for all the nice graphics of the ST.  If
anyone has any source, please E-mail me...thanks.

      By the way, I still want to know the format of the Uniterm2.0e font
files...I'd really like a response.  I don't seem to be able to contact the
Author.

         -Dave

==============================================================================
 dhe@uafhcx.uark.edu                      David Ewing, University of Arkansas
 dhe@uafb15.uark.edu   "DON'T PANIC!!!"       Computer Science Engineering
==============================================================================

steve@thelake.mn.org (Steve Yelvington) (02/22/90)

[In article <3740@uafhp.uark.edu>,
     dhe@uafhcx.uucp (David Ewing) writes ... ]

> 
>       Does anyone out there have any source code that would allow Sozobon C to
> use the A-Line functions and AES?  I've gotten version 1.2, but it seems to be
> lacking in a few areas, like support for all the nice graphics of the ST.

I'm responding here instead of mail because this is a question of general
interest.

These are two different issues.

First issue: the AES (and VDI).

AES calls are supplied in the GEMFAST bindings by Ian Lepore.  GEMFAST is
in the Panarthea archives. The package includes a library of AES bindings,
a library of VDI bindings, and some utility functions. The current release
seems to be pretty reliable. Among its nicer features is a fsel_exinfo()
function that checks the GEM version and fakes the extended file selector
features if you don't have TOS 1.4 or better. It's written in MadMac, so
you can't alter things with the Sozobon assembler, but you can get it in
object library form. Incidentally, Ian should be reachable at
ian%fwbbs.citadel@thelake.mn.org.

Another, older set of GEM bindings, GEMQ by Don Farmer, also is available.
It's less fully featured, but it will assemble with jas.ttp.

Second issue: Line A.

Atari has surrounded Line A with nondisclosure agreements. There is not,
to my knowledge at least, a set of PD Line A routines. J.R. Bammi wrote an
aline.h #include file that might help you roll your own. It tells you what
values you will be able to find/change based on the Line A pointer.

You can write the basic Line A functions easily enough -- using embedded
assembler if you want. Basically you're putting illegal opcodes in the
text portion of your program. If you do:

char *getlinea()
	{
	asm(".dc.w $A000");
	}

... you'll have a Line A init function. A pointer to the Line A block will
be returned (in D0).

However, you must not try to run this -- or any C code with embedded Line
A opcodes -- through Tony's optimizer. You'll have to untangle the raw
output of hcc by hand, producing this:

	.text
	.globl	_getlinea
_getlinea:
	.dc.w   $a000 
	rts

... which you probably should have written in asm in the first place.

Generally you stuff the right values into the right memory locations,
and/or place an address in register A6. Then you feed the right $Annn
value to the 68000. Zap! But figuring out what locations need to be fed
what values is a big pain.

I haven't found Line A to be worth the hassle for general programming
except for obtaining (and modifying) such system variables as the number
of lines and columns on the TOS screen.

Here are some opcodes:

 $A000	initialize; returns Line A pointer in A0 and D0, font table
	pointer in A1, and function table pointer in A2
 $A001	put pixel
 $A002  get pixel; returns a value in D0
 $A003	draw line; may return a value (??) in D0
 $A004	draw horizontal line
 $A005	draw filled rectangle
 $A006	draw filled polygon
 $A007	bit block xfer
 $A008	text block xfer
 $A009	show mouse
 $A00A	hide mouse
 $A00B	transform mouse
 $A00C	undraw sprite
 $A00D	draw sprite
 $A00E	copy raster form
 $A00F	seed fill

If you start messing around with Line A stuff you'll begin to see
similarities between the Line A and the GEM VDI.

Disclaimer: This information comes from various public sources; none comes
from Atari documentation (which I don't have anyway).  You'll have to
determine what works by experimenting at your own risk. If any of this is
incorrect, feel free to explain why and how.

-- 
   Steve Yelvington at the (thin ice today*) lake in Minnesota
   UUCP path: ... umn-cs.cs.umn.edu!thelake!steve
   
   *16 cars through the ice so far this year! Yes, you, too, can
    have that sinking feeling....

ONM07@DMSWWU1A.BITNET (Julian Reschke) (02/23/90)

In article <3740@uafhp.uark.edu> David Ewing writes:
>       Does anyone out there have any source code that would allow Sozobon C to
> use the A-Line functions and AES?  I've gotten version 1.2, but it seems to be
> lacking in a few areas, like support for all the nice graphics of the ST.  If
> anyone has any source, please E-mail me...thanks.
Please stop using Line-A-functions NOW. All programs using Line-A won't
and CAN't run properly on Mega-St-Color-cards (8-Bit == 256 Colors!!!) or
on the TT.

___________________________ cut here _____________________________________
Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241
eMail: ONM07@DMSWWU1A.BITNET, "Julian Reschke" @ MAUS MS  (++49 251 80386)
____________________ correct me if I'm wrong _____________________________

D.M.Johnson@newcastle.ac.uk (D.M. Johnson) (03/05/90)

        This has most likely been on the net before so replies to this query
should be Emailed if possible.

        Query..  I have just got a copy of Sozobon C and began to right of
couple of programs for it. One of these programs was a simple screen load
program to swap between screens stored in memory.  This program required the
use of the Gemdos function Malloc, however the complier refused to complie.
Thinking that this was a fault in the program I just entered I entered this
very small program:

        #include <stdio.h>
        #include <osbind.h>

        main()
        {
        long address;
        address=Malloc(-1);
        printf(address);
        }

        The complier returned with Malloc failure.

        I am doing something wrong or is there a bug in the complier? If it is
a bug is there a way round it.

Thanks in advance

Dave

+------------------------------------+----------------------------------------+
| David M. Johnson                   | Janet : D.M.Johnson@uk.ac.newcastle    |
| c/o Electrical and Electronic Eng. | ARPA  : D.M.Johnson@newcastle.ac.uk    |
|     Merz Court                     | UUCP  : ...ukc!newcastle!D.M.Johnson   |
|     Newcastle University           |                                        |
|     Newcastle upon Tyne            |                                        |
|     NE1 7RU                        |                                        |
+------------------------------------+----------------------------------------+
| I DON'T KNOW ABOUT YOU BUT I COULD MURDER A CURRY said death                |
+------------------------------------+----------------------------------------+

schultzd@cpsin1.cps.msu.edu (04/02/90)

For any using Sozobon C:

I was trying to compile a file which contained multiple procedures, but
Sozo didn't like anything after the first (possibly anything not called
main() .)  I would like to be able to mudularize my programs (making a 
C program of only one procedure is kinda pointless!)

Any Comments (Or am I just an idiot with a fluke problem)
[I use gcc on a sun running unix most of the time.  Sozobon appears to
not have function prototyping.  It would be nice if it did.]

---------------------------
Thanks to replies about my Uniterm from Gulam question.  The answers I
got were all identical:  make sure uniterm.rsc is in the same directory 
as uniterm and be in that directory when you call uniterm
<paraphrased from my own memory>

I run a single DS floppy machine, and my uniterm disk has no sub-dirs.
Could it be something else.

______________________________________________________# # #__________________
        _______________________________________       # # #  
       /            ________________                  # # #   
      /________            /                          # # #
              /           /                          #  #  #
_____________/           /                          #   #   #
__________________________________________________#_____#_____#______________ 
David W. Schultz	|				|
312 N. Case Hall	| schultzd@cpsin.cps.msu.edu	|   M
Michigan State Univ.	| schultzd@frith.egr.msu.edu	|     S
E. Lansing, MI  48825	| Last Chance: 517 355-7033	|       G
________________________|_______________________________|____________________

John.Bunch@samba.acs.unc.edu (BBS Account) (08/12/90)

I have been trying to use sozobon.  I have been able to use it, but
I have not been able to use it on  2 drive system with sozobon on
drive a and my source on b.  I have it set up the way it is described
in the docs, but it crashes when it goes to find the library files.

Any help would be appreciated..  I am running it from gulam...

John Bunch.

John.Bunch@samba.acs.unc.edu

bill@mwca.UUCP (Bill Sheppard) (08/14/90)

I recently grabbed sozobin.arc and sozolib.arc from terminator, but I've
seen bits and pieces that imply there is a bug in one of the library calls.
Can someone let me know what patches/additional libraries I should acquire
to have the latest/greatest Sozobon installation?

Thanks!


-- 
################################################################################
#  Bill Sheppard -- bill@mwca.microware.com -- {uunet,sun}!mcrware!mwca!bill   #
#  Microware Systems Corporation  ---  OS-9: Seven generations beyond __/_!!   #
#######Opinions expressed are my own, though you'd be wise to adopt them!#######

ekrimen@csuchico.edu (Ed Krimen) (09/14/90)

Sozobon is PD right?  I'm looking for it for one of my BBS users.  I didn't
see it on atari.archive.  If it's there, please tell me where.  If not, could
someone please tell me where I can get it or send it to me?  The latter would
be nice, but any of the others will do as well.  Thanks for the help.

BTW, I got some source code from /atari/sources/volume02/sozobon1.2, but it
wasn't really what I was looking for.  :^)  At least I don't think so.

aa400@cleveland.Freenet.Edu (Marc A. Lombardo) (04/29/91)

I downloaded the sozobon c compiler from the atari archive, and put all of
the un-compressed files into three folders.  All files in sozobon1.zoo were
put into sozobon1, etc...  The strange thing is that there were several
makefile files that just overwrote one another.  There were also several 
other files that overwrote one another.  Should these files have uncompressed
into folders?  

Anyway, I am having a lot of trouble getting used to C, and the sozobon 
compiler.  If anyone could help me with getting started using C and 
the sozobon compiler, I would really appriciate it.  
 
Thanks in advance.

 

--
Marc A. Lombardo           User Address:aa400@cleveland.freenet.edu   ~ ~ ~
/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/--/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-   ~ ~ ~
Atari ST, MIDI, Music                                                ~~ ~ ~~
                                                                   ~~   ~   ~~

aa400@cleveland.Freenet.Edu (Marc A. Lombardo) (04/29/91)

I donwloaded the following files from atari.archive... SOZOBON1.ZOO, 
SOZOBON2.ZOO, and DLIB.ARC.  I wanted to get started using C, but I am 
greatly confused when using sozobon.  First off, when I de-compressed
the sozobon2.zoo file, many of the files had duplicate filenames 
(makfile, for example).  They just overwrote one another.  Should these
files have un-compressed into folders or something? (I am using BOOZ.TTP to
decompress the ZOO files..)
 
Anyway, if there is a C guru out there that has used sozobon c before, and
would be willing to help me out getting started with C, please mail me. 
Also, if you are a machine language guru, please mail me to help with
get started in assembly.  I have Devpac 2, but I don't know where to 
start.  
 
Thanks in advance.
 

--
Marc A. Lombardo           User Address:aa400@cleveland.freenet.edu   ~ ~ ~
/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/--/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-   ~ ~ ~
Atari ST, MIDI, Music                                                ~~ ~ ~~
                                                                   ~~   ~   ~~

bcc@Eyring.COM (Brian Cooper) (04/29/91)

In article <9104281836.AA06500@cwns10.INS.CWRU.Edu> aa400@cleveland.Freenet.Edu writes:
>
>I donwloaded the following files from atari.archive... SOZOBON1.ZOO, 
>SOZOBON2.ZOO, and DLIB.ARC.  I wanted to get started using C, but I am 
>greatly confused when using sozobon.  First off, when I de-compressed
>the sozobon2.zoo file, many of the files had duplicate filenames 
>(makfile, for example).  They just overwrote one another.  Should these
>files have un-compressed into folders or something? (I am using BOOZ.TTP to
>decompress the ZOO files..)
> 
Ha!  finally one that I know the answer to, and that no one else has already
answered!  The sozobon*.zoo files have subdirectories, and must be unpacked
with the 'x//' command to work properly -- otherwise, they will overwrite
each other (as you saw) and the files don't end up where they are supposed
to!  If you are using a shell, like gulam (I think that the sozobon developers
mostly use gulam) then unpack as follows:
zoo x// sozobon1.zoo *
If you are doing it from gem, zoo must be a .TTP file, and you give the
'x// sozobon1.zoo *' as the command line.  Note:  I think someone said that
this doesn't work before TOS 1.4 because earlier TOS's converted TTP arguments
to upper case -- I don't know.  The best way is probably to use one of the
shells that lets you select the sub-directory extraction as an option.

Did I get it all?  Flame me if I messed up on this one, but I think that's
how it goes.
Brian Cooper
bcc@eyring.com
uunet!lanai!bcc