🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #3169

Re: 680x0 assembly questions

#3169
From: markv
Date: Sat, 07 Apr 1990 18:21
116 lines
5941 bytes
> Do you know of any books that:
> a) deal with the 680x0
> b) *TEACH* you assembly along the way [i.e. I've never dealt direct with it
>                                        *HORRORS* :-]

Not personally.  I learned 680X0 assembler in an upper class systems
programming language.
 
> Also, what is needed to run code under CPR?  If I have some simple
> program which just decrements some 680x0 data register, to I still have to
> blink it to c.o?

No, you don't need c.o.  c.o is mainly for C programs.  It opens the
standard file handles as streams (Amiga DOS already has them open as
Amiga DOS files for CLI programs) and handles the WB startup message,
and builds the argv array.

In assembler, AmigaDOS gives you most of what you need.  The pointers
to DOSBase and the command line are in registers (dont remember which
ones).  You can get amigados stdin and stdout with calls to Input()
and Output().

> I guess what I am wondering is if I just want to do generic 680x0 programming
> [i.e. no Amiga system calls] does such a program need startup code, or can
> I just assemble it and run it through blink (without c.o or any of that) and
> then run it under the debugger.  What about running generic assembly from the
> CLI?

As just said, no.  You can just jump right into your code.  If not
using the startup you need to open libraries yourself, but it works
fine.  To exit the code call DOS Exit() or do a rts at the end of your
code.
 
> And let's say I want to do a bubble sort or something.  WOuld I have to call
> AllocMem(), or do the dc.* assembler directives take care of reserving data
> space?

The ds.* and dc.* work just fine, just remember that this is static
data.  If you want your code reentrant, allocate your storage on the
stack or with AllocMem.
 
> And in programs that do call Amiga specific stuff, is the c.o startup needed?
> When IS c.o needed and when is it not?

No, you still dont need c.o.  c.o really is mainly for c programs
only.  You can open the libraries yourselves and make system calls
yourself and do anything you want.  
 
> The last time I diddled with assembly was on my 6809 based CoCo, and since it
> was not multitasking (I didn't buy OS-9) there was't startup.  You just
> used a BASIC command that put the program counter at the beginning of you
> code and then you hope it reached the final RTS :-)

That works on the Amiga.  Exit() allows you do do an safe exit
regardless of how many subroutine jumps your nested, you don't need to
back out if you call Exit().  Just remember, free anything YOU
allocate and dont free anything you dont.  For instance, Input() gives
you the stdin file handle, but you didn't open them yourself, so you
dont close it.
 
> A question for those with the 1.3 RKM's.
> In the Libs and Devs, in the section on Workbench, there is the assembly 
> source to a Amiga-only startup - i.e. it only inits the AmigaDOS I/O
> (i.e. the stdio built into the Amiga ROMs *NOT* the Lattice stdio in lc.lib).
> Now - if I want such a startup, do I have to type that in, or is there an
> equivalent in Lattice?  Some #define that can be made?  Or a recompilation
> of c.a or main.c?

Lattice used to have a startup what used AmigaDOS file handles (called
a.o).  Such a thing doesn't exist, but can be done.  Type it in, and
use the Amiga I/O calls in amiga.lib (Printf, Sprintf, etc).  Or, you
can #define calls like this that use Amiga DOS handles by using Exec's
RawDoFmt or sprintf, and then pass the string to Write (Amiga DOS) or
_drwrite() (lattice).
 
> Also, is there anyway to make a C program *WITHOUT* needijng any sort of
> startup?  I remember something like that in one of the examples that comes
> with Lattice.

It works, you just need to realize that at entry NOTHING is done for
you and at exit nothing will be done.  (Most importantly any memory
allocated by lc.lib (malloc and calloc and realloc) will NOT be freed.
Same goes for Stream file handles.  You need to use AllocMem and the
DOS calls for I/O.

> Any help on any of this stuff will be GREATLY appreciated.
> 
> And I apologize if these are baby questions, but not everyone's a guru.
> 
> And finally, should I just use Lattice's assembler and CPR, or should I
> get A68K or whatever the PD/SHareware assembler is?

If you wan't to use CPR (and it DOES help) you need to use Lattice's
assembler so the symbolic debugging inforamtion gets put in the file.
 
> Thanks!!
 
Try looking at the example code out there, it is the best teacher
(especially on things like the semantics of assembler system calls).

If you want I can give you more specific details.
 
> --
> Hollywood's Animato Lives!                          ==>  Mike Jittlov  <==
> ARPA: rlcarr@space.mit.edu                                   is
> UUCP: ...!mit-eddie!space.mit.edu!rlcarr             ** The Wizard of **
> BITNET: rlcarr@space.mit.edu                        *** Speed and Time ***
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Gooderum			Only...		\    Good Cheer !!!
Academic Computing Services	       ///	  \___________________________
University of Kansas		     ///  /|         __    _
Bix:	  markgood	      \\\  ///  /__| |\/| | | _   /_\  makes it
Bitnet:   MARKV@UKANVAX		\/\/  /    | |  | | |__| /   \ possible...
Internet: markv@kuhub.cc.ukans.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Technical Details
Message-ID: <22779.261ddb39@kuhub.cc.ukans.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!kuhub.cc.ukans.edu!markv
References: <1990Apr6.202242.13920@mintaka.lcs.mit.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!kuhub.cc.ukans.edu!markv
From: markv@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.tech
Subject: Re: 680x0 assembly questions
Message-ID: <22779.261ddb39@kuhub.cc.ukans.edu>
Date: 7 Apr 90 18:21:13 GMT
References: <1990Apr6.202242.13920@mintaka.lcs.mit.edu>
Organization: University of Kansas Academic Computing Services
Lines: 116