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