🚀 go-pugleaf

This is an introductory posting to comp.sys.amiga.tech. If you are a new
reader of this group or even if you just want Amiga/Usenet information,
please read the following articles. 

It is recommended that you save this article for future reference. We
hope that you refer to this article first before posting to the net.
This helps keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed. There is an analogous posting in
comp.sys.amiga.

In rn type:
s newuser <return>
to save this article in the file News/newuser.

To read any of the following topics, type 'g' for 'go to' and the three
letter index identifier in capitals that is listed on the left. This 
article contains the following topics:

NOV   Questions and Answers about starting to program the Amiga in C.
        cmcmanis@pepper
        edwin@hcr.UUCP
MOT   Discussion of the 4.3 vs. 4.4 B2000 motherboard.
        daveh@cbmvax.UUCP
MOU   Help with Mountlist entries.
        kjohn@richp1.UUCP
REE   How to do re-entrant C code in Lattice and Manx.
        carolyn@cbmvax.UUCP
        dillon@CORY.BERKELEY.EDU.UUCP
TEC   How to get the Technical Reference Manual for the 500/2000 from
      Commodore.
        bill@cbmvax.UUCP 
UNS   Unsupported Programming Practices
        carolyn@cbmvax.UUCP
				daveh@cbmvax.UUCP

Edwin
uunet!utai!utcsri!hcr!edwin
*************************************************************************
NOV
>From: cmcmanis@pepper.UUCP
Subject: Re: Novice Question..

Hmmm, in an attempt to avoid religious battles, allow me to enumerate the
most common problems that new programmers to the Amiga encounter. (in
order of most commonness)  :

	# 1 : The library base variables are declared incorrectly, either
		in spelling, or with improper case.
	# 2 : The MANX C compiler is used without the +L option.
	# 3 : The order of the libraries is reversed when linking Lattice
		objects (Amiga.lib+LC.lib versus lc.lib+amiga.lib)
	# 4 : Something that needs to be in CHIP ram isn't there.
	# 5 : The stack is set to low when the program is run.

These are generally discovered by people who have programmed before eventually
but they are sometimes insurmountable problems to complete novices.
	
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
-----------------
Solutions to these problems:
# 1 : Fix the spelling. (hard, eh?)

# 2 : Manx uses 16 bits as a default size for ints. Lattice uses 32
bits as its default, and is therefore not subject to this. The problem
lies in trying to call a routine from Manx that requires 32 bit ints.
Most calls to the operating system and most programs or libraries that
use the operating system calls need to use 32 bit ints or they do wild
and wonderful things all over memory.  To get Manx to use 32 bits by
default, just add +L to the 'cc' line. Also, once you have done this,
remember to link with the 32 bit libraries:  c32.lib m32.lib.

# 3 : Reverse 'em. (another easy mistake, but common)

# 4 : The Amiga's custom graphics and sound chips can only access the
first 512K of memory (slow or chip memory). Therefore, anything that
these chips use must be in the first 512K of memory. This includes
Window, Gadget and BitMap structures that Intuition uses. To make sure
that you get chip memory do add the MEMF_CHIP constant to your call to
malloc:

      foobar *milkchocolate;
      milkchocolate = ( foobar * ) AllocMem (sizeof(foobar), MEMF_CHIP);

Then copy your data to the memory pointed to by "milkchocolate". 

# 5 : Set the stack using the AmigaDOS 'stack' command to be
higher than it is now. (20000 is a good start)

Edwin Hoogerbeets
uunet!utai!utcsri!hcr!edwin
*************************************************************************
MOT
From: daveh@cbmvax.UUCP
Subject: Re: B2000 Rev 4.4 Motherboard

in article <826@raven.ukc.ac.uk>, rpa@raven.ukc.ac.uk (R.P.Almeida) says:
>  Could someone at CATS tell me what the changes between 4.3 and 4.4 are ?

How about someone in Systems Design?  The R4.4 board has two resistors on
the board layout that had to be added by hand on the R4.3 board.  It also
has a few traces and things moved around, to make it easier to produce
than a R4.3 board.

> Also could someone tell me which link causes the 0x00C00000 memory to be
> mapped at 0x00080000 ?

That's the link marked J101.  But DON'T move this jumper until you get a
1 meg Fat Agnus installed, or the system will die miserably as soon as
any of that remapped-into-chipram-space-but-not-really-chip-accessable
memory gets touched.

>  I also have the memory expansion board from an A2000 (the original Amiga2000)
> populated to 1Mbyte.

Remove the memory chips and throw it away!

>  I wanted to install it in the B2000, so i disconnected link J500 on the B2000
> , so as to disable the 0x00C00000 memory totally, and installed the board.
> 	It didnt work.

No, it wouldn't.

> This worries me, are the A2000 and B2000 CPU slot timings that different?

There are some slight differences, both in timing (mainly the difference
between Thin and Fat Agnus) and in signals on the CPU slots (due to the
B2000's full CPU slot implementation).  This isn't a problem is you
design things to the published specs.  The A2000's add-on board wasn't
designed to our specifications, it was designed specifically for the
A2000, using unpublished information about the A2000 that doesn't
necessarily apply to any other Amiga.  It should only be used in an
A2000. 

-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {ihnp4|uunet|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
		"I can't relax, 'cause I'm a Boinger!"
*************************************************************************
MOU
From: kjohn@richp1.UUCP
Subject: AmigaDOS MountList Tips

                    ATTENTION ALL HARD DISK USERS:

I do not know if this is common knowledge on the net (I never saw it
before.....), but the way that AmigaDOS uses MountList information is
misleading.  

When AmigaDOS has a hard disk to use, it treats the disk as if it were a
continuous string of sectors (i.e. it ignores track information).
Normally, this is not a problem because all partion mounted on a single
disk use the same number of sectors per track.  THIS IS NOT TRUE WHEN
SIMULATING A FLOPPY DISK ON A HARD DISK!!!!!  When mounting a simulated
floppy disk, you must change the number of heads to 2, the number of track
to 80, and the number of sectors per track to 11.  This causes a problem
with AmigaDOS, because it calculates the first sector to start a partition
on based on the following formula:

(starting sector #) = (starting track #)*(# of sectors/track)*(# of sides)

This causes simulated floopy partions to start on a sector no where near
where you thought you told AmigaDOS to put it!  Since this sounds rather
confusing, here is an example:

To make a simulated floppy starting at track 100 of an ST238 (4 heads, 610
tracks (according to C.Ltd, 615 by Seagate), 26 sectors/track)

MountList entry (in error):

	DH0:
	Starting Cylinder (track) = 0
	Ending Cylinder = 99
	Sectors per Track = 26
	Number of sides (heads) = 4

	Starting Cylinder (track) = 100
	Ending Cylinder = 179
	Sectors per Track = 11
	Number of sides (heads) = 2

	DH1:
	Starting Cylinder (track) = 180
	Ending Cylinder = 609
	Sectors per Track = 26
	Number of sides (heads) = 4


One would think this would start on track 100.  Wrongo buffalo breath, if
you apply our formula from before you get:

  starting sector number = 100 * 11 * 2 == 1760

On the ST238 this is actually on physical track:

  physical track = 2200 / (26*4) = track 21.1538 (near beginning of track 21)

Yesh, you would have just trashed what ever was on track 21 instead of
using track 100 like you had asked (this has bitten me MANY times, it wiped
out my main partion for 2 days during the EXPO (made me stay up all night
Friday copying disks for Saturdays get-together)).


The correct MountList entry should have been:

desired starting track = 100

desired starting physical sector = 26 * 4 * 100 = 10400

starting logical track = 10400 / (11 * 2) = 472.7 (don't want to hit physical 
                                                   track 99, so use 473)

ending logical track = 473 + 80 - 1 = 552
(80 logical tracks per sector on a floopy)

ending physical sector = 552 * (11*2) / (26*4) = 116.8 (not quite into track
                                                        117, so use 116)

So our MountList entry should have looked like this:

	DH0:
	Starting Cylinder (track) = 0
	Ending Cylinder = 99
	Sectors per Track = 26
	Number of sides (heads) = 4

	HF0:  (Simulated Floppy)
	Starting Cylinder (track) = 473
	Ending Cylinder = 552
	Sectors per Track = 11
	Number of sides (heads) = 2

	DH1:
	Starting Cylinder (track) = 117
	Ending Cylinder = 609
	Sectors per Track = 26
	Number of sides (heads) = 4

Now, not only does it work, but be have more avilable space on our hard
drive!!!  Some of you may look at this and go, gee, why would I want to
make my HD look like part of it was a floppy drive?  Well, the first thing
that comes to mind is copying disks.  If you have to make more than 1 copy
of a disk, you can use DISKCOPY to copy it to your HD floppy and then use
DISCOPY to copy it onto as many disks as you need (due to the incredible
spped of the HD, you save the time it would have taken to read the disk the
second, third, etc. times).  This is also useful if you wish to work with a
foreign disk, just copy it to your simulated floppy.  If the disk has a
virus and it tries to trash your boot dish, it can't (it's on your HD)!

I hope this proves useful, but not too confusing.  Just remember, when you
are calculating the track numbers to use in the MountList, they are logical
track numbers calcualted off of the current MountLsit entry.


						KJohn

I can be reached at:

RealTime (prefered):  1(312)418-1236  (6pm to 10:30pm central time)

USmail:               John Kjellman
                      17302 Park Ave.
                      Lansing IL 60438

E-Mail:                kjohn@richp1.UUCP

P.S.
	I will create a program to automatically create either an entire
	MountList or individual MountList entries if demand warrents it.
-- 
|DISCLAIMER:  Being a consultant, none of my opions represent anything.       |
|             Except possiblely my own, but then again, maybe not.            |
|----------kjohn@richp1--or--USMail-17302-Park-Ave.,-Lansing-IL,-60438--------|
|          "I didn't do it, must be a bug in the operating system."           |
*************************************************************************
REE
From: carolyn@cbmvax.UUCP
Subject: Re: Reentrant Lattice C code

   I have a couple of versions of reentrant startup code which will
appear on the 1.3 Native Developer Update disks when 1.3 is released.
These startups can be used in place of Astartup (not Lstartup/c.o).
So if you program can be compiled -v and linked with Astartup.obj...
LIBRARY Amiga.lib, LC.lib, and you write YOUR code so it is reentrant,
you can link with the new reentrant startup code and create executables
that can be made resident. (like 1.3 More program, etc.)

   Making YOUR code reentrant involves having no globals except for
constants (like error message strings, etc), and library bases.
When doing OpenLibrary(), you must keep your result in a local
variable, only store to the global Base if successful, and use your
local when you CloseLibrary.

  If you have a lot of variables that need to be "known" to all of
your subroutines, you can put them all in a dynamically allocated and
cleared structure, and pass a pointer to that structure to each of your
routines.  This has a minimal impact on your coding style, and makes
it fairly easy to retrofit reentrancy on existing code.

-- 
==========================================================================
  Carolyn Scheppner -- CATS  Commodore Amiga Technical Support
  PHONE 215-431-9180   UUCP  ...{uunet,allegra,rutgers}!cbmvax!carolyn 

 Calm down.  It's just ones and zeros.
==========================================================================

>From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: Re: how to write reentrant C code?

>   Does anybody know what the dos and don'ts are to write reentrant code with
>Manx 3.4?  (or 3.6 as I will be upgrading to that soon).

	Mainly, you have to stay away from most link-library routines (C.LIB).
As you said, globals, unless they are constants, are out.  For example,
SysBase and DOSBase are globals but never change, so they are ok.  STDIO 
(in C.LIB) is DEFINATELY out.  If you stick to run-time library calls and
keep in mind your code might be running simultaniously in different contexes,
you should be fine.

	AVOID RETURNING STRUCTURES.  Many compilers, Aztec included (I'm
pretty sure), use static memory to hold structural return values.  I don't
know of anybody who uses the [mis]feature, though.

	STATIC variables, unless used purposefully, are also out.

NOTE:  This means using the main() entry point is out, as it sets up stdio.
I am not sure about using _main() ... it might work.  If all else fails,
you can compile your code +B, and assuming there are no other references
to .begin, the code is entered at the first module.  In this case you must
remember that global variables will NOT be zero'd initially, and neither
the DOS or  EXEC libraries will be open.

	Did I miss anything?

				-Matt
>From: carolyn@cbmvax.UUCP
Subject: Re: Reentrant Lattice C code

In article <Aug.4.19.20.35.1988.6604@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes:
>Could someone go over what it takes to make code RESIDENT?  I was
>sort-of-hopeing that most well-behaved programs that don't modify
>string constants (that are in the code segment), etc should work...
>right?

The Amiga 1.3 Workbench resident command just loadsegs the code and
sticks it on the DOS resident list.  It does not attempt to clone
data segments or do anything similar since it would be quite
impossible with unknown code generated by an unknown compiler or
assembler.

i.e. - If you want your program to work with Amiga RESIDENT, either
       YOU or your compiler must make that code pure.  So pure that
       it is re-executable, reentrant, etc.  So that lots of tasks 
       could all use that code at the SAME time with no problem.

I am providing a way for YOU to write pure code NOW.
Your compiler might offer something better which is compiler-specific.
If so, use it.

-- 
==========================================================================
  Carolyn Scheppner -- CATS  Commodore Amiga Technical Support
  PHONE 215-431-9180   UUCP  ...{uunet,allegra,rutgers}!cbmvax!carolyn 

 If you find my mind, please email it to me.  I seem to have mislaid it.
==========================================================================
*************************************************************************
TEC
>From: bill@cbmvax.UUCP (Bill Koester CATS)
Subject: Re: SCSI Speed (was Re: FFS speed.  Bytes/Bits per s)

In article <12330@orchid.waterloo.edu> tdwest@orchid.waterloo.edu (Terry D. West) writes:
>I posted an article requesting info about the 2090, but nobody replied :-(

You can get the A500/A2000 Technical reference manual by sending $40 US to:

      Commodore Business Machines
      Attn: Lauren Brown
      1200 Wilson Drive
      West Chester, PA 19380

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Bill Koester (CATS)            >>Commodore Amiga Technical Support<<
Commodore International Ltd.   UUCP {allegra|burdvax|rutgers|ihnp4}!cbmvax!bill
                             PHONE  (215) 431-9355
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                Pleese desrigard eny spealing airors!!!!!!!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>From: lauren@cbmvax.UUCP
Subject: Re: how to improve sound capabilities

In article <1856.AA1856@heimat> sneakers@heimat.UUCP (Dan "Sneakers" Schein) writes:
>In Message <8808100911.AA07219@decwrl.dec.com>, carli@munich.dec.com (Bernardo da Vinci - the Amiga genius) writes:
>   
>>    I'm desperately seeking for a cheap solution to set the cut off
>>    frequency of the filter to 14kHz or higher. It shouldn't be a hard job,
>>    but without any printsets it isn't a simple task (for me).
>>    Maybe someone tried it allready - I don't want to reinvent the wheel.
>>    As far as I know can this filter be turned off on newer A500 or A2000
>>    with the LED PD-Programm. So CATS, what do I have to do ???
>>
>     I wrote just such an article with a A1000 hardware hack & A2000/A500 'C'
>	 code examples when I was at CBM. It was for a (then) upcomming AmigaMail,
>	 im not sure if it was published yet or not. Lauren or Carolyn?
>
>>    Any recommendations would be appreciated.
>>    
>>    Bernhard
>    
>
>--
> Dan "Sneakers" Schein     {alegra|amiga|rutgers|uunet}!cbmvax!heimat!sneakers

Dan wrote an article called "Amiga Audio Cutoff Filter, which we published in
the March/April issue of AmigaMail.

Sorry, we do not make back issues available to non-subscribers (our supply is
limited). If you would like to subscribe to AmigaMail, send a check for
U.S $20 (22.50 in Canada, 25.00 all other global points) to:

				CATS-Orders
				1200 Wilson Drive
				West Chester, PA 19380

At the same time, you can request any back copy you might be interested
in. As long as we still have a supply, we will fulfill your request.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lauren Brown      -- CBM   >>Amiga Technical Support<<
                     UUCP  ...{allegra,caip,ihnp4,seismo}!cbmvax!lauren 
                     PHONE 215-431-9100
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
UNS
From: carolyn@cbmvax.UUCP
Subject: Unsupported Programming Practices

                              IMPORTANT !    

       Official Warning to Rom-Jumpers, Structure-Hackers, and Others
       ==============================================================
          From Commodore Engineering, Commodore-Amiga, and C.A.T.S.

     We who bring you the Amiga want to make it perfectly clear that
if you don't follow the rules, you WILL break.  

     The following practices are NOT supported !
 
       - Jumping directly to ROM code
       - Modifying or depending on private system structures 
       - Depending on the addresses of system structures or free memory
       - Ignoring hardware or software interfacing specifications


     Do not jump into ROM.  Beware of any example code that calls routines
in the $F80000 to $FFFFFF range.  Those are ROM addresses and those ROM
routines WILL move.   The only supported interface to system ROM code
is through the provided library, device, and resource calls. 

     Do not modify or depend on the format of the private system structures.
This includes the poking of copper lists, memory lists, and library bases.

     Do not depend on any address containing any particular system structure 
or type of memory.  The system modules dynamically allocate their memory
space when they are initialized.  The addresses of system structures and 
buffers differ with every OS, every model, and every configuration, as
does the amount of free memory and system stack usage. 

     If you are using the system libraries, devices, and resources, you
must follow the defined interface.  Assembler programmers (and compiler
writers) must enter functions through the library base jump tables,
with arguments passed as longs and library base address in A6.  Results
returned in D0 must be tested, and the contents of D0-D0/A0-A1 must be 
assumed lost after a system call.  

     Do not use assembler instructions which are priviledged on any 
68000 family processor.  All addresses must be 32 bits.  Do not use
the upper 8 bits for other data.  Do not execute code on your stack or
put system structures on your stack.  Do not use the TAS instruction.  
Do not use software instruction based timimg loops or delays.

     If you are programming at the hardware level, you must follow hardware
interfacing specifications.  All hardware is NOT the same.  Do not assume 
that low level hacks for speed or copy protection will work on all drives, 
or all keyboards, or all systems, or future systems.  

     Software distributers who purchase or contract software from
outside programmers must make sure that the programmers are aware
of correct programming practices and are providing software which
will not break on different machines or different OS revisions.


     We are dedicated to enhancing and expanding the capabilities of
the Amiga hardware and software, while maintaining compatibility
wherever possible for those who follow the rules.  Those who don't
follow the rules can consider themselves warned.

==========================================================================
  Carolyn Scheppner -- CATS  Commodore Amiga Technical Support
  PHONE 215-431-9180   UUCP  ...{uunet,allegra,rutgers}!cbmvax!carolyn 
==========================================================================

Subject: Re: Unsupported Programming Practices

	Don't write self-modifying code.  It currently CAN'T be supported
	for future systems.  Even if you get clever and manage to always
	overrun the cache on a 68020 system, you'll probably not overrun
	the cache on a future system.

	If you're messing with exception stacks, you're responsible for
	doing the right things for each 680x0 processor.  Note that even
	the 68010 has it's own special exception stack in some cases.

	Don't expect OS level things done by user level programs to always
	work.  Things like changing cache parameters or MMU banging are by
	definition things that should be managed by the operating system.
	Currently, some of these aren't.  In the future, they should be.  And
	programs that muck with them today will not likely work once OS 
	support is provided.

-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession