edwin@hcr.UUCP (Edwin Hoogerbeets) (01/25/89)
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 obsessionedwin@hcr.UUCP (Edwin Hoogerbeets) (03/04/89)
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.
This posting last modified: March 3, 1989
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.
*
To save this posting when you are using
rn or vn: s newuser <return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./newuser.
To read any of the following topics after this page, 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
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.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
*************************************************************************
,REC
>From: cmcmanis@pepper.UUCP
Subject: Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
,CUS
>From: papa@pollux.usc.edu.UUCP
Subject: Re: Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
,EXC
>From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: Re: Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
,IFF
>From: carolyn@cbmvax.UUCP
Subject: Re: IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
,REQ
>From: koster@cory.Berkeley.EDU.UUCP
Subject: Re: Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************bartonr@psu-cs.UUCP (Robert Barton) (03/07/89)
> # 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". > > Edwin Hoogerbeets > uunet!utai!utcsri!hcr!edwin This is a new one to me. When the OpenWindow() routine allocates the memory for the Window structure it asks for MEMF_CLEAR | MEMF_PUBLIC. Same with OpenScreen() when allocating a Screen or RasInfo structure. Since a Screen contains a ViewPort, a RastPort, a BitMap, and a LayerInfo this implies that none of these structures need to be in chip memory either.
kevin@uts.amdahl.com (Kevin Clague) (03/08/89)
In article <1739@psu-cs.UUCP> bartonr@psu-cs.UUCP (Robert Barton) writes: >> # 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". >> >> Edwin Hoogerbeets >> uunet!utai!utcsri!hcr!edwin > > This is a new one to me. When the OpenWindow() routine allocates the >memory for the Window structure it asks for MEMF_CLEAR | MEMF_PUBLIC. Same >with OpenScreen() when allocating a Screen or RasInfo structure. Since a >Screen contains a ViewPort, a RastPort, a BitMap, and a LayerInfo this >implies that none of these structures need to be in chip memory either. It is true that things the custom chips need to access need to be in CHIP RAM. The "art" or hard part is knowing which things the custom chips actually access. Example: Bit planes need to be in CHIP RAM, but RastPort and Window structures do not. The 680X0 access these higher level structures, and eventually calls the custom chips to actually manipulate data in your viewport or screen's bitmaps. Here is a list of the places where some of the resources should be placed (I wish I had RKM's here at work): CHIP RAM NOT CHIP RAM ________ ___________ BitPlanes BitMap structure RastPort structure LayerInfo structure Window structure NewWindow structure Screen structure NewScreen structure ViewPort structure BitPlanes Image structure Border structure So you see that really very few things actually need to be in chip RAM. I hope this helps. Kevin -- UUCP: kevin@uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
cmcmanis%pepper@Sun.COM (Chuck McManis) (03/09/89)
In article <1739@psu-cs.UUCP> bartonr@psu-cs.UUCP (Robert Barton) writes: > This is a new one to me. When the OpenWindow() routine allocates the >memory for the Window structure it asks for MEMF_CLEAR | MEMF_PUBLIC. Same >with OpenScreen() when allocating a Screen or RasInfo structure. Since a >Screen contains a ViewPort, a RastPort, a BitMap, and a LayerInfo this >implies that none of these structures need to be in chip memory either. You are correct, the custom chips (blitter, dma channels) never "see" the various structures, they see the data. That is why you can allocate a RastPort from anywhere but the actual data areas that the PlanePtrs of the BitMap structure point to must be in chip memory. Same is true with Audio device or Trackdisk device requests, the IORequest struct can be in any kind of memory but the data buffers must be in chip memory. The only place this gets kinda weird are things like the Image data in an Intuition Image structure. This my not appear at first as data for a custom chip, however Intuition does indeed point the blitter at it and blit so it too has to be in chip memory. --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.
edwin@hcr.UUCP (Edwin Hoogerbeets) (04/03/89)
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.
This posting last changed: April 3, 1989
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.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 too 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: cbmvax!lauren (Lauren Brown CATS)
Subject: Re: Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
*************************************************************************
,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
*************************************************************************
,REC
>From: cmcmanis@pepper.UUCP
Subject: Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
,CUS
>From: papa@pollux.usc.edu.UUCP
Subject: Re: Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
,EXC
>From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: Re: Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
,IFF
>From: carolyn@cbmvax.UUCP
Subject: Re: IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
,REQ
>From: koster@cory.Berkeley.EDU.UUCP
Subject: Re: Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
,BUG
From: bryce@cbmvax.UUCP
Subject: Re: Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
,STA
From: peter@sugar.UUCP
Subject: Re: A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************ehoogerbeets@rose.waterloo.edu (Edwin Hoogerbeets) (05/03/89)
[Please note my new address: ehoogerbeets@rose.waterloo.edu or
uunet!watmath!rose!ehoogerbeets. Please do not send to hcr!edwin
anymore]
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.
This posting last changed: April 3, 1989
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
Edwin
edwin@rose.waterloo.edu
*************************************************************************
,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 too 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: cbmvax!lauren (Lauren Brown CATS)
Subject: Re: Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
*************************************************************************
,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
*************************************************************************
,REC
>From: cmcmanis@pepper.UUCP
Subject: Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
,CUS
>From: papa@pollux.usc.edu.UUCP
Subject: Re: Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
,EXC
>From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: Re: Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
,IFF
>From: carolyn@cbmvax.UUCP
Subject: Re: IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
,REQ
>From: koster@cory.Berkeley.EDU.UUCP
Subject: Re: Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
,BUG
From: bryce@cbmvax.UUCP
Subject: Re: Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
,STA
From: peter@sugar.UUCP
Subject: Re: A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************ehoogerbeets@rose.waterloo.edu (Edwin Hoogerbeets) (06/03/89)
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.
This posting last changed: June 2, 1989
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
Edwin
edwin@rose.waterloo.edu
*************************************************************************
,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 too 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. To make sure that
you get chip memory do add the MEMF_CHIP constant to your call to
AllocMem:
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) A rule of thumb is to
double the current size and try again until it works.
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 Usenet (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!!!!!
[You might want to simulate a floppy disk on your hard drive
so that you can use the Amiga 1.3 DISKCOPY program which only
does the job when it believes that the source and destination
disks are identical. That is, the number of tracks, the number
of sectors per track and the number of heads].
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 nowhere 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
HF0: (Simulated Floppy)
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. Wrong!
If you apply the 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)
Yes, you would have just trashed what ever was on track 21 instead of
using track 100 as 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
[ Each mountlist entry seems to separately tell AmigaDOS the complete
physical configuration of the drive, but the calculations for starting
cylinder, track and number of sectors per surface are simply providing
a non-overlapping method of telling AmigaDOS which is calculated sector
to assign as the first sector within a logical partition. All of the
calculations come down to that.]
Some of you may look at this and say, "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
speed 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 calculated from of the current MountList entry.
KJohn
I can be reached at:
RealTime (prefered): 1(312)403-4762 (6pm to 10:30pm central time)
USmail: John Kjellman
14465 Middle Pine Creek Dr.
Orland Park, IL 60462
E-Mail: kjohn@richp1.UUCP
*************************************************************************
,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: cbmvax!lauren (Lauren Brown CATS)
Subject: Re: Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
-------------
New documents:
Commodore-Amiga, Incorporated. Amiga Technical Reference Series.
Reading, Massachusets: Addison-Wesley Publishing Company, Inc.; 1989; 3
volumes; 28 cm.
Amiga Hardware Reference Manual.
[STILL on order] approx $30
Amiga ROM Kernal Reference Manual: Libraries & Devices.
[STILL on order] approx $40
Amiga ROM Kernal Reference Manual: Includes & Autodocs. approx. 760
pages. "This manual corresponds to V1.3 system software release."
ISBN 0-201-18177-0. $32.95. Commodore Item Number 327271-06.
Introduction
Library Summaries
diskfont.doc exec.doc expansion.doc graphics.doc icon.doc
intuition.doc layers.doc mathffp.doc mathieeedoubbas.doc
mathieeedoubtrans.doc mathtrans.doc translator.doc
Devices Summaries
audio.doc clipboard.doc console.doc gameport.doc input.doc
keyboard.doc narrator.doc parallel.doc printer.doc
serial.doc timer.doc trackdisk.doc
Resource Summaries
cia.doc disk.doc misc.doc potgo.doc
C Include files - ".h" Files
Assembly Include Files - ".i" Files
Linker Libraries
[amiga.lib stuff]
Sample Device, Sample Library
Reference Charts
1.3_Base_Offset_Reference
Assembly_Prefix_Reference
C_Language_Cross-Reference
Chip_Register_Map
Structure Reference
IFF - Interchange File Format
EA IFF 85 - General IFF Format Specifications
Form Specifications from the Original EA Document
Additional IFF Documents
Third Party Registered FORM and Chunk Specifications
EA IFF Source Code
Additional IFF Examples
Function Index
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
*************************************************************************
,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
*************************************************************************
,REC
>From: cmcmanis@pepper.UUCP
Subject: Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
,CUS
>From: papa@pollux.usc.edu.UUCP
Subject: Re: Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
,EXC
>From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: Re: Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
,IFF
>From: carolyn@cbmvax.UUCP
Subject: Re: IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
,REQ
>From: koster@cory.Berkeley.EDU.UUCP
Subject: Re: Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
,BUG
From: bryce@cbmvax.UUCP
Subject: Re: Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
,STA
From: peter@sugar.UUCP
Subject: Re: A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************ehoogerbeets@rose.waterloo.edu (Edwin Hoogerbeets) (07/05/89)
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.
This posting last changed: July 4, 1989
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
,BOO What the Amiga does on reboot
page@sun.COM (Bob Page)
,LIB A description of the Lattice libraries
fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Edwin
edwin@rose.waterloo.edu
*************************************************************************
,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 too 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. To make sure that
you get chip memory do add the MEMF_CHIP constant to your call to
AllocMem:
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) A rule of thumb is to
double the current size and try again until it works.
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 Usenet (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!!!!!
[You might want to simulate a floppy disk on your hard drive
so that you can use the Amiga 1.3 DISKCOPY program which only
does the job when it believes that the source and destination
disks are identical. That is, the number of tracks, the number
of sectors per track and the number of heads].
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 nowhere 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
HF0: (Simulated Floppy)
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. Wrong!
If you apply the 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)
Yes, you would have just trashed what ever was on track 21 instead of
using track 100 as 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
[ Each mountlist entry seems to separately tell AmigaDOS the complete
physical configuration of the drive, but the calculations for starting
cylinder, track and number of sectors per surface are simply providing
a non-overlapping method of telling AmigaDOS which is calculated sector
to assign as the first sector within a logical partition. All of the
calculations come down to that.]
Some of you may look at this and say, "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
speed 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 calculated from of the current MountList entry.
KJohn
I can be reached at:
RealTime (prefered): 1(312)403-4762 (6pm to 10:30pm central time)
USmail: John Kjellman
14465 Middle Pine Creek Dr.
Orland Park, IL 60462
E-Mail: kjohn@richp1.UUCP
*************************************************************************
,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: cbmvax!lauren (Lauren Brown CATS)
Subject: Re: Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
-------------
New documents:
Commodore-Amiga, Incorporated. Amiga Technical Reference Series.
Reading, Massachusets: Addison-Wesley Publishing Company, Inc.; 1989; 3
volumes; 28 cm.
Amiga Hardware Reference Manual.
[STILL on order] approx $30
Amiga ROM Kernal Reference Manual: Libraries & Devices.
[STILL on order] approx $40
Amiga ROM Kernal Reference Manual: Includes & Autodocs. approx. 760
pages. "This manual corresponds to V1.3 system software release."
ISBN 0-201-18177-0. $32.95. Commodore Item Number 327271-06.
Introduction
Library Summaries
diskfont.doc exec.doc expansion.doc graphics.doc icon.doc
intuition.doc layers.doc mathffp.doc mathieeedoubbas.doc
mathieeedoubtrans.doc mathtrans.doc translator.doc
Devices Summaries
audio.doc clipboard.doc console.doc gameport.doc input.doc
keyboard.doc narrator.doc parallel.doc printer.doc
serial.doc timer.doc trackdisk.doc
Resource Summaries
cia.doc disk.doc misc.doc potgo.doc
C Include files - ".h" Files
Assembly Include Files - ".i" Files
Linker Libraries
[amiga.lib stuff]
Sample Device, Sample Library
Reference Charts
1.3_Base_Offset_Reference
Assembly_Prefix_Reference
C_Language_Cross-Reference
Chip_Register_Map
Structure Reference
IFF - Interchange File Format
EA IFF 85 - General IFF Format Specifications
Form Specifications from the Original EA Document
Additional IFF Documents
Third Party Registered FORM and Chunk Specifications
EA IFF Source Code
Additional IFF Examples
Function Index
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
*************************************************************************
,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
*************************************************************************
,REC
>From: cmcmanis@pepper.UUCP
Subject: Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
,CUS
>From: papa@pollux.usc.edu.UUCP
Subject: Re: Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
,EXC
>From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: Re: Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
,IFF
>From: carolyn@cbmvax.UUCP
Subject: Re: IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
,REQ
>From: koster@cory.Berkeley.EDU.UUCP
Subject: Re: Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
,BUG
From: bryce@cbmvax.UUCP
Subject: Re: Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
,STA
From: peter@sugar.UUCP
Subject: Re: A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************
,BOO
From: page@Sun.COM (Bob Page)
Subject: What the Amiga does on reboot
u586182058ea@deneb.ucdavis.edu Frank Kuan wrote:
>What does the Amiga do when you reboot?
- Clear Chips (screen turns blue on custom chip failure)
- Disable DMA and Interrupts
- Clear the Screen
- Check the Hardware
- Pass or fail the Hardware to the Screen (dark grey if OK)
- Checksum the WCS (OS does not checksum the ROM)
- Pass or fail the WCS to the Screen (displays "Insert Kickstart" screen)
- System setup
- Check the for RAM at $C00000
- Move SYS_BASE to $C00000 if it exists
- RAM Test
- Pass or fail the RAM to the Screen (green if bad)
- Check the Software
- Pass or fail the Software to the Screen (light grey if OK)
- Set up the RAM
- Link the Libraries
- Find External RAM and link it to the list
- Set up Interrupts and DMA
- Start default Task
- Check for 68010, 68020, and 68881
- Check for an Exception (screen yellow if found and GURU handler not set up)
- System Reset
>Is it possible to change a vector somewhere and have the Amiga
>run your code instead of the reboot sequence?
Yes. This is one of those Amiga Secrets, most people don't discuss it
because (presumably) it encourages crackers to write viruses and other
nasty stuff.
..bob
*************************************************************************
,LIB
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Subject: Re: Lattice Library Question
>From article <690@dsacg2.UUCP>, by nor1675@dsacg2.UUCP (Michael Figg):
> I've been programming with Lattice 'C' off and on for about 2.5 years now,
> but continually get confused with what libraries need to be linked when.
Take a look at the Addendum.docs file on disk 5 of your compiler
package. Among other things it contains a description of all the files in
the LIB: directory.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: 12 :::::::::::::::::::Library Descriptions:::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
cback.o
Startup routine to detach process from CLI and run in background.
catchres.o
Startup routine to catch software exceptions in resident programs.
lcs.lib
Lattice C Library for use with 16-bit integers.
catch.o
Startup routine to catch software exceptions.
lcms.lib
Lattice Standard IEEE Math Library for use with 16-bit integers.
lcm881.lib
Lattice 68881 Coprocessor Math Library.
c.o
Standard Lattice Startup routine.
lcnb.lib
Lattice C Library for use with no base-relative data addressing.
catchresnr.o
Startup - Catch Exceptions, Resident, No Requesters on exception.
lcmffp.lib
Lattice Motorola Fast Floating Point Math Library.
lcmieee.lib
Lattice IEEE Math Library for use with Commodore Resident Library.
lcsr.lib
Lattice C Library for use with 16-bit integers and Registerized Parameters.
lcr.lib
Lattice C Library for use with Registerized Parameters.
lcmr.lib
Lattice IEEE Math Library for use with Registerized Parameters.
lc.lib
Lattice Standard C Library.
cres.o
Startup routine for Resident Programs.
lcm.lib
Lattice Standard IEEE Math Library.
lcsnb.lib
Lattice C Library for 16-bit integers and no base-relative
addressing.
ddebug.lib
Commodore debug library for use with Parallel Port.
debug.lib
Commodore debug library for use with Serial Port.
amiga.lib
Library of linkage routines to Amiga Resident Libraries.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3
*************************************************************************ehoogerbeets@rose.waterloo.edu (Edwin Hoogerbeets) (08/02/89)
[please note: next month's posting may be a little late as I am going to
work next semester (back in January). My new address will be
w-edwinh@microsoft.uucp -ed]
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.
This posting last changed: August 1, 1989
Changes this month:
Added: How to get audiotools
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
,BOO What the Amiga does on reboot
page@sun.COM (Bob Page)
,LIB A description of the Lattice libraries
fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
,AUD How to get audiotools
uunet!ardent.com!rap (Rob Peck)
Edwin
edwin@rose.waterloo.edu
(or as of September: w-edwinh@microsoft.uucp)
*************************************************************************
,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 too 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. To make sure that
you get chip memory do add the MEMF_CHIP constant to your call to
AllocMem:
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) A rule of thumb is to
double the current size and try again until it works.
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 Usenet (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!!!!!
[You might want to simulate a floppy disk on your hard drive
so that you can use the Amiga 1.3 DISKCOPY program which only
does the job when it believes that the source and destination
disks are identical. That is, the number of tracks, the number
of sectors per track and the number of heads].
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 nowhere 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
HF0: (Simulated Floppy)
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. Wrong!
If you apply the 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)
Yes, you would have just trashed what ever was on track 21 instead of
using track 100 as 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
[ Each mountlist entry seems to separately tell AmigaDOS the complete
physical configuration of the drive, but the calculations for starting
cylinder, track and number of sectors per surface are simply providing
a non-overlapping method of telling AmigaDOS which is calculated sector
to assign as the first sector within a logical partition. All of the
calculations come down to that.]
Some of you may look at this and say, "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
speed 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 calculated from of the current MountList entry.
KJohn
I can be reached at:
RealTime (prefered): 1(312)403-4762 (6pm to 10:30pm central time)
USmail: John Kjellman
14465 Middle Pine Creek Dr.
Orland Park, IL 60462
E-Mail: kjohn@richp1.UUCP
*************************************************************************
,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: cbmvax!lauren (Lauren Brown CATS)
Subject: Re: Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
-------------
New documents:
Commodore-Amiga, Incorporated. Amiga Technical Reference Series.
Reading, Massachusets: Addison-Wesley Publishing Company, Inc.; 1989; 3
volumes; 28 cm.
Amiga Hardware Reference Manual.
[STILL on order] approx $30
Amiga ROM Kernal Reference Manual: Libraries & Devices.
[STILL on order] approx $40
Amiga ROM Kernal Reference Manual: Includes & Autodocs. approx. 760
pages. "This manual corresponds to V1.3 system software release."
ISBN 0-201-18177-0. $32.95. Commodore Item Number 327271-06.
Introduction
Library Summaries
diskfont.doc exec.doc expansion.doc graphics.doc icon.doc
intuition.doc layers.doc mathffp.doc mathieeedoubbas.doc
mathieeedoubtrans.doc mathtrans.doc translator.doc
Devices Summaries
audio.doc clipboard.doc console.doc gameport.doc input.doc
keyboard.doc narrator.doc parallel.doc printer.doc
serial.doc timer.doc trackdisk.doc
Resource Summaries
cia.doc disk.doc misc.doc potgo.doc
C Include files - ".h" Files
Assembly Include Files - ".i" Files
Linker Libraries
[amiga.lib stuff]
Sample Device, Sample Library
Reference Charts
1.3_Base_Offset_Reference
Assembly_Prefix_Reference
C_Language_Cross-Reference
Chip_Register_Map
Structure Reference
IFF - Interchange File Format
EA IFF 85 - General IFF Format Specifications
Form Specifications from the Original EA Document
Additional IFF Documents
Third Party Registered FORM and Chunk Specifications
EA IFF Source Code
Additional IFF Examples
Function Index
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
*************************************************************************
,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
*************************************************************************
,REC
>From: cmcmanis@pepper.UUCP
Subject: Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
,CUS
>From: papa@pollux.usc.edu.UUCP
Subject: Re: Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
,EXC
>From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: Re: Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
,IFF
>From: carolyn@cbmvax.UUCP
Subject: Re: IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
,REQ
>From: koster@cory.Berkeley.EDU.UUCP
Subject: Re: Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
,BUG
From: bryce@cbmvax.UUCP
Subject: Re: Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
,STA
From: peter@sugar.UUCP
Subject: Re: A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************
,BOO
From: page@Sun.COM (Bob Page)
Subject: What the Amiga does on reboot
u586182058ea@deneb.ucdavis.edu Frank Kuan wrote:
>What does the Amiga do when you reboot?
- Clear Chips (screen turns blue on custom chip failure)
- Disable DMA and Interrupts
- Clear the Screen
- Check the Hardware
- Pass or fail the Hardware to the Screen (dark grey if OK)
- Checksum the WCS (OS does not checksum the ROM)
- Pass or fail the WCS to the Screen (displays "Insert Kickstart" screen)
- System setup
- Check the for RAM at $C00000
- Move SYS_BASE to $C00000 if it exists
- RAM Test
- Pass or fail the RAM to the Screen (green if bad)
- Check the Software
- Pass or fail the Software to the Screen (light grey if OK)
- Set up the RAM
- Link the Libraries
- Find External RAM and link it to the list
- Set up Interrupts and DMA
- Start default Task
- Check for 68010, 68020, and 68881
- Check for an Exception (screen yellow if found and GURU handler not set up)
- System Reset
>Is it possible to change a vector somewhere and have the Amiga
>run your code instead of the reboot sequence?
Yes. This is one of those Amiga Secrets, most people don't discuss it
because (presumably) it encourages crackers to write viruses and other
nasty stuff.
..bob
*************************************************************************
,LIB
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Subject: Re: Lattice Library Question
>From article <690@dsacg2.UUCP>, by nor1675@dsacg2.UUCP (Michael Figg):
> I've been programming with Lattice 'C' off and on for about 2.5 years now,
> but continually get confused with what libraries need to be linked when.
Take a look at the Addendum.docs file on disk 5 of your compiler
package. Among other things it contains a description of all the files in
the LIB: directory.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: 12 :::::::::::::::::::Library Descriptions:::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
cback.o
Startup routine to detach process from CLI and run in background.
catchres.o
Startup routine to catch software exceptions in resident programs.
lcs.lib
Lattice C Library for use with 16-bit integers.
catch.o
Startup routine to catch software exceptions.
lcms.lib
Lattice Standard IEEE Math Library for use with 16-bit integers.
lcm881.lib
Lattice 68881 Coprocessor Math Library.
c.o
Standard Lattice Startup routine.
lcnb.lib
Lattice C Library for use with no base-relative data addressing.
catchresnr.o
Startup - Catch Exceptions, Resident, No Requesters on exception.
lcmffp.lib
Lattice Motorola Fast Floating Point Math Library.
lcmieee.lib
Lattice IEEE Math Library for use with Commodore Resident Library.
lcsr.lib
Lattice C Library for use with 16-bit integers and Registerized Parameters.
lcr.lib
Lattice C Library for use with Registerized Parameters.
lcmr.lib
Lattice IEEE Math Library for use with Registerized Parameters.
lc.lib
Lattice Standard C Library.
cres.o
Startup routine for Resident Programs.
lcm.lib
Lattice Standard IEEE Math Library.
lcsnb.lib
Lattice C Library for 16-bit integers and no base-relative
addressing.
ddebug.lib
Commodore debug library for use with Parallel Port.
debug.lib
Commodore debug library for use with Serial Port.
amiga.lib
Library of linkage routines to Amiga Resident Libraries.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3
*************************************************************************
,AUD
>From: uunet!ardent.com!rap (Rob Peck)
Subject: audiotools
How do I play sounds on the Amiga?
I offer a disk of audiotools for the Amiga, for only $8.00. It
includes source and object code in both C and Modula that makes it
easier to add audio to your programs. It includes functions for
obtaining and releasing audio channels, playing notes, explicit
frequencies, sampled sounds, allows queueing of sounds to play, and
even includes an ability to synchronize sound and graphics by having
the audio.device itself tell you when a particular note begins to
play. The audiotools are a continuing project, based on an article I
originally wrote for Amiga World: July, 1987, but updated to add more
capabilities, and with the text of the article now explaining the
latest version of the tools. As of this writing, the audiotools are at
release 3.0, the same level as that released at the Washington DC
developers conference. I encourage submission of additional features
and functions for and from interested parties. Pseudo public
domain... that is, NO ROYALTIES, but I would hope that interested
parties would contact me directly so that I can continue to receive
suggestions for improvements and bug reports. Rob Peck, DATAPATH,
POBox 1828, Los Gatos, CA 95031
Rob Peck
*************************************************************************w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) (11/01/89)
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.
This posting last changed: August 1, 1989
Changes this month: none
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed. Previously deleted topics are still
available from the editor via email.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
,BOO What the Amiga does on reboot
page@sun.COM (Bob Page)
,LIB A description of the Lattice libraries
fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
,AUD How to get audiotools
uunet!ardent.com!rap (Rob Peck)
Edwin
edwin@rose.waterloo.edu
(or as of September: w-edwinh@microsoft.uucp)
*************************************************************************
,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 too 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. To make sure that
you get chip memory do add the MEMF_CHIP constant to your call to
AllocMem:
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) A rule of thumb is to
double the current size and try again until it works.
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 Usenet (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!!!!!
[You might want to simulate a floppy disk on your hard drive
so that you can use the Amiga 1.3 DISKCOPY program which only
does the job when it believes that the source and destination
disks are identical. That is, the number of tracks, the number
of sectors per track and the number of heads].
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 nowhere 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
HF0: (Simulated Floppy)
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. Wrong!
If you apply the 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)
Yes, you would have just trashed what ever was on track 21 instead of
using track 100 as 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
[ Each mountlist entry seems to separately tell AmigaDOS the complete
physical configuration of the drive, but the calculations for starting
cylinder, track and number of sectors per surface are simply providing
a non-overlapping method of telling AmigaDOS which is calculated sector
to assign as the first sector within a logical partition. All of the
calculations come down to that.]
Some of you may look at this and say, "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
speed 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 calculated from of the current MountList entry.
KJohn
I can be reached at:
RealTime (prefered): 1(312)403-4762 (6pm to 10:30pm central time)
USmail: John Kjellman
14465 Middle Pine Creek Dr.
Orland Park, IL 60462
E-Mail: kjohn@richp1.UUCP
*************************************************************************
,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: cbmvax!lauren (Lauren Brown CATS)
Subject: Re: Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
-------------
New documents:
Commodore-Amiga, Incorporated. Amiga Technical Reference Series.
Reading, Massachusets: Addison-Wesley Publishing Company, Inc.; 1989; 3
volumes; 28 cm.
Amiga Hardware Reference Manual.
[STILL on order] approx $30
Amiga ROM Kernal Reference Manual: Libraries & Devices.
[STILL on order] approx $40
Amiga ROM Kernal Reference Manual: Includes & Autodocs. approx. 760
pages. "This manual corresponds to V1.3 system software release."
ISBN 0-201-18177-0. $32.95. Commodore Item Number 327271-06.
Introduction
Library Summaries
diskfont.doc exec.doc expansion.doc graphics.doc icon.doc
intuition.doc layers.doc mathffp.doc mathieeedoubbas.doc
mathieeedoubtrans.doc mathtrans.doc translator.doc
Devices Summaries
audio.doc clipboard.doc console.doc gameport.doc input.doc
keyboard.doc narrator.doc parallel.doc printer.doc
serial.doc timer.doc trackdisk.doc
Resource Summaries
cia.doc disk.doc misc.doc potgo.doc
C Include files - ".h" Files
Assembly Include Files - ".i" Files
Linker Libraries
[amiga.lib stuff]
Sample Device, Sample Library
Reference Charts
1.3_Base_Offset_Reference
Assembly_Prefix_Reference
C_Language_Cross-Reference
Chip_Register_Map
Structure Reference
IFF - Interchange File Format
EA IFF 85 - General IFF Format Specifications
Form Specifications from the Original EA Document
Additional IFF Documents
Third Party Registered FORM and Chunk Specifications
EA IFF Source Code
Additional IFF Examples
Function Index
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
*************************************************************************
,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
*************************************************************************
,REC
>From: cmcmanis@pepper.UUCP
Subject: Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
,CUS
>From: papa@pollux.usc.edu.UUCP
Subject: Re: Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
,EXC
>From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: Re: Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
,IFF
>From: carolyn@cbmvax.UUCP
Subject: Re: IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
,REQ
>From: koster@cory.Berkeley.EDU.UUCP
Subject: Re: Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
,BUG
From: bryce@cbmvax.UUCP
Subject: Re: Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
,STA
From: peter@sugar.UUCP
Subject: Re: A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************
,BOO
From: page@Sun.COM (Bob Page)
Subject: What the Amiga does on reboot
u586182058ea@deneb.ucdavis.edu Frank Kuan wrote:
>What does the Amiga do when you reboot?
- Clear Chips (screen turns blue on custom chip failure)
- Disable DMA and Interrupts
- Clear the Screen
- Check the Hardware
- Pass or fail the Hardware to the Screen (dark grey if OK)
- Checksum the WCS (OS does not checksum the ROM)
- Pass or fail the WCS to the Screen (displays "Insert Kickstart" screen)
- System setup
- Check the for RAM at $C00000
- Move SYS_BASE to $C00000 if it exists
- RAM Test
- Pass or fail the RAM to the Screen (green if bad)
- Check the Software
- Pass or fail the Software to the Screen (light grey if OK)
- Set up the RAM
- Link the Libraries
- Find External RAM and link it to the list
- Set up Interrupts and DMA
- Start default Task
- Check for 68010, 68020, and 68881
- Check for an Exception (screen yellow if found and GURU handler not set up)
- System Reset
>Is it possible to change a vector somewhere and have the Amiga
>run your code instead of the reboot sequence?
Yes. This is one of those Amiga Secrets, most people don't discuss it
because (presumably) it encourages crackers to write viruses and other
nasty stuff.
..bob
*************************************************************************
,LIB
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Subject: Re: Lattice Library Question
>From article <690@dsacg2.UUCP>, by nor1675@dsacg2.UUCP (Michael Figg):
> I've been programming with Lattice 'C' off and on for about 2.5 years now,
> but continually get confused with what libraries need to be linked when.
Take a look at the Addendum.docs file on disk 5 of your compiler
package. Among other things it contains a description of all the files in
the LIB: directory.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: 12 :::::::::::::::::::Library Descriptions:::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
cback.o
Startup routine to detach process from CLI and run in background.
catchres.o
Startup routine to catch software exceptions in resident programs.
lcs.lib
Lattice C Library for use with 16-bit integers.
catch.o
Startup routine to catch software exceptions.
lcms.lib
Lattice Standard IEEE Math Library for use with 16-bit integers.
lcm881.lib
Lattice 68881 Coprocessor Math Library.
c.o
Standard Lattice Startup routine.
lcnb.lib
Lattice C Library for use with no base-relative data addressing.
catchresnr.o
Startup - Catch Exceptions, Resident, No Requesters on exception.
lcmffp.lib
Lattice Motorola Fast Floating Point Math Library.
lcmieee.lib
Lattice IEEE Math Library for use with Commodore Resident Library.
lcsr.lib
Lattice C Library for use with 16-bit integers and Registerized Parameters.
lcr.lib
Lattice C Library for use with Registerized Parameters.
lcmr.lib
Lattice IEEE Math Library for use with Registerized Parameters.
lc.lib
Lattice Standard C Library.
cres.o
Startup routine for Resident Programs.
lcm.lib
Lattice Standard IEEE Math Library.
lcsnb.lib
Lattice C Library for 16-bit integers and no base-relative
addressing.
ddebug.lib
Commodore debug library for use with Parallel Port.
debug.lib
Commodore debug library for use with Serial Port.
amiga.lib
Library of linkage routines to Amiga Resident Libraries.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3
*************************************************************************
,AUD
>From: uunet!ardent.com!rap (Rob Peck)
Subject: audiotools
How do I play sounds on the Amiga?
I offer a disk of audiotools for the Amiga, for only $8.00. It
includes source and object code in both C and Modula that makes it
easier to add audio to your programs. It includes functions for
obtaining and releasing audio channels, playing notes, explicit
frequencies, sampled sounds, allows queueing of sounds to play, and
even includes an ability to synchronize sound and graphics by having
the audio.device itself tell you when a particular note begins to
play. The audiotools are a continuing project, based on an article I
originally wrote for Amiga World: July, 1987, but updated to add more
capabilities, and with the text of the article now explaining the
latest version of the tools. As of this writing, the audiotools are at
release 3.0, the same level as that released at the Washington DC
developers conference. I encourage submission of additional features
and functions for and from interested parties. Pseudo public
domain... that is, NO ROYALTIES, but I would hope that interested
parties would contact me directly so that I can continue to receive
suggestions for improvements and bug reports. Rob Peck, DATAPATH,
POBox 1828, Los Gatos, CA 95031
Rob Peck
*************************************************************************w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) (11/29/89)
[I'm going skiing in Whistler this weekend (yeah!), so that's why this
is a bit early this month -ed]
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.
This posting last changed: August 1, 1989
Changes this month: none
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed. Previously deleted topics are still
available from the editor via email.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
,BOO What the Amiga does on reboot
page@sun.COM (Bob Page)
,LIB A description of the Lattice libraries
fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
,AUD How to get audiotools
uunet!ardent.com!rap (Rob Peck)
Edwin
edwin@rose.waterloo.edu
(or as of September: w-edwinh@microsoft.uucp)
*************************************************************************
,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 too 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. To make sure that
you get chip memory do add the MEMF_CHIP constant to your call to
AllocMem:
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) A rule of thumb is to
double the current size and try again until it works.
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 Usenet (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!!!!!
[You might want to simulate a floppy disk on your hard drive
so that you can use the Amiga 1.3 DISKCOPY program which only
does the job when it believes that the source and destination
disks are identical. That is, the number of tracks, the number
of sectors per track and the number of heads].
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 nowhere 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
HF0: (Simulated Floppy)
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. Wrong!
If you apply the 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)
Yes, you would have just trashed what ever was on track 21 instead of
using track 100 as 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
[ Each mountlist entry seems to separately tell AmigaDOS the complete
physical configuration of the drive, but the calculations for starting
cylinder, track and number of sectors per surface are simply providing
a non-overlapping method of telling AmigaDOS which is calculated sector
to assign as the first sector within a logical partition. All of the
calculations come down to that.]
Some of you may look at this and say, "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
speed 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 calculated from of the current MountList entry.
KJohn
I can be reached at:
RealTime (prefered): 1(312)403-4762 (6pm to 10:30pm central time)
USmail: John Kjellman
14465 Middle Pine Creek Dr.
Orland Park, IL 60462
E-Mail: kjohn@richp1.UUCP
*************************************************************************
,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: cbmvax!lauren (Lauren Brown CATS)
Subject: Re: Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
-------------
New documents:
Commodore-Amiga, Incorporated. Amiga Technical Reference Series.
Reading, Massachusets: Addison-Wesley Publishing Company, Inc.; 1989; 3
volumes; 28 cm.
Amiga Hardware Reference Manual.
[STILL on order] approx $30
Amiga ROM Kernal Reference Manual: Libraries & Devices.
[STILL on order] approx $40
Amiga ROM Kernal Reference Manual: Includes & Autodocs. approx. 760
pages. "This manual corresponds to V1.3 system software release."
ISBN 0-201-18177-0. $32.95. Commodore Item Number 327271-06.
Introduction
Library Summaries
diskfont.doc exec.doc expansion.doc graphics.doc icon.doc
intuition.doc layers.doc mathffp.doc mathieeedoubbas.doc
mathieeedoubtrans.doc mathtrans.doc translator.doc
Devices Summaries
audio.doc clipboard.doc console.doc gameport.doc input.doc
keyboard.doc narrator.doc parallel.doc printer.doc
serial.doc timer.doc trackdisk.doc
Resource Summaries
cia.doc disk.doc misc.doc potgo.doc
C Include files - ".h" Files
Assembly Include Files - ".i" Files
Linker Libraries
[amiga.lib stuff]
Sample Device, Sample Library
Reference Charts
1.3_Base_Offset_Reference
Assembly_Prefix_Reference
C_Language_Cross-Reference
Chip_Register_Map
Structure Reference
IFF - Interchange File Format
EA IFF 85 - General IFF Format Specifications
Form Specifications from the Original EA Document
Additional IFF Documents
Third Party Registered FORM and Chunk Specifications
EA IFF Source Code
Additional IFF Examples
Function Index
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
*************************************************************************
,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
*************************************************************************
,REC
>From: cmcmanis@pepper.UUCP
Subject: Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
,CUS
>From: papa@pollux.usc.edu.UUCP
Subject: Re: Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
,EXC
>From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: Re: Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
,IFF
>From: carolyn@cbmvax.UUCP
Subject: Re: IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
,REQ
>From: koster@cory.Berkeley.EDU.UUCP
Subject: Re: Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
,BUG
From: bryce@cbmvax.UUCP
Subject: Re: Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
,STA
From: peter@sugar.UUCP
Subject: Re: A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************
,BOO
From: page@Sun.COM (Bob Page)
Subject: What the Amiga does on reboot
u586182058ea@deneb.ucdavis.edu Frank Kuan wrote:
>What does the Amiga do when you reboot?
- Clear Chips (screen turns blue on custom chip failure)
- Disable DMA and Interrupts
- Clear the Screen
- Check the Hardware
- Pass or fail the Hardware to the Screen (dark grey if OK)
- Checksum the WCS (OS does not checksum the ROM)
- Pass or fail the WCS to the Screen (displays "Insert Kickstart" screen)
- System setup
- Check the for RAM at $C00000
- Move SYS_BASE to $C00000 if it exists
- RAM Test
- Pass or fail the RAM to the Screen (green if bad)
- Check the Software
- Pass or fail the Software to the Screen (light grey if OK)
- Set up the RAM
- Link the Libraries
- Find External RAM and link it to the list
- Set up Interrupts and DMA
- Start default Task
- Check for 68010, 68020, and 68881
- Check for an Exception (screen yellow if found and GURU handler not set up)
- System Reset
>Is it possible to change a vector somewhere and have the Amiga
>run your code instead of the reboot sequence?
Yes. This is one of those Amiga Secrets, most people don't discuss it
because (presumably) it encourages crackers to write viruses and other
nasty stuff.
..bob
*************************************************************************
,LIB
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Subject: Re: Lattice Library Question
>From article <690@dsacg2.UUCP>, by nor1675@dsacg2.UUCP (Michael Figg):
> I've been programming with Lattice 'C' off and on for about 2.5 years now,
> but continually get confused with what libraries need to be linked when.
Take a look at the Addendum.docs file on disk 5 of your compiler
package. Among other things it contains a description of all the files in
the LIB: directory.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: 12 :::::::::::::::::::Library Descriptions:::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
cback.o
Startup routine to detach process from CLI and run in background.
catchres.o
Startup routine to catch software exceptions in resident programs.
lcs.lib
Lattice C Library for use with 16-bit integers.
catch.o
Startup routine to catch software exceptions.
lcms.lib
Lattice Standard IEEE Math Library for use with 16-bit integers.
lcm881.lib
Lattice 68881 Coprocessor Math Library.
c.o
Standard Lattice Startup routine.
lcnb.lib
Lattice C Library for use with no base-relative data addressing.
catchresnr.o
Startup - Catch Exceptions, Resident, No Requesters on exception.
lcmffp.lib
Lattice Motorola Fast Floating Point Math Library.
lcmieee.lib
Lattice IEEE Math Library for use with Commodore Resident Library.
lcsr.lib
Lattice C Library for use with 16-bit integers and Registerized Parameters.
lcr.lib
Lattice C Library for use with Registerized Parameters.
lcmr.lib
Lattice IEEE Math Library for use with Registerized Parameters.
lc.lib
Lattice Standard C Library.
cres.o
Startup routine for Resident Programs.
lcm.lib
Lattice Standard IEEE Math Library.
lcsnb.lib
Lattice C Library for 16-bit integers and no base-relative
addressing.
ddebug.lib
Commodore debug library for use with Parallel Port.
debug.lib
Commodore debug library for use with Serial Port.
amiga.lib
Library of linkage routines to Amiga Resident Libraries.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3
*************************************************************************
,AUD
>From: uunet!ardent.com!rap (Rob Peck)
Subject: audiotools
How do I play sounds on the Amiga?
I offer a disk of audiotools for the Amiga, for only $8.00. It
includes source and object code in both C and Modula that makes it
easier to add audio to your programs. It includes functions for
obtaining and releasing audio channels, playing notes, explicit
frequencies, sampled sounds, allows queueing of sounds to play, and
even includes an ability to synchronize sound and graphics by having
the audio.device itself tell you when a particular note begins to
play. The audiotools are a continuing project, based on an article I
originally wrote for Amiga World: July, 1987, but updated to add more
capabilities, and with the text of the article now explaining the
latest version of the tools. As of this writing, the audiotools are at
release 3.0, the same level as that released at the Washington DC
developers conference. I encourage submission of additional features
and functions for and from interested parties. Pseudo public
domain... that is, NO ROYALTIES, but I would hope that interested
parties would contact me directly so that I can continue to receive
suggestions for improvements and bug reports. Rob Peck, DATAPATH,
POBox 1828, Los Gatos, CA 95031
Rob Peck
*************************************************************************ehoogerbeets@rose.waterloo.edu (Edwin Hoogerbeets) (01/07/90)
[Sorry about the delay this month -- lack of account prevented posting! -ed]
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.
This posting last changed: January 1, 1990
Changes this month: none
Updated: Technical Reference Manual section (,TEC)
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed. Previously deleted topics are still
available from the editor via email.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
,BOO What the Amiga does on reboot
page@sun.COM (Bob Page)
,LIB A description of the Lattice libraries
fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
,AUD How to get audiotools
uunet!ardent.com!rap (Rob Peck)
Edwin
ehoogerbeets@rose.waterloo.edu or edwin@watcsc.waterloo.edu
uunet!watmath!watrose!ehoogerbeets or uunet!watmath!watcsc!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 too 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. To make sure that
you get chip memory do add the MEMF_CHIP constant to your call to
AllocMem:
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) A rule of thumb is to
double the current size and try again until it works.
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 Usenet (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!!!!!
[You might want to simulate a floppy disk on your hard drive
so that you can use the Amiga 1.3 DISKCOPY program which only
does the job when it believes that the source and destination
disks are identical. That is, the number of tracks, the number
of sectors per track and the number of heads].
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 nowhere 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
HF0: (Simulated Floppy)
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. Wrong!
If you apply the 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)
Yes, you would have just trashed what ever was on track 21 instead of
using track 100 as 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
[ Each mountlist entry seems to separately tell AmigaDOS the complete
physical configuration of the drive, but the calculations for starting
cylinder, track and number of sectors per surface are simply providing
a non-overlapping method of telling AmigaDOS which is calculated sector
to assign as the first sector within a logical partition. All of the
calculations come down to that.]
Some of you may look at this and say, "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
speed 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 calculated from of the current MountList entry.
KJohn
I can be reached at:
RealTime (prefered): 1(312)403-4762 (6pm to 10:30pm central time)
USmail: John Kjellman
14465 Middle Pine Creek Dr.
Orland Park, IL 60462
E-Mail: kjohn@richp1.UUCP
*************************************************************************
,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: cbmvax!lauren (Lauren Brown CATS)
Subject: Re: Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
-------------
New documents:
Commodore-Amiga, Incorporated. Amiga Technical Reference Series.
Reading, Massachusets: Addison-Wesley Publishing Company, Inc.; 1989; 3
volumes; 28 cm; paperbound.
Amiga Hardware Reference Manual. approx 400 pages. "This maual
covers the A1000, A500, and A2000 release machines." ISBN
0-201-18157-6. $24.95. CBM Product Number 327272-04. Includes
glossary and index.
1. Introduction
2. Coprocessor Hardware
3. Playfield Hardware
4. Sprite Hardware
5. Audio Hardware
6. Blitter Hardware
7. System Contol Hardware
8. Interface Hardware
A. Register Summary--Alphabetical Order
B. Register Summary--Address Order
C. Custom Chip Pin Allocation List
D. System Memory Map
E. Interfaces
F. Complex Interface Adapters
G. AUTOCONFIG(tm)
H. Keyboard
I. External Disk Connector Interface Specifications
J. Hardware Example Include File
Amiga ROM Kernal Reference Manual: Libraries & Devices.
[STILL on order] approx $40
Amiga ROM Kernal Reference Manual: Includes & Autodocs. approx. 760
pages. "This manual corresponds to V1.3 system software release."
ISBN 0-201-18177-0. $32.95. Commodore Item Number 327271-06.
Introduction
Library Summaries
diskfont.doc exec.doc expansion.doc graphics.doc icon.doc
intuition.doc layers.doc mathffp.doc mathieeedoubbas.doc
mathieeedoubtrans.doc mathtrans.doc translator.doc
Devices Summaries
audio.doc clipboard.doc console.doc gameport.doc input.doc
keyboard.doc narrator.doc parallel.doc printer.doc
serial.doc timer.doc trackdisk.doc
Resource Summaries
cia.doc disk.doc misc.doc potgo.doc
C Include files - ".h" Files
Assembly Include Files - ".i" Files
Linker Libraries
[amiga.lib stuff]
Sample Device, Sample Library
Reference Charts
1.3_Base_Offset_Reference
Assembly_Prefix_Reference
C_Language_Cross-Reference
Chip_Register_Map
Structure Reference
IFF - Interchange File Format
EA IFF 85 - General IFF Format Specifications
Form Specifications from the Original EA Document
Additional IFF Documents
Third Party Registered FORM and Chunk Specifications
EA IFF Source Code
Additional IFF Examples
Function Index
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
*************************************************************************
,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
*************************************************************************
,REC
>From: cmcmanis@pepper.UUCP
Subject: Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
,CUS
>From: papa@pollux.usc.edu.UUCP
Subject: Re: Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
,EXC
>From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: Re: Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
,IFF
>From: carolyn@cbmvax.UUCP
Subject: Re: IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
,REQ
>From: koster@cory.Berkeley.EDU.UUCP
Subject: Re: Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
,BUG
From: bryce@cbmvax.UUCP
Subject: Re: Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
,STA
From: peter@sugar.UUCP
Subject: Re: A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************
,BOO
From: page@Sun.COM (Bob Page)
Subject: What the Amiga does on reboot
u586182058ea@deneb.ucdavis.edu Frank Kuan wrote:
>What does the Amiga do when you reboot?
- Clear Chips (screen turns blue on custom chip failure)
- Disable DMA and Interrupts
- Clear the Screen
- Check the Hardware
- Pass or fail the Hardware to the Screen (dark grey if OK)
- Checksum the WCS (OS does not checksum the ROM)
- Pass or fail the WCS to the Screen (displays "Insert Kickstart" screen)
- System setup
- Check the for RAM at $C00000
- Move SYS_BASE to $C00000 if it exists
- RAM Test
- Pass or fail the RAM to the Screen (green if bad)
- Check the Software
- Pass or fail the Software to the Screen (light grey if OK)
- Set up the RAM
- Link the Libraries
- Find External RAM and link it to the list
- Set up Interrupts and DMA
- Start default Task
- Check for 68010, 68020, and 68881
- Check for an Exception (screen yellow if found and GURU handler not set up)
- System Reset
>Is it possible to change a vector somewhere and have the Amiga
>run your code instead of the reboot sequence?
Yes. This is one of those Amiga Secrets, most people don't discuss it
because (presumably) it encourages crackers to write viruses and other
nasty stuff.
..bob
*************************************************************************
,LIB
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Subject: Re: Lattice Library Question
>From article <690@dsacg2.UUCP>, by nor1675@dsacg2.UUCP (Michael Figg):
> I've been programming with Lattice 'C' off and on for about 2.5 years now,
> but continually get confused with what libraries need to be linked when.
Take a look at the Addendum.docs file on disk 5 of your compiler
package. Among other things it contains a description of all the files in
the LIB: directory.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: 12 :::::::::::::::::::Library Descriptions:::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
cback.o
Startup routine to detach process from CLI and run in background.
catchres.o
Startup routine to catch software exceptions in resident programs.
lcs.lib
Lattice C Library for use with 16-bit integers.
catch.o
Startup routine to catch software exceptions.
lcms.lib
Lattice Standard IEEE Math Library for use with 16-bit integers.
lcm881.lib
Lattice 68881 Coprocessor Math Library.
c.o
Standard Lattice Startup routine.
lcnb.lib
Lattice C Library for use with no base-relative data addressing.
catchresnr.o
Startup - Catch Exceptions, Resident, No Requesters on exception.
lcmffp.lib
Lattice Motorola Fast Floating Point Math Library.
lcmieee.lib
Lattice IEEE Math Library for use with Commodore Resident Library.
lcsr.lib
Lattice C Library for use with 16-bit integers and Registerized Parameters.
lcr.lib
Lattice C Library for use with Registerized Parameters.
lcmr.lib
Lattice IEEE Math Library for use with Registerized Parameters.
lc.lib
Lattice Standard C Library.
cres.o
Startup routine for Resident Programs.
lcm.lib
Lattice Standard IEEE Math Library.
lcsnb.lib
Lattice C Library for 16-bit integers and no base-relative
addressing.
ddebug.lib
Commodore debug library for use with Parallel Port.
debug.lib
Commodore debug library for use with Serial Port.
amiga.lib
Library of linkage routines to Amiga Resident Libraries.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3
*************************************************************************
,AUD
>From: uunet!ardent.com!rap (Rob Peck)
Subject: audiotools
How do I play sounds on the Amiga?
I offer a disk of audiotools for the Amiga, for only $8.00. It
includes source and object code in both C and Modula that makes it
easier to add audio to your programs. It includes functions for
obtaining and releasing audio channels, playing notes, explicit
frequencies, sampled sounds, allows queueing of sounds to play, and
even includes an ability to synchronize sound and graphics by having
the audio.device itself tell you when a particular note begins to
play. The audiotools are a continuing project, based on an article I
originally wrote for Amiga World: July, 1987, but updated to add more
capabilities, and with the text of the article now explaining the
latest version of the tools. As of this writing, the audiotools are at
release 3.0, the same level as that released at the Washington DC
developers conference. I encourage submission of additional features
and functions for and from interested parties. Pseudo public
domain... that is, NO ROYALTIES, but I would hope that interested
parties would contact me directly so that I can continue to receive
suggestions for improvements and bug reports. Rob Peck, DATAPATH,
POBox 1828, Los Gatos, CA 95031
Rob Peck
*************************************************************************ehoogerbeets@rose.waterloo.edu (Edwin Hoogerbeets) (03/04/90)
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.
This posting last changed: March 2, 1990
Changes this month:
Added: Questions and answers about the Fatter Agnus (,AGNUS)
Also changed is that all intro postings are now in mailbox format.
Individual topics in a file called `introfile' can be accessed by
executing mail -f introfile on a Unix system.
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed. Previously deleted topics are still
available from the editor via email.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./newuser.
To read any of the following topics, type 'g' for 'go to' and the 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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
,BOO What the Amiga does on reboot
page@sun.COM (Bob Page)
,LIB A description of the Lattice libraries
fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
,AUD How to get audiotools
uunet!ardent.com!rap (Rob Peck)
,AGNUS Questions and answers about the Fatter Agnus
peter@cbmvax.commodore.com (Peter Cherna)
Edwin
ehoogerbeets@rose.waterloo.edu or edwin@watcsc.waterloo.edu
uunet!watmath!watrose!ehoogerbeets or uunet!watmath!watcsc!edwin
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: cmcmanis@pepper.UUCP
Subject: (,NOV) 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 too 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. To make sure that
you get chip memory do add the MEMF_CHIP constant to your call to
AllocMem:
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) A rule of thumb is to
double the current size and try again until it works.
Edwin Hoogerbeets
uunet!utai!utcsri!hcr!edwin
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: daveh@cbmvax.UUCP
Subject: (,MOT) 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!"
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: kjohn@richp1.UUCP
Subject: (,MOU) AmigaDOS MountList Tips
ATTENTION ALL HARD DISK USERS:
I do not know if this is common knowledge on Usenet (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!!!!!
[You might want to simulate a floppy disk on your hard drive
so that you can use the Amiga 1.3 DISKCOPY program which only
does the job when it believes that the source and destination
disks are identical. That is, the number of tracks, the number
of sectors per track and the number of heads].
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 nowhere 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
HF0: (Simulated Floppy)
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. Wrong!
If you apply the 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)
Yes, you would have just trashed what ever was on track 21 instead of
using track 100 as 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
[ Each mountlist entry seems to separately tell AmigaDOS the complete
physical configuration of the drive, but the calculations for starting
cylinder, track and number of sectors per surface are simply providing
a non-overlapping method of telling AmigaDOS which is calculated sector
to assign as the first sector within a logical partition. All of the
calculations come down to that.]
Some of you may look at this and say, "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
speed 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 calculated from of the current MountList entry.
KJohn
I can be reached at:
RealTime (prefered): 1(312)403-4762 (6pm to 10:30pm central time)
USmail: John Kjellman
14465 Middle Pine Creek Dr.
Orland Park, IL 60462
E-Mail: kjohn@richp1.UUCP
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.UUCP
Subject: (,REE) 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.
==========================================================================
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: cbmvax!lauren (Lauren Brown CATS)
Subject: (,TEC) Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
-------------
New documents:
Commodore-Amiga, Incorporated. Amiga Technical Reference Series.
Reading, Massachusets: Addison-Wesley Publishing Company, Inc.; 1989; 3
volumes; 28 cm; paperbound.
Amiga Hardware Reference Manual. approx 400 pages. "This maual
covers the A1000, A500, and A2000 release machines." ISBN
0-201-18157-6. $24.95. CBM Product Number 327272-04. Includes
glossary and index.
1. Introduction
2. Coprocessor Hardware
3. Playfield Hardware
4. Sprite Hardware
5. Audio Hardware
6. Blitter Hardware
7. System Contol Hardware
8. Interface Hardware
A. Register Summary--Alphabetical Order
B. Register Summary--Address Order
C. Custom Chip Pin Allocation List
D. System Memory Map
E. Interfaces
F. Complex Interface Adapters
G. AUTOCONFIG(tm)
H. Keyboard
I. External Disk Connector Interface Specifications
J. Hardware Example Include File
Amiga ROM Kernal Reference Manual: Libraries & Devices.
[STILL on order] approx $40
Amiga ROM Kernal Reference Manual: Includes & Autodocs. approx. 760
pages. "This manual corresponds to V1.3 system software release."
ISBN 0-201-18177-0. $32.95. Commodore Item Number 327271-06.
Introduction
Library Summaries
diskfont.doc exec.doc expansion.doc graphics.doc icon.doc
intuition.doc layers.doc mathffp.doc mathieeedoubbas.doc
mathieeedoubtrans.doc mathtrans.doc translator.doc
Devices Summaries
audio.doc clipboard.doc console.doc gameport.doc input.doc
keyboard.doc narrator.doc parallel.doc printer.doc
serial.doc timer.doc trackdisk.doc
Resource Summaries
cia.doc disk.doc misc.doc potgo.doc
C Include files - ".h" Files
Assembly Include Files - ".i" Files
Linker Libraries
[amiga.lib stuff]
Sample Device, Sample Library
Reference Charts
1.3_Base_Offset_Reference
Assembly_Prefix_Reference
C_Language_Cross-Reference
Chip_Register_Map
Structure Reference
IFF - Interchange File Format
EA IFF 85 - General IFF Format Specifications
Form Specifications from the Original EA Document
Additional IFF Documents
Third Party Registered FORM and Chunk Specifications
EA IFF Source Code
Additional IFF Examples
Function Index
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.UUCP
Subject: (,UNS) 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
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: cmcmanis@pepper.UUCP
Subject: (,REC) Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: papa@pollux.usc.edu.UUCP
Subject: (,CUS) Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: (,EXC) Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.UUCP
Subject: (,IFF) IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: koster@cory.Berkeley.EDU.UUCP
Subject: (,REQ) Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: bryce@cbmvax.UUCP
Subject: (,BUG) Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: peter@sugar.UUCP
Subject: (,STA) A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: page@Sun.COM (Bob Page)
Subject: (,BOO) What the Amiga does on reboot
u586182058ea@deneb.ucdavis.edu Frank Kuan wrote:
>What does the Amiga do when you reboot?
- Clear Chips (screen turns blue on custom chip failure)
- Disable DMA and Interrupts
- Clear the Screen
- Check the Hardware
- Pass or fail the Hardware to the Screen (dark grey if OK)
- Checksum the WCS (OS does not checksum the ROM)
- Pass or fail the WCS to the Screen (displays "Insert Kickstart" screen)
- System setup
- Check the for RAM at $C00000
- Move SYS_BASE to $C00000 if it exists
- RAM Test
- Pass or fail the RAM to the Screen (green if bad)
- Check the Software
- Pass or fail the Software to the Screen (light grey if OK)
- Set up the RAM
- Link the Libraries
- Find External RAM and link it to the list
- Set up Interrupts and DMA
- Start default Task
- Check for 68010, 68020, and 68881
- Check for an Exception (screen yellow if found and GURU handler not set up)
- System Reset
>Is it possible to change a vector somewhere and have the Amiga
>run your code instead of the reboot sequence?
Yes. This is one of those Amiga Secrets, most people don't discuss it
because (presumably) it encourages crackers to write viruses and other
nasty stuff.
..bob
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Subject: (,LIB) Lattice Library Question
>From article <690@dsacg2.UUCP>, by nor1675@dsacg2.UUCP (Michael Figg):
> I've been programming with Lattice 'C' off and on for about 2.5 years now,
> but continually get confused with what libraries need to be linked when.
Take a look at the Addendum.docs file on disk 5 of your compiler
package. Among other things it contains a description of all the files in
the LIB: directory.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: 12 :::::::::::::::::::Library Descriptions:::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
cback.o
Startup routine to detach process from CLI and run in background.
catchres.o
Startup routine to catch software exceptions in resident programs.
lcs.lib
Lattice C Library for use with 16-bit integers.
catch.o
Startup routine to catch software exceptions.
lcms.lib
Lattice Standard IEEE Math Library for use with 16-bit integers.
lcm881.lib
Lattice 68881 Coprocessor Math Library.
c.o
Standard Lattice Startup routine.
lcnb.lib
Lattice C Library for use with no base-relative data addressing.
catchresnr.o
Startup - Catch Exceptions, Resident, No Requesters on exception.
lcmffp.lib
Lattice Motorola Fast Floating Point Math Library.
lcmieee.lib
Lattice IEEE Math Library for use with Commodore Resident Library.
lcsr.lib
Lattice C Library for use with 16-bit integers and Registerized Parameters.
lcr.lib
Lattice C Library for use with Registerized Parameters.
lcmr.lib
Lattice IEEE Math Library for use with Registerized Parameters.
lc.lib
Lattice Standard C Library.
cres.o
Startup routine for Resident Programs.
lcm.lib
Lattice Standard IEEE Math Library.
lcsnb.lib
Lattice C Library for 16-bit integers and no base-relative
addressing.
ddebug.lib
Commodore debug library for use with Parallel Port.
debug.lib
Commodore debug library for use with Serial Port.
amiga.lib
Library of linkage routines to Amiga Resident Libraries.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: uunet!ardent.com!rap (Rob Peck)
Subject: (,AUD) audiotools
How do I play sounds on the Amiga?
I offer a disk of audiotools for the Amiga, for only $8.00. It
includes source and object code in both C and Modula that makes it
easier to add audio to your programs. It includes functions for
obtaining and releasing audio channels, playing notes, explicit
frequencies, sampled sounds, allows queueing of sounds to play, and
even includes an ability to synchronize sound and graphics by having
the audio.device itself tell you when a particular note begins to
play. The audiotools are a continuing project, based on an article I
originally wrote for Amiga World: July, 1987, but updated to add more
capabilities, and with the text of the article now explaining the
latest version of the tools. As of this writing, the audiotools are at
release 3.0, the same level as that released at the Washington DC
developers conference. I encourage submission of additional features
and functions for and from interested parties. Pseudo public
domain... that is, NO ROYALTIES, but I would hope that interested
parties would contact me directly so that I can continue to receive
suggestions for improvements and bug reports. Rob Peck, DATAPATH,
POBox 1828, Los Gatos, CA 95031
Rob Peck
*************************************************************************
From watdragon!watserv1!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!rutgers!cbmvax!peter Thu Feb 22 12:18:18 EST 1990
From: peter@cbmvax.commodore.com (Peter Cherna)
Subject: (,AGNUS) the Fatter Agnus
In article <6187@cps3xx.UUCP> hensley@frith.egr.msu.edu (John Hensley) writes:
>He said that without any fast RAM some programs, among them Deluxe Paint III,
>Dungeon Master, and a bunch of other graphics-intensive programs, wouldn't
>operate properly. This made absolutely no sense to me. Isn't the 512K on a
>stock 500 all chip RAM with the Fatter Agnus? Why would programs that run in
that chip RAM run less well with a meg of it?
I don't know whether the programs you mention indeed have this trouble,
but you can write software that has a bug (programmer misunderstanding, really)
that would cause it to fail on 1Meg Agnus machines with no expansion RAM
that would work on 1Meg machines with only 512K of chip. It will have
nothing to do with how "graphics-intensive" the program is - on that
point your dealer is mistaken. It may be that a couple of "graphics-intensive"
programs have this problem, but again, it is a programmer's mistake basically
unrelated to the category of program or its performance needs.
When you allocate memory, you can ask for CHIP memory, FAST memory,
or EITHER. Now, if you need chip, you should always ask for chip, but
if you don't care, you should ask for either. Make sense? Tell that
to people who ask EXPLICITLY for fast memory when they _mean_ either.
So the memory allocation will fail if you have no fast memory installed.
Now if a program required 1 Meg of memory total to run and made the mistake of
asking for fast memory, then it would fail on an all-chip machine, which
yours would be. It would work on a 1 Meg A500 or A2000 with an older
Agnus, but it wouldn't work at all on an 512K machine. I don't see
any reason that a program working on a 512K Amiga would fail on a 1 Meg chip
machine (of course, some "creative" programmers who break rules have
amazed us before).
To add further confusion, you have three basic kinds of memory in the system,
and their advantages:
Usable by Custom Chips? No Chip Contention?
chip yes no
fast no yes
C00000 no no
So while chip memory is good because it can be accessed by the chip set,
it can suffer during high DMA. You may find it strange that the C00000
memory (the 2nd 512K on a 1Meg A2000 or A500 with older Agnus) seems to
have both disadvantages. The old Agnus just doesn't have the addressing
range to use it, but we put it on the chip bus (where it suffers contention)
so that it would become chip memory with a Super-Agnus installed. In
the system, C00000 memory is classified as "fast" memory.
So the "fast" memory that a program got by asking could actually be no
better performing than chip, so clearly it never needed to ask for
fast.
Just to complete the tale, if you ask for "either" kind of memory, the
system will try to give you fast memory in preference to chip memory.
The system utility FastMemFirst we supply ensures that the order of
preference is expansion fast memory (true fast memory), C00000 memory,
and then chip memory (without it the system comes up with C00000 memory
at the highest priority). So for those with expansion RAM and C00000 RAM,
make sure you have FastMemFirst in your startup sequence - you WILL
notice the difference.
--
Peter Cherna, Software Engineer, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com
My opinions do not necessarily represent the opinions of my employer.
*************************************************************************w-edwinh@microsoft.UUCP (Edwin HOOGERBEETS) (05/02/90)
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.
This posting last changed: May 1, 1990
Changes this month:
Added: Amiga Programming Newsletter - Submissions/needs.... (,LET)
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed. Previously deleted topics are still
available from the editor via email.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./newuser.
To read any of the following topics, type 'g' for 'go to' and the 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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
,BOO What the Amiga does on reboot
page@sun.COM (Bob Page)
,LIB A description of the Lattice libraries
fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
,AUD How to get audiotools
uunet!ardent.com!rap (Rob Peck)
,AGNUS Questions and answers about the Fatter Agnus
peter@cbmvax.commodore.com (Peter Cherna)
,LET Amiga Programming Newsletter - Submissions/needs....
kamidon@dip.eecs.umich.edu (Keith Amidon)
Edwin
w-edwinh@microsoft or uunet!microsoft!w-edwinh
*************************************************************************
From uunet!Sun.COM!cmcmanis Fri Mar 2 15:59:47 EST 1990
From: cmcmanis@Sun.COM
Subject: (,NOV) 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 too 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. To make sure that
you get chip memory do add the MEMF_CHIP constant to your call to
AllocMem:
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) A rule of thumb is to
double the current size and try again until it works.
Edwin Hoogerbeets
uunet!utai!utcsri!hcr!edwin
*************************************************************************
From uunet!cbmvax!daveh Fri Mar 2 15:59:47 EST 1990
From: daveh@cbmvax.commodore.com
Subject: (,MOT) 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!"
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: kjohn@richp1.UUCP
Subject: (,MOU) AmigaDOS MountList Tips
ATTENTION ALL HARD DISK USERS:
I do not know if this is common knowledge on Usenet (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!!!!!
[You might want to simulate a floppy disk on your hard drive
so that you can use the Amiga 1.3 DISKCOPY program which only
does the job when it believes that the source and destination
disks are identical. That is, the number of tracks, the number
of sectors per track and the number of heads].
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 nowhere 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
HF0: (Simulated Floppy)
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. Wrong!
If you apply the 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)
Yes, you would have just trashed what ever was on track 21 instead of
using track 100 as 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
[ Each mountlist entry seems to separately tell AmigaDOS the complete
physical configuration of the drive, but the calculations for starting
cylinder, track and number of sectors per surface are simply providing
a non-overlapping method of telling AmigaDOS which is calculated sector
to assign as the first sector within a logical partition. All of the
calculations come down to that.]
Some of you may look at this and say, "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
speed 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 calculated from of the current MountList entry.
KJohn
I can be reached at:
RealTime (prefered): 1(312)403-4762 (6pm to 10:30pm central time)
USmail: John Kjellman
14465 Middle Pine Creek Dr.
Orland Park, IL 60462
E-Mail: kjohn@richp1.UUCP
*************************************************************************
From uunet!cbmvax!carolyn Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.commodore.com
Subject: (,REE) 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.commodore.com
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.
==========================================================================
*************************************************************************
From uunet!cbmvax!lauren Fri Mar 2 15:59:47 EST 1990
From: lauren@cbmvax.commodore.com (Lauren Brown CATS)
Subject: (,TEC) Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
-------------
New documents:
Commodore-Amiga, Incorporated. Amiga Technical Reference Series.
Reading, Massachusets: Addison-Wesley Publishing Company, Inc.; 1989; 3
volumes; 28 cm; paperbound.
Amiga Hardware Reference Manual. approx 400 pages. "This maual
covers the A1000, A500, and A2000 release machines." ISBN
0-201-18157-6. $24.95. CBM Product Number 327272-04. Includes
glossary and index.
1. Introduction
2. Coprocessor Hardware
3. Playfield Hardware
4. Sprite Hardware
5. Audio Hardware
6. Blitter Hardware
7. System Contol Hardware
8. Interface Hardware
A. Register Summary--Alphabetical Order
B. Register Summary--Address Order
C. Custom Chip Pin Allocation List
D. System Memory Map
E. Interfaces
F. Complex Interface Adapters
G. AUTOCONFIG(tm)
H. Keyboard
I. External Disk Connector Interface Specifications
J. Hardware Example Include File
Amiga ROM Kernal Reference Manual: Libraries & Devices.
[STILL on order] approx $40
Amiga ROM Kernal Reference Manual: Includes & Autodocs. approx. 760
pages. "This manual corresponds to V1.3 system software release."
ISBN 0-201-18177-0. $32.95. Commodore Item Number 327271-06.
Introduction
Library Summaries
diskfont.doc exec.doc expansion.doc graphics.doc icon.doc
intuition.doc layers.doc mathffp.doc mathieeedoubbas.doc
mathieeedoubtrans.doc mathtrans.doc translator.doc
Devices Summaries
audio.doc clipboard.doc console.doc gameport.doc input.doc
keyboard.doc narrator.doc parallel.doc printer.doc
serial.doc timer.doc trackdisk.doc
Resource Summaries
cia.doc disk.doc misc.doc potgo.doc
C Include files - ".h" Files
Assembly Include Files - ".i" Files
Linker Libraries
[amiga.lib stuff]
Sample Device, Sample Library
Reference Charts
1.3_Base_Offset_Reference
Assembly_Prefix_Reference
C_Language_Cross-Reference
Chip_Register_Map
Structure Reference
IFF - Interchange File Format
EA IFF 85 - General IFF Format Specifications
Form Specifications from the Original EA Document
Additional IFF Documents
Third Party Registered FORM and Chunk Specifications
EA IFF Source Code
Additional IFF Examples
Function Index
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
*************************************************************************
From uunet!cbmvax!carolyn Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.commodore.com
Subject: (,UNS) 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
*************************************************************************
From uunet!Sun.COM!cmcmanis Fri Mar 2 15:59:47 EST 1990
From: cmcmanis@Sun.COM
Subject: (,REC) Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: papa@pollux.usc.edu.UUCP
Subject: (,CUS) Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: (,EXC) Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
From uunet!cbmvax!carolyn Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.commodore.com
Subject: (,IFF) IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: koster@cory.Berkeley.EDU.UUCP
Subject: (,REQ) Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
From uunet!cbmvax!bryce Fri Mar 2 15:59:47 EST 1990
From: bryce@cbmvax.commodore.com
Subject: (,BUG) Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
From uunet!sugar!peter Fri Mar 2 15:59:47 EST 1990
From: peter@sugar.UUCP
Subject: (,STA) A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************
From uunet!Sun.COM!page Fri Mar 2 15:59:47 EST 1990
From: page@Sun.COM (Bob Page)
Subject: (,BOO) What the Amiga does on reboot
u586182058ea@deneb.ucdavis.edu Frank Kuan wrote:
>What does the Amiga do when you reboot?
- Clear Chips (screen turns blue on custom chip failure)
- Disable DMA and Interrupts
- Clear the Screen
- Check the Hardware
- Pass or fail the Hardware to the Screen (dark grey if OK)
- Checksum the WCS (OS does not checksum the ROM)
- Pass or fail the WCS to the Screen (displays "Insert Kickstart" screen)
- System setup
- Check the for RAM at $C00000
- Move SYS_BASE to $C00000 if it exists
- RAM Test
- Pass or fail the RAM to the Screen (green if bad)
- Check the Software
- Pass or fail the Software to the Screen (light grey if OK)
- Set up the RAM
- Link the Libraries
- Find External RAM and link it to the list
- Set up Interrupts and DMA
- Start default Task
- Check for 68010, 68020, and 68881
- Check for an Exception (screen yellow if found and GURU handler not set up)
- System Reset
>Is it possible to change a vector somewhere and have the Amiga
>run your code instead of the reboot sequence?
Yes. This is one of those Amiga Secrets, most people don't discuss it
because (presumably) it encourages crackers to write viruses and other
nasty stuff.
..bob
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Subject: (,LIB) Lattice Library Question
>From article <690@dsacg2.UUCP>, by nor1675@dsacg2.UUCP (Michael Figg):
> I've been programming with Lattice 'C' off and on for about 2.5 years now,
> but continually get confused with what libraries need to be linked when.
Take a look at the Addendum.docs file on disk 5 of your compiler
package. Among other things it contains a description of all the files in
the LIB: directory.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: 12 :::::::::::::::::::Library Descriptions:::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
cback.o
Startup routine to detach process from CLI and run in background.
catchres.o
Startup routine to catch software exceptions in resident programs.
lcs.lib
Lattice C Library for use with 16-bit integers.
catch.o
Startup routine to catch software exceptions.
lcms.lib
Lattice Standard IEEE Math Library for use with 16-bit integers.
lcm881.lib
Lattice 68881 Coprocessor Math Library.
c.o
Standard Lattice Startup routine.
lcnb.lib
Lattice C Library for use with no base-relative data addressing.
catchresnr.o
Startup - Catch Exceptions, Resident, No Requesters on exception.
lcmffp.lib
Lattice Motorola Fast Floating Point Math Library.
lcmieee.lib
Lattice IEEE Math Library for use with Commodore Resident Library.
lcsr.lib
Lattice C Library for use with 16-bit integers and Registerized Parameters.
lcr.lib
Lattice C Library for use with Registerized Parameters.
lcmr.lib
Lattice IEEE Math Library for use with Registerized Parameters.
lc.lib
Lattice Standard C Library.
cres.o
Startup routine for Resident Programs.
lcm.lib
Lattice Standard IEEE Math Library.
lcsnb.lib
Lattice C Library for 16-bit integers and no base-relative
addressing.
ddebug.lib
Commodore debug library for use with Parallel Port.
debug.lib
Commodore debug library for use with Serial Port.
amiga.lib
Library of linkage routines to Amiga Resident Libraries.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3
*************************************************************************
From uunet!ardent.com!rap Fri Mar 2 15:59:47 EST 1990
From: rap@ardent.com (Rob Peck)
Subject: (,AUD) audiotools
How do I play sounds on the Amiga?
I offer a disk of audiotools for the Amiga, for only $8.00. It
includes source and object code in both C and Modula that makes it
easier to add audio to your programs. It includes functions for
obtaining and releasing audio channels, playing notes, explicit
frequencies, sampled sounds, allows queueing of sounds to play, and
even includes an ability to synchronize sound and graphics by having
the audio.device itself tell you when a particular note begins to
play. The audiotools are a continuing project, based on an article I
originally wrote for Amiga World: July, 1987, but updated to add more
capabilities, and with the text of the article now explaining the
latest version of the tools. As of this writing, the audiotools are at
release 3.0, the same level as that released at the Washington DC
developers conference. I encourage submission of additional features
and functions for and from interested parties. Pseudo public
domain... that is, NO ROYALTIES, but I would hope that interested
parties would contact me directly so that I can continue to receive
suggestions for improvements and bug reports. Rob Peck, DATAPATH,
POBox 1828, Los Gatos, CA 95031
Rob Peck
*************************************************************************
From uunet!cbmvax!peter Thu Feb 22 12:18:18 EST 1990
From: peter@cbmvax.commodore.com (Peter Cherna)
Subject: (,AGNUS) the Fatter Agnus
In article <6187@cps3xx.UUCP> hensley@frith.egr.msu.edu (John Hensley) writes:
>He said that without any fast RAM some programs, among them Deluxe Paint III,
>Dungeon Master, and a bunch of other graphics-intensive programs, wouldn't
>operate properly. This made absolutely no sense to me. Isn't the 512K on a
>stock 500 all chip RAM with the Fatter Agnus? Why would programs that run in
that chip RAM run less well with a meg of it?
I don't know whether the programs you mention indeed have this trouble,
but you can write software that has a bug (programmer misunderstanding, really)
that would cause it to fail on 1Meg Agnus machines with no expansion RAM
that would work on 1Meg machines with only 512K of chip. It will have
nothing to do with how "graphics-intensive" the program is - on that
point your dealer is mistaken. It may be that a couple of "graphics-intensive"
programs have this problem, but again, it is a programmer's mistake basically
unrelated to the category of program or its performance needs.
When you allocate memory, you can ask for CHIP memory, FAST memory,
or EITHER. Now, if you need chip, you should always ask for chip, but
if you don't care, you should ask for either. Make sense? Tell that
to people who ask EXPLICITLY for fast memory when they _mean_ either.
So the memory allocation will fail if you have no fast memory installed.
Now if a program required 1 Meg of memory total to run and made the mistake of
asking for fast memory, then it would fail on an all-chip machine, which
yours would be. It would work on a 1 Meg A500 or A2000 with an older
Agnus, but it wouldn't work at all on an 512K machine. I don't see
any reason that a program working on a 512K Amiga would fail on a 1 Meg chip
machine (of course, some "creative" programmers who break rules have
amazed us before).
To add further confusion, you have three basic kinds of memory in the system,
and their advantages:
Usable by Custom Chips? No Chip Contention?
chip yes no
fast no yes
C00000 no no
So while chip memory is good because it can be accessed by the chip set,
it can suffer during high DMA. You may find it strange that the C00000
memory (the 2nd 512K on a 1Meg A2000 or A500 with older Agnus) seems to
have both disadvantages. The old Agnus just doesn't have the addressing
range to use it, but we put it on the chip bus (where it suffers contention)
so that it would become chip memory with a Super-Agnus installed. In
the system, C00000 memory is classified as "fast" memory.
So the "fast" memory that a program got by asking could actually be no
better performing than chip, so clearly it never needed to ask for
fast.
Just to complete the tale, if you ask for "either" kind of memory, the
system will try to give you fast memory in preference to chip memory.
The system utility FastMemFirst we supply ensures that the order of
preference is expansion fast memory (true fast memory), C00000 memory,
and then chip memory (without it the system comes up with C00000 memory
at the highest priority). So for those with expansion RAM and C00000 RAM,
make sure you have FastMemFirst in your startup sequence - you WILL
notice the difference.
--
Peter Cherna, Software Engineer, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com
My opinions do not necessarily represent the opinions of my employer.
*************************************************************************
From uunet!dip.eecs.umich.edu!kamidon Sat Apr 28 16:30:44 PDT 1990
From: kamidon@dip.eecs.umich.edu (Keith Amidon)
Subject: (,LET) Amiga Programming Newsletter - Submissions/needs....
The Amiga Progamming Newsletter is looking for a few good people to
write some columns for our readership. I would like to see the
following columns in this newsletter:
1 - Amiga Internals: This column would delve into the internals
of programming on the Amiga, discussing such topics as
message passing, safe task creation, etc. It would
hopefully start with a logical overview of the entire
Amiga programming system, and then start examining each
important sub-system in great detail, including well commented
source code to illustrate important points. It would be
nice if this could be posted fairly regularly.
2 - Tricks of the Trade: This column would compile a list of
bug fixes/workarounds etc. for the Amiga system software
and programming utilities. It could also keep a record
of the current version numbers of various widely used
programming tools. (Not to run on but..) It could also
keep a bibliography of currently available box on programming
the Amiga, with short descriptions of their good/bad points
etc.
Those are the two ideas I have had for columns so far. If you have a
topic you would like to write about on a regular basis that could be
a column, please mail at the address which will be given below, and we
can see how it will fit in. (Hint .... PLEASE mail me!!!)
Along with the columns, I would also like to post one time articles from
various authors. These articles could review a programming tool, explain
some complex bit of Amiga programming, or showcase new tools written by
the author to make programming easier. Actually, just about anything
having to do with programming the Amiga would be great!
Now, the submission guidelines.
1 - Please, submit all text as plain ASCII with 80 columns maximum.
While this may not be strictly neccessary, it will make my life
A LOT easier.
2 - Any source code submitted should be well commented and only
included if it is neccessary or relavent to the article. There
is no point in distributing usesless or unreadable code, since
no one will be able to get anything out of it.
3 - If source code is submitted, please included a uuencoded binary.
I require this because there is no way I can get access to all
of the programming tools that would allow me to examine the
final result of the code. If you are descibing a library etc.,
please include a demo.
4 - All source code must be either PD or freely-redistributable.
I will simply be redistributing the author's material, so it
will remain in his or her copyright. However, I prefer not to
distribute shareware code.
5 - Thats it!
If I feel that any material doesn't fit the above guidelines, I will
get in touch with the author so we can work the problems out. This
will be done in a nice manner, NOT IT'S not right so FIX IT :^)
Thanks for reading this post. I have been using a lot of network
bandwidth lately trying to get this thing off the ground. However,
things should calm down again soon.
Thanks, Keith Amidon
Woops.... I almost forgot, the mail address for submission of material
follows:
apn_sub@dip.eecs.umich.edu (Amiga Programming Newsletter_SUBmit)
-------------
>From: kamidon@dip.eecs.umich.edu (Keith Amidon)
Subject: Amiga Programming Newsletter, final post (for a while 8^)
This is the last post I will be making about the Amiga Programming Newsletter
for a while. However, there are a few things I wanted to clear up ASAP, and
because the mailing distribution list isn't quite in finished form yet, I
thought this would be the best way to reach everyone involved.
There are several questions which already seem to be very common,
and I would like to deal with these here rather than mailing people
individually. So:
1 - Yes, I will be archiving back issues of all articles going
through the mailing list. I have not decided how I will handle
distributing backissues yet, but I will inform everyone via
the mailing list when I know for sure.
2 - I would like this newsletter to reach as many people as possible.
For this reason I will be redistributing the material without
attaching any copyright etc. (except on my own stuff) Copyright
etc. will be left in the name of the person submitting the
article (HINT: if you submit one, add the copyright etc) I
will not distribute any material which does not allow distribution
outside the newsletter, which means that anyone who wishes to may
redistribute the newsletter. The only condition I impose is
that the redistribution must bne done on a NOT FOR PROFIT basis.
A lot of my work will be going into this project, I don't want
others making money off it.
3 - For submissions, I will accept anything, written in any langauge
as long as there is a binary so I can look at the result of the
code. (This is because I can't own all possible programming tools)
That about ties it up. I will be writing several standard reply messages
for subscriptions etc. as soon as I have time so that people will know they
have been added to the list and will get information similar to the above
when they subscribe. However, AGAIN I will most likely not produce anything
until May 3. If you asked for a subscription and haven't heard from me,
don't worry. After May 3 I will post to the list a message dealing with
many of these issues along with a simultaneous post to c.s.a so that people
will know they should be getting something. If you don't receive something
soon after the post in c.s.a, mail me with your subscription again.
By the way, for those who joined us late, the subscription address is:
apn_sub@dip.eecs.umich.edu (Amiga Programming Newsletter SUBscribe)
the address for submissions is:
apn_sub@dip.eecs.umich.edu (Amiga Programming Newsletter SUBmit)
Yes, they are really the same address 8^)
Thanks again, Keith Amidon -- editor, Amiga Programming Newsletter
kamidon@dip.eecs.umich.edu
*************************************************************************w-edwinh@microsoft.UUCP (Edwin HOOGERBEETS) (07/04/90)
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.
This posting last changed: June 1, 1990
Changes this month:
Updated: Amiga Programming Newsletter (,LET)
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed. Previously deleted topics are still
available from the editor via email.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./newuser.
To read any of the following topics, type 'g' for 'go to' and the 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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
,BOO What the Amiga does on reboot
page@sun.COM (Bob Page)
,LIB A description of the Lattice libraries
fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
,AUD How to get audiotools
uunet!ardent.com!rap (Rob Peck)
,AGNUS Questions and answers about the Fatter Agnus
peter@cbmvax.commodore.com (Peter Cherna)
,LET Amiga Programming Newsletter
kamidon@dip.eecs.umich.edu (Keith Amidon)
Edwin
w-edwinh@microsoft or uunet!microsoft!w-edwinh
*************************************************************************
From uunet!Sun.COM!cmcmanis Fri Mar 2 15:59:47 EST 1990
From: cmcmanis@Sun.COM
Subject: (,NOV) 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 too 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. To make sure that
you get chip memory do add the MEMF_CHIP constant to your call to
AllocMem:
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) A rule of thumb is to
double the current size and try again until it works.
Edwin Hoogerbeets
uunet!utai!utcsri!hcr!edwin
*************************************************************************
From uunet!cbmvax!daveh Fri Mar 2 15:59:47 EST 1990
From: daveh@cbmvax.commodore.com
Subject: (,MOT) 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!"
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: kjohn@richp1.UUCP
Subject: (,MOU) AmigaDOS MountList Tips
ATTENTION ALL HARD DISK USERS:
I do not know if this is common knowledge on Usenet (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!!!!!
[You might want to simulate a floppy disk on your hard drive
so that you can use the Amiga 1.3 DISKCOPY program which only
does the job when it believes that the source and destination
disks are identical. That is, the number of tracks, the number
of sectors per track and the number of heads].
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 nowhere 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
HF0: (Simulated Floppy)
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. Wrong!
If you apply the 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)
Yes, you would have just trashed what ever was on track 21 instead of
using track 100 as 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
[ Each mountlist entry seems to separately tell AmigaDOS the complete
physical configuration of the drive, but the calculations for starting
cylinder, track and number of sectors per surface are simply providing
a non-overlapping method of telling AmigaDOS which is calculated sector
to assign as the first sector within a logical partition. All of the
calculations come down to that.]
Some of you may look at this and say, "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
speed 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 calculated from of the current MountList entry.
KJohn
I can be reached at:
RealTime (prefered): 1(312)403-4762 (6pm to 10:30pm central time)
USmail: John Kjellman
14465 Middle Pine Creek Dr.
Orland Park, IL 60462
E-Mail: kjohn@richp1.UUCP
*************************************************************************
From uunet!cbmvax!carolyn Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.commodore.com
Subject: (,REE) 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.commodore.com
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.
==========================================================================
*************************************************************************
From uunet!cbmvax!lauren Fri Mar 2 15:59:47 EST 1990
From: lauren@cbmvax.commodore.com (Lauren Brown CATS)
Subject: (,TEC) Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
-------------
New documents:
Commodore-Amiga, Incorporated. Amiga Technical Reference Series.
Reading, Massachusets: Addison-Wesley Publishing Company, Inc.; 1989; 3
volumes; 28 cm; paperbound.
Amiga Hardware Reference Manual. approx 400 pages. "This maual
covers the A1000, A500, and A2000 release machines." ISBN
0-201-18157-6. $24.95. CBM Product Number 327272-04. Includes
glossary and index.
1. Introduction
2. Coprocessor Hardware
3. Playfield Hardware
4. Sprite Hardware
5. Audio Hardware
6. Blitter Hardware
7. System Contol Hardware
8. Interface Hardware
A. Register Summary--Alphabetical Order
B. Register Summary--Address Order
C. Custom Chip Pin Allocation List
D. System Memory Map
E. Interfaces
F. Complex Interface Adapters
G. AUTOCONFIG(tm)
H. Keyboard
I. External Disk Connector Interface Specifications
J. Hardware Example Include File
Amiga ROM Kernal Reference Manual: Libraries & Devices.
[STILL on order] approx $40
Amiga ROM Kernal Reference Manual: Includes & Autodocs. approx. 760
pages. "This manual corresponds to V1.3 system software release."
ISBN 0-201-18177-0. $32.95. Commodore Item Number 327271-06.
Introduction
Library Summaries
diskfont.doc exec.doc expansion.doc graphics.doc icon.doc
intuition.doc layers.doc mathffp.doc mathieeedoubbas.doc
mathieeedoubtrans.doc mathtrans.doc translator.doc
Devices Summaries
audio.doc clipboard.doc console.doc gameport.doc input.doc
keyboard.doc narrator.doc parallel.doc printer.doc
serial.doc timer.doc trackdisk.doc
Resource Summaries
cia.doc disk.doc misc.doc potgo.doc
C Include files - ".h" Files
Assembly Include Files - ".i" Files
Linker Libraries
[amiga.lib stuff]
Sample Device, Sample Library
Reference Charts
1.3_Base_Offset_Reference
Assembly_Prefix_Reference
C_Language_Cross-Reference
Chip_Register_Map
Structure Reference
IFF - Interchange File Format
EA IFF 85 - General IFF Format Specifications
Form Specifications from the Original EA Document
Additional IFF Documents
Third Party Registered FORM and Chunk Specifications
EA IFF Source Code
Additional IFF Examples
Function Index
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
*************************************************************************
From uunet!cbmvax!carolyn Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.commodore.com
Subject: (,UNS) 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
*************************************************************************
From uunet!Sun.COM!cmcmanis Fri Mar 2 15:59:47 EST 1990
From: cmcmanis@Sun.COM
Subject: (,REC) Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: papa@pollux.usc.edu.UUCP
Subject: (,CUS) Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: (,EXC) Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
From uunet!cbmvax!carolyn Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.commodore.com
Subject: (,IFF) IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: koster@cory.Berkeley.EDU.UUCP
Subject: (,REQ) Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
From uunet!cbmvax!bryce Fri Mar 2 15:59:47 EST 1990
From: bryce@cbmvax.commodore.com
Subject: (,BUG) Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
From uunet!sugar!peter Fri Mar 2 15:59:47 EST 1990
From: peter@sugar.UUCP
Subject: (,STA) A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************
From uunet!Sun.COM!page Fri Mar 2 15:59:47 EST 1990
From: page@Sun.COM (Bob Page)
Subject: (,BOO) What the Amiga does on reboot
u586182058ea@deneb.ucdavis.edu Frank Kuan wrote:
>What does the Amiga do when you reboot?
- Clear Chips (screen turns blue on custom chip failure)
- Disable DMA and Interrupts
- Clear the Screen
- Check the Hardware
- Pass or fail the Hardware to the Screen (dark grey if OK)
- Checksum the WCS (OS does not checksum the ROM)
- Pass or fail the WCS to the Screen (displays "Insert Kickstart" screen)
- System setup
- Check the for RAM at $C00000
- Move SYS_BASE to $C00000 if it exists
- RAM Test
- Pass or fail the RAM to the Screen (green if bad)
- Check the Software
- Pass or fail the Software to the Screen (light grey if OK)
- Set up the RAM
- Link the Libraries
- Find External RAM and link it to the list
- Set up Interrupts and DMA
- Start default Task
- Check for 68010, 68020, and 68881
- Check for an Exception (screen yellow if found and GURU handler not set up)
- System Reset
>Is it possible to change a vector somewhere and have the Amiga
>run your code instead of the reboot sequence?
Yes. This is one of those Amiga Secrets, most people don't discuss it
because (presumably) it encourages crackers to write viruses and other
nasty stuff.
..bob
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Subject: (,LIB) Lattice Library Question
>From article <690@dsacg2.UUCP>, by nor1675@dsacg2.UUCP (Michael Figg):
> I've been programming with Lattice 'C' off and on for about 2.5 years now,
> but continually get confused with what libraries need to be linked when.
Take a look at the Addendum.docs file on disk 5 of your compiler
package. Among other things it contains a description of all the files in
the LIB: directory.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: 12 :::::::::::::::::::Library Descriptions:::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
cback.o
Startup routine to detach process from CLI and run in background.
catchres.o
Startup routine to catch software exceptions in resident programs.
lcs.lib
Lattice C Library for use with 16-bit integers.
catch.o
Startup routine to catch software exceptions.
lcms.lib
Lattice Standard IEEE Math Library for use with 16-bit integers.
lcm881.lib
Lattice 68881 Coprocessor Math Library.
c.o
Standard Lattice Startup routine.
lcnb.lib
Lattice C Library for use with no base-relative data addressing.
catchresnr.o
Startup - Catch Exceptions, Resident, No Requesters on exception.
lcmffp.lib
Lattice Motorola Fast Floating Point Math Library.
lcmieee.lib
Lattice IEEE Math Library for use with Commodore Resident Library.
lcsr.lib
Lattice C Library for use with 16-bit integers and Registerized Parameters.
lcr.lib
Lattice C Library for use with Registerized Parameters.
lcmr.lib
Lattice IEEE Math Library for use with Registerized Parameters.
lc.lib
Lattice Standard C Library.
cres.o
Startup routine for Resident Programs.
lcm.lib
Lattice Standard IEEE Math Library.
lcsnb.lib
Lattice C Library for 16-bit integers and no base-relative
addressing.
ddebug.lib
Commodore debug library for use with Parallel Port.
debug.lib
Commodore debug library for use with Serial Port.
amiga.lib
Library of linkage routines to Amiga Resident Libraries.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3
*************************************************************************
From uunet!ardent.com!rap Fri Mar 2 15:59:47 EST 1990
From: rap@ardent.com (Rob Peck)
Subject: (,AUD) audiotools
How do I play sounds on the Amiga?
I offer a disk of audiotools for the Amiga, for only $8.00. It
includes source and object code in both C and Modula that makes it
easier to add audio to your programs. It includes functions for
obtaining and releasing audio channels, playing notes, explicit
frequencies, sampled sounds, allows queueing of sounds to play, and
even includes an ability to synchronize sound and graphics by having
the audio.device itself tell you when a particular note begins to
play. The audiotools are a continuing project, based on an article I
originally wrote for Amiga World: July, 1987, but updated to add more
capabilities, and with the text of the article now explaining the
latest version of the tools. As of this writing, the audiotools are at
release 3.0, the same level as that released at the Washington DC
developers conference. I encourage submission of additional features
and functions for and from interested parties. Pseudo public
domain... that is, NO ROYALTIES, but I would hope that interested
parties would contact me directly so that I can continue to receive
suggestions for improvements and bug reports. Rob Peck, DATAPATH,
POBox 1828, Los Gatos, CA 95031
Rob Peck
*************************************************************************
From uunet!cbmvax!peter Thu Feb 22 12:18:18 EST 1990
From: peter@cbmvax.commodore.com (Peter Cherna)
Subject: (,AGNUS) the Fatter Agnus
In article <6187@cps3xx.UUCP> hensley@frith.egr.msu.edu (John Hensley) writes:
>He said that without any fast RAM some programs, among them Deluxe Paint III,
>Dungeon Master, and a bunch of other graphics-intensive programs, wouldn't
>operate properly. This made absolutely no sense to me. Isn't the 512K on a
>stock 500 all chip RAM with the Fatter Agnus? Why would programs that run in
that chip RAM run less well with a meg of it?
I don't know whether the programs you mention indeed have this trouble,
but you can write software that has a bug (programmer misunderstanding, really)
that would cause it to fail on 1Meg Agnus machines with no expansion RAM
that would work on 1Meg machines with only 512K of chip. It will have
nothing to do with how "graphics-intensive" the program is - on that
point your dealer is mistaken. It may be that a couple of "graphics-intensive"
programs have this problem, but again, it is a programmer's mistake basically
unrelated to the category of program or its performance needs.
When you allocate memory, you can ask for CHIP memory, FAST memory,
or EITHER. Now, if you need chip, you should always ask for chip, but
if you don't care, you should ask for either. Make sense? Tell that
to people who ask EXPLICITLY for fast memory when they _mean_ either.
So the memory allocation will fail if you have no fast memory installed.
Now if a program required 1 Meg of memory total to run and made the mistake of
asking for fast memory, then it would fail on an all-chip machine, which
yours would be. It would work on a 1 Meg A500 or A2000 with an older
Agnus, but it wouldn't work at all on an 512K machine. I don't see
any reason that a program working on a 512K Amiga would fail on a 1 Meg chip
machine (of course, some "creative" programmers who break rules have
amazed us before).
To add further confusion, you have three basic kinds of memory in the system,
and their advantages:
Usable by Custom Chips? No Chip Contention?
chip yes no
fast no yes
C00000 no no
So while chip memory is good because it can be accessed by the chip set,
it can suffer during high DMA. You may find it strange that the C00000
memory (the 2nd 512K on a 1Meg A2000 or A500 with older Agnus) seems to
have both disadvantages. The old Agnus just doesn't have the addressing
range to use it, but we put it on the chip bus (where it suffers contention)
so that it would become chip memory with a Super-Agnus installed. In
the system, C00000 memory is classified as "fast" memory.
So the "fast" memory that a program got by asking could actually be no
better performing than chip, so clearly it never needed to ask for
fast.
Just to complete the tale, if you ask for "either" kind of memory, the
system will try to give you fast memory in preference to chip memory.
The system utility FastMemFirst we supply ensures that the order of
preference is expansion fast memory (true fast memory), C00000 memory,
and then chip memory (without it the system comes up with C00000 memory
at the highest priority). So for those with expansion RAM and C00000 RAM,
make sure you have FastMemFirst in your startup sequence - you WILL
notice the difference.
--
Peter Cherna, Software Engineer, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com
My opinions do not necessarily represent the opinions of my employer.
*************************************************************************
From uunet!dip.eecs.umich.edu!kamidon Fri May 4 08:15:59 1990
From: Keith Amidon <uunet!dip.eecs.umich.edu!kamidon>
Subject: (,LET) Amiga Programming Newsletter
The purpose of this article is to inform Amiga Programming Newsletter
(APN) subscribers of the current goals and methods of APN, and to solicit
their involvement though a questionaire at the end. This article, updated
as necessary, will be distributed to all new subscribers.
********* Amiga Programming Newsletters -- Goals and Methods *********
PURPOSE: The purpose of APN is to deliver the maximum amount of Amiga
programming information into the hands of its subscribers
in a minimum amount of time. A secondary goal is to increase
its readership to as large a base as possible.
DISTRIBUTION: In keeping with the goals stated above, APN distribution will
be very informal. The core distribution will be a mailing
list of subscribers managed by Keith Amidon (myself). A
subscription to this core distribution can be obtained by
sending a message to:
apn_sub@dip.eecs.umich.edu
Because these messages are processed automatically by a set of
scripts, it is extremely important that the following criteria
be met:
1 - The subject line must include the word "Subscribe"
2 - The body of the message must include a line, starting on
the first column with the following format:
VALID_MAIL_PATH=<a valid mail path to your account>
Please note that there are NO SPACES!
Any message to apn_sub@dip.eecs.umich.edu which does not contain
the keyword Subscribe or one of the other keywords given below,
will be automatically deleted before I ever see it, so make sure
you include it! If the keyword Subscribe is seen, a script will
be invoked that will extract the VALID_MAIL_PATH line from the
message and attempt to send this article to the new subscriber.
If the VALID_MAIL_PATH cannot be extracted, the message will be
saved to a file for later manual update by the mailing list
maintainer. However, this will not endear you to him, so try
to get it right ;^)
SECONDARY
DISTRIBUTION: Anyone who recieves APN is allowed to redistribute it on a not
for profit basis. Copyright of material appearing in APN will
stay with the author of the material, rather than become APN's,
since APN isn't really buying its material, but rather just
providing a convient distribution path for the author. The
only money you can charge for APN would be the cost of disk
or other distribution medium.
DISTRIBUTION
TIMING: Articles for APN will be sent out on an "as they arrive basis."
There may be several regular columns if I can get people
interested in writing them, but otherwise distribution may be
rather erratic.
SUBSCRIBER
INTERACTON: There are several ways in which subscribers to APN can interact
with the distribution personel and authors. The very first
thing you can do is return the questionaire at the end of this
article. This, along with letters for me can be sent to the
address:
apn_sub@dip.eecs.umich.edu
The subject line of your post should include one of the
following keywords:
Questionaire -- For the questionaire obviously.
Letter -- This keyword indicates a letter which you
would like published in APN. Usually this
would be used to correct some problem with
an article.
Suggestion -- This keyword would indicate a message
involving a suggestion for some aspect of
APN, which I would deal with and get a
response back to you ASAP.
Submission -- This is what APN is about; The sharing of
the expertise of its readers. If you have
a project you are working on and would like
to write up as an article for APN, please
send a message indicating your ideas and
include this keyword. I again get back to
you ASAP, including the as yet vaporware
Author's Toolkit, which will include tools
to make articles reasonably formated etc.
NOTE: ALL mail to apn_sub@dip.eecs.umich.edu which does not
contain one of the above listed keywords in
*************************************************************************w-edwinh@microsoft.UUCP (Edwin HOOGERBEETS) (08/08/90)
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.
This posting last changed: Aug 6, 1990
Changes this month:
Updated: Questions and Anwswers about starting to program the Amiga in
C (,NOV)
It is recommended that you save this article for future reference.
Please refer to this article first before posting to the net. This
will help keep the comp.sys.amiga* groups uncluttered with topics that
have already been discussed. Previously deleted topics are still
available from the editor via email.
*
* There is an analogous posting in comp.sys.amiga.
*
To save this posting when you are using
rn or vn: s newuser<return> to save in the file News/newuser.
notes: snewuser<return> to save this article in the file ./newuser.
To read any of the following topics, type 'g' for 'go to' and the 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 Documents from Commodore
cbmvax!lauren (Lauren Brown CATS)
,UNS Unsupported Programming Practices
carolyn@cbmvax.UUCP
daveh@cbmvax.UUCP
,REC Resource reclamation, why can't it be done?
cmcmanis@pepper.UUCP
,CUS Can System Request windows appear on custom screens?
papa@pollux.usc.edu.UUCP
,EXC Info on exceptions
dillon@CORY.BERKELEY.EDU.UUCP
,IFF IFF File Format
carolyn@cbmvax.UUCP
,REQ Intuition requestors: how to stop them?
koster@cory.Berkeley.EDU.UUCP
,BUG How to report bugs to Commodore (info on 1.3 crash to
KickStart bug)
bryce@cbmvax.UUCP
,STA How to find the stack size in a program
peter@sugar.UUCP
,BOO What the Amiga does on reboot
page@sun.COM (Bob Page)
,LIB A description of the Lattice libraries
fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
,AUD How to get audiotools
uunet!ardent.com!rap (Rob Peck)
,AGNUS Questions and answers about the Fatter Agnus
peter@cbmvax.commodore.com (Peter Cherna)
,LET Amiga Programming Newsletter
kamidon@dip.eecs.umich.edu (Keith Amidon)
Edwin
w-edwinh@microsoft or uunet!microsoft!w-edwinh
*************************************************************************
From uunet!Sun.COM!cmcmanis Fri Mar 2 15:59:47 EST 1990
From: cmcmanis@Sun.COM
Subject: (,NOV) 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 too 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 -- see the header files for the correct spelling.
(hard, eh?)
# 2 : Both Manx and Lattice now use use 32 bits as a default size for
ints. However, the Manx C compiler also allows 16 bit ints under a
certain flag. When interfacing with system routines, you must make sure
the appropriate ints are actually 32 bits longs, or fireworks will
happen.
In older versions of the Manx compiler (pre 5.0), 16 bits was the default,
and you had to make sure the appropriate ints were longs, or you had to
compile with the +L option, which made 32 bits the size of an int.
# 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 on older systems, or the first 1 Meg with the
enhanced chip set (this memory is the slow or chip memory). Therefore,
anything that these chips use must be in the first 512K (1 Meg) of
memory. To make sure that you get chip memory do add the MEMF_CHIP
constant to your call to AllocMem:
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) A rule of thumb is to
double the current size and try again until it works.
Edwin Hoogerbeets
uunet!microsoft!w-edwinh or w-edwinh@microsoft.uucp
*************************************************************************
From uunet!cbmvax!daveh Fri Mar 2 15:59:47 EST 1990
From: daveh@cbmvax.commodore.com
Subject: (,MOT) 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!"
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: kjohn@richp1.UUCP
Subject: (,MOU) AmigaDOS MountList Tips
ATTENTION ALL HARD DISK USERS:
I do not know if this is common knowledge on Usenet (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!!!!!
[You might want to simulate a floppy disk on your hard drive
so that you can use the Amiga 1.3 DISKCOPY program which only
does the job when it believes that the source and destination
disks are identical. That is, the number of tracks, the number
of sectors per track and the number of heads].
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 nowhere 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
HF0: (Simulated Floppy)
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. Wrong!
If you apply the 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)
Yes, you would have just trashed what ever was on track 21 instead of
using track 100 as 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
[ Each mountlist entry seems to separately tell AmigaDOS the complete
physical configuration of the drive, but the calculations for starting
cylinder, track and number of sectors per surface are simply providing
a non-overlapping method of telling AmigaDOS which is calculated sector
to assign as the first sector within a logical partition. All of the
calculations come down to that.]
Some of you may look at this and say, "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
speed 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 calculated from of the current MountList entry.
KJohn
I can be reached at:
RealTime (prefered): 1(312)403-4762 (6pm to 10:30pm central time)
USmail: John Kjellman
14465 Middle Pine Creek Dr.
Orland Park, IL 60462
E-Mail: kjohn@richp1.UUCP
*************************************************************************
From uunet!cbmvax!carolyn Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.commodore.com
Subject: (,REE) 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.commodore.com
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.
==========================================================================
*************************************************************************
From uunet!cbmvax!lauren Fri Mar 2 15:59:47 EST 1990
From: lauren@cbmvax.commodore.com (Lauren Brown CATS)
Subject: (,TEC) Tech Ref. Docs
This list will be growing, as we make the 1.3 Native Developer Update
available, along with some other stuff we're planning.
Commodore-Amiga Technical Information
=====================================
Amiga 1000 Schematics and Expansion Specifications
Full A1000 schematics, timing diagrams, PAL equations, and
documentation of auto-config process
IFF Manual and Disk
Full IFF documentation and source listings, including new IFF
form chunk ANIM. IFF disk includes source code, object files,
executable programs and documentation.
Fall 1986 Developers Conference Notes
Contains the diagrams, outlines and additional notes pertaining
to each conference speakers' topic. Some additional information
has been included (e.g., 8520 specifications).
AmigaMail
Bimonthly technical newsletter produced by CATS. Articles range from
programming standards through programming for compatibility to
advance technical information on new products (hardware and software).
Cost EACH for any of the above: U.S. $20 (in Canada $22.50, $25 elsewhere)
A500/A2000 Technical Reference Manual
275 page reference manual that describes the technical
features of the A500 and A2000, and the features that differ
from the A1000. Included are: System block diagrams, Amiga
Expansion, Designing hardware for the Amiga Expansion Arhictecture,
Driver documentation, Software for Amiga Expansion, BIOS entry
points, Clock/Calendar Registers, plus much more. Also included
are schematics.
Cost each: U.S. $40 (in Canada $42.50, $45 elsewhere)
TO ORDER
========
Send check or money order payable in U.S. funds to:
CATS-Orders
1200 Wilson Drive
West Chester, PA 19382
Commodore Amiga Technical Support Programs
==========================================
Certified Developer Support Program: Cost is $75 for the first year.
Provides technical support through AmigaMail (our bimonthly newsletter) and
through the amiga.dev conferences on BIX. Provides marketing information
through AmigaMail-Markets our quarterly marketing newsletter. Hardware
discounts are available to members of this program. Internal documentation and
technical updates are made available when possible. Ths program is for third
party developers who have not yet brought a product to market. Also, many user
groups and education institutions find this program useful.
Commercial Developer Support Program: Cost is $500 for the first year.
This program includes all of the benefits listed above, along with
eligibility for direct phone support from Commodore Amiga Technical Support
(CATS) and membership in the closed developer conferences on BIX. When possible,
and when a need is shown, beta versions of hardware and software are made
available to Commercial developers. This program is designed for individuals
and companies who have already sucessfully launched products into the
commercial market. Because of the increased effort and resources required
to provide this more intensive form of support, membership is limited,
and subject to approval by Commodore.
To receive an application for either support program, write to:
CATS-Inquiries
1200 Wilson Drive
West Chester, PA 19382
-------------
New documents:
Commodore-Amiga, Incorporated. Amiga Technical Reference Series.
Reading, Massachusets: Addison-Wesley Publishing Company, Inc.; 1989; 3
volumes; 28 cm; paperbound.
Amiga Hardware Reference Manual. approx 400 pages. "This maual
covers the A1000, A500, and A2000 release machines." ISBN
0-201-18157-6. $24.95. CBM Product Number 327272-04. Includes
glossary and index.
1. Introduction
2. Coprocessor Hardware
3. Playfield Hardware
4. Sprite Hardware
5. Audio Hardware
6. Blitter Hardware
7. System Contol Hardware
8. Interface Hardware
A. Register Summary--Alphabetical Order
B. Register Summary--Address Order
C. Custom Chip Pin Allocation List
D. System Memory Map
E. Interfaces
F. Complex Interface Adapters
G. AUTOCONFIG(tm)
H. Keyboard
I. External Disk Connector Interface Specifications
J. Hardware Example Include File
Amiga ROM Kernal Reference Manual: Libraries & Devices.
[STILL on order] approx $40
Amiga ROM Kernal Reference Manual: Includes & Autodocs. approx. 760
pages. "This manual corresponds to V1.3 system software release."
ISBN 0-201-18177-0. $32.95. Commodore Item Number 327271-06.
Introduction
Library Summaries
diskfont.doc exec.doc expansion.doc graphics.doc icon.doc
intuition.doc layers.doc mathffp.doc mathieeedoubbas.doc
mathieeedoubtrans.doc mathtrans.doc translator.doc
Devices Summaries
audio.doc clipboard.doc console.doc gameport.doc input.doc
keyboard.doc narrator.doc parallel.doc printer.doc
serial.doc timer.doc trackdisk.doc
Resource Summaries
cia.doc disk.doc misc.doc potgo.doc
C Include files - ".h" Files
Assembly Include Files - ".i" Files
Linker Libraries
[amiga.lib stuff]
Sample Device, Sample Library
Reference Charts
1.3_Base_Offset_Reference
Assembly_Prefix_Reference
C_Language_Cross-Reference
Chip_Register_Map
Structure Reference
IFF - Interchange File Format
EA IFF 85 - General IFF Format Specifications
Form Specifications from the Original EA Document
Additional IFF Documents
Third Party Registered FORM and Chunk Specifications
EA IFF Source Code
Additional IFF Examples
Function Index
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
*************************************************************************
From uunet!cbmvax!carolyn Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.commodore.com
Subject: (,UNS) 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
*************************************************************************
From uunet!Sun.COM!cmcmanis Fri Mar 2 15:59:47 EST 1990
From: cmcmanis@Sun.COM
Subject: (,REC) Re: resource reclamation
In article <YX2ERcy00Uh0IEQFxo@andrew.cmu.edu> (Miles Bader) writes:
> How come simple resource reclamation isn't done? It seems like it
> would be pretty simple to hang a list of allocated resources off a
> task...
> -Miles
Because it isn't. The original DOS specified for the Amiga included
resource reclamation, however when time got tight and Commodore had
to go with MetaCompCo's modified version of TriPOS, there wasn't time
to put it in. If you look at some of the structures you will notice
that there entries for Tasks such as tc_MemEntry which were for this
kind of stuff.
That is not to say that it isn't possible. The ARP project (AmigaDOS
Replacement Project) has created a library which allows you to track
resources and free them on exit. The ARP stuff in on a Fish disk #???
and available thru the amiga archives.
The question Miles didn't ask but always follows is :
How come I can't kill a hung process with ^C or something? And when
the program breaks why do I have to reboot the machine?
The reason is that the Amiga does not have memory protection between
tasks. And when a program goes astray, you do not know what sort of
damage it may have caused to internal memory structures. It can damage
the memory free list, trackdisk buffers, the stack of other programs,
and a host of other "sensitive" areas. Consequently, if you continue
to run the machine after a program has died, you run the much greater
risk of destroying completely unrelated data. For most people this
is unacceptable and that is why you have to reboot. For those people
who like to gamble, there is a commercial program called GOMF which
attempts to recover from these situations. It does keep the machine
running, however if another program you are running crashes, you should
be aware that it is much more likely that the originally crashed program
probably is responsible, not a bug in the code that just ran.
--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.
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: papa@pollux.usc.edu.UUCP
Subject: (,CUS) Can System Request windows appear on custom screens?
>How can I redirect System Request windows to a screen other than the
>Workbench screen? In particular, I'm interested in the ones that say
>"Please insert volume ... in any drive".
>From the bag of tricks of Bryce Nesbitt:
struct Process *mproc;
struct Window *window;
APTR temp;
...
mproc = (struct Process *) FindTask(0L);
temp = mproc->pr_WindowPtr;
mproc->WindowPtr = (APTR) window; /* any window open on custom screen */
at the end:
...
mproc->pr_WindowPtr = temp; /* retore BEFORE CloseWindow */
CloseWindow(window);
Enjoy.
-- Marco papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: dillon@CORY.BERKELEY.EDU.UUCP
Subject: (,EXC) Need info on exceptions
Time to go into a brief description of the three types of interrupts
that exist on the Amiga:
(1) Task Exceptions (via SetExcept() and standard signals). This is a
task-level interrupt and only interrupts the task it is attached to.
Other tasks still run... the interrupt only interrupts the one task.
That is, any number of tasks may be handling exceptions all simultaniously.
This is analogous to UNIX signals with one major exception.... system
calls can get interrupted in the middle (i.e. library calls). Although
all run-time libraries are reentrant between tasks, this is not always
so within a given task. For instance, you cannot interrupt a DOS Write()
with an exception and then do a Write() from within the exception!!
Another for instance: you CAN call AllocMem().
So you have to be very careful as to when to allow an exception and when not
to. Forbid() effectively disables exceptions (but also task switching).
Also, there is a bug in the exception handler in that if an exception
occured during a Forbid() it does NOT execute when you Permit()... i.e.
you also have to do a SetExcept(0,0) to force EXEC to check for active
exceptions after you Permit().
The 'simple' description of an exception is this: First, a task gets
signalled and if the exception bit for that signal bit is set, the
EXCEPTION-ENABLE BIT AND THE SIGNAL BIT IS CLEARED and the task then enters
its exception handler. D0 contains a mask of the exception that occured
(more than one bit may be set if more than one exception occured
at once). The exception handler thus must be reentrant for different
exception bits.
After the handler runs, it must return a bitmask in D0 of those exceptions
that occured. EXEC automatically ENABLES the exceptions specified by
the bitmask. However, it doesn't check to see if they re-occured at this
time... Thus, there is a window of vulnerability here. Usually, I
reenable the exceptions manually with a SetExcept() call from the handler
and return 0 in D0. Unlike other types of interrupts, EXEC saves and
restores ALL of our registers (except the stack pointer) for us. But,
you cannot make assumptions as to the contents of the registers (except
for D0 and A1(=tc_ExceptData). Specifically, there is no guarentee
A4 will contain the small-code-model data segment base so you must reload
it if you intend to use that model inside the handler.
(2) Software Interrupts. Software interrupts are HIGHER priority than tasks
but LOWER priority than interrupts. Essentially, these are pseudo
hardware interrupts but without the timing restrictions in real
interrupts.... you can do things that you would not want to do in normal
interrupts because they would otherwise take too long.
BUT! A software interrupt is not a task, and you still may not use
memory allocation/free functions within one (same restrictions as for
hardware interrupts apply with the exception that you can take a longer
time in the soft int). For example, instead of calling ReplyMsg() from
an HARD interrupt handler you might want to Cause() a softint instead.
This allows the HARD int to end (and other HARD ints to occur).
A software interrupt uses the same structure as a hardware interrupt.
(3) Hardware Interrupts. Real honest to goodness hardware interrupts.
Implemented by SetIntVector() and AddIntServer() and the like. These
are real hardware interrupts and the service routine should take as
little time as possible in them... I mean as *little* time as possible.
Make your code tight. Calling something like ReplyMsg() or PutMsg(),
while it works, usually takes too much time for an interrupt handler
to spare. Cause() a softint for things that take too much time so
other interrupts can go. I don't know how much time Signal() takes.
There are two flavors. (1) Direct hardware interrupts (SetIntVector()),
and (2) Chained hardware interrupts. In many cases there are also
resources (misc.resource, for instance) to arbitrate usage of some of
the interrupt vectors.
-Matt
*************************************************************************
From uunet!cbmvax!carolyn Fri Mar 2 15:59:47 EST 1990
From: carolyn@cbmvax.commodore.com
Subject: (,IFF) IFF File Format
>What exactly is the format of an Amiga IFF file?
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
==========================================================================
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: koster@cory.Berkeley.EDU.UUCP
Subject: (,REQ) Intuition requestors: how to stop them?
>How do I make Intuition requestors NOT appear?
Just place a $ffffffff (or -1) in the pr_windowptr field of your process, and
intuition will mind its own business, returning errors when it would return
a message. Note that you will want to restore this after your program exits,
as leaving it at -1 will mean the CLI will not get intuition requestors
anymore. Normally pr_windowptr is a 0.
koster@cory.berkeley.edu
David Ashley
*************************************************************************
From uunet!cbmvax!bryce Fri Mar 2 15:59:47 EST 1990
From: bryce@cbmvax.commodore.com
Subject: (,BUG) Crashing all the way to Kickstart (*the solution*)
In several articles <> several.net.posters wrote:
> [Since installing V1.3 I have noticed something strange. If the
> machine ever crashes, it sometimes goes back to the Kickstart hand
> instead of the Workbench hand.]
Thank you all for noting and reporting this bug. I have located the
cause; a code mistake causes the Kickstart protected memory to be
left open open for writing during some types of system Alert. This
problem will be addressed in the next version of "SetPatch" (no
date or distribution details are available at this time).
Please note that some types of bug reports can be sent directly to
Commodore. Before reporting, please verify the accuracy of your statements.
Try removing any special programs or hacks you may be running (booting
from your unmodified master Workbench disk is a good way to guarantee
this).
Submitted reports must include a TELEPHONE number. Reports must
be CLEAR, COMPLETE and CONCISE. Based on your bug report alone,
we must be able to repeat the bug. Bugs that we can repeat
in-house GET FIXED.
-Bryce Nesbitt, Commodore-Amiga, Inc.
Here is a sample bug report form:
BUG REPORT
----------
Date:
Name:
Phone:
Company:
EMail:
### Bug Location (Hardware, Documentation, Software, Other):
### Your Configuration (Model, number and type of disks, memory,
### add-on equipment):
### Other software running or resident at the time of the bug (should be
### "none"):
### Revisions (Kickstart/Workbench revision numbers, etc.):
### Brief Bug Description:
### Bug Generation Procedure (remember that someone else will be trying to
repeat this bug based on your description):
### Related bugs:
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Lawyers: America's untapped export market.
*************************************************************************
From uunet!sugar!peter Fri Mar 2 15:59:47 EST 1990
From: peter@sugar.UUCP
Subject: (,STA) A little help please...
This is the code I use to find the stack size for launch...
---------[from launch.shar]---------
struct Process *FindTask();
...
struct Process *me;
struct CommandLineInterface *cli;
long stack;
...
if(stack == 0) {
me = FindTask(0);
if(me->pr_CLI) {
cli = (struct CommandLineInterface *)(me->pr_CLI<<2);
stack = cli->cli_DefaultStack<<2; /* DefaultStack is in Longwords */
} else
stack = me->pr_StackSize;
}
--
Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net 'U`
*************************************************************************
From uunet!Sun.COM!page Fri Mar 2 15:59:47 EST 1990
From: page@Sun.COM (Bob Page)
Subject: (,BOO) What the Amiga does on reboot
u586182058ea@deneb.ucdavis.edu Frank Kuan wrote:
>What does the Amiga do when you reboot?
- Clear Chips (screen turns blue on custom chip failure)
- Disable DMA and Interrupts
- Clear the Screen
- Check the Hardware
- Pass or fail the Hardware to the Screen (dark grey if OK)
- Checksum the WCS (OS does not checksum the ROM)
- Pass or fail the WCS to the Screen (displays "Insert Kickstart" screen)
- System setup
- Check the for RAM at $C00000
- Move SYS_BASE to $C00000 if it exists
- RAM Test
- Pass or fail the RAM to the Screen (green if bad)
- Check the Software
- Pass or fail the Software to the Screen (light grey if OK)
- Set up the RAM
- Link the Libraries
- Find External RAM and link it to the list
- Set up Interrupts and DMA
- Start default Task
- Check for 68010, 68020, and 68881
- Check for an Exception (screen yellow if found and GURU handler not set up)
- System Reset
>Is it possible to change a vector somewhere and have the Amiga
>run your code instead of the reboot sequence?
Yes. This is one of those Amiga Secrets, most people don't discuss it
because (presumably) it encourages crackers to write viruses and other
nasty stuff.
..bob
*************************************************************************
From uunet!watmath!rose!ehoogerbeets Fri Mar 2 15:59:47 EST 1990
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Subject: (,LIB) Lattice Library Question
>From article <690@dsacg2.UUCP>, by nor1675@dsacg2.UUCP (Michael Figg):
> I've been programming with Lattice 'C' off and on for about 2.5 years now,
> but continually get confused with what libraries need to be linked when.
Take a look at the Addendum.docs file on disk 5 of your compiler
package. Among other things it contains a description of all the files in
the LIB: directory.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: 12 :::::::::::::::::::Library Descriptions:::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
cback.o
Startup routine to detach process from CLI and run in background.
catchres.o
Startup routine to catch software exceptions in resident programs.
lcs.lib
Lattice C Library for use with 16-bit integers.
catch.o
Startup routine to catch software exceptions.
lcms.lib
Lattice Standard IEEE Math Library for use with 16-bit integers.
lcm881.lib
Lattice 68881 Coprocessor Math Library.
c.o
Standard Lattice Startup routine.
lcnb.lib
Lattice C Library for use with no base-relative data addressing.
catchresnr.o
Startup - Catch Exceptions, Resident, No Requesters on exception.
lcmffp.lib
Lattice Motorola Fast Floating Point Math Library.
lcmieee.lib
Lattice IEEE Math Library for use with Commodore Resident Library.
lcsr.lib
Lattice C Library for use with 16-bit integers and Registerized Parameters.
lcr.lib
Lattice C Library for use with Registerized Parameters.
lcmr.lib
Lattice IEEE Math Library for use with Registerized Parameters.
lc.lib
Lattice Standard C Library.
cres.o
Startup routine for Resident Programs.
lcm.lib
Lattice Standard IEEE Math Library.
lcsnb.lib
Lattice C Library for 16-bit integers and no base-relative
addressing.
ddebug.lib
Commodore debug library for use with Parallel Port.
debug.lib
Commodore debug library for use with Serial Port.
amiga.lib
Library of linkage routines to Amiga Resident Libraries.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3
*************************************************************************
From uunet!ardent.com!rap Fri Mar 2 15:59:47 EST 1990
From: rap@ardent.com (Rob Peck)
Subject: (,AUD) audiotools
How do I play sounds on the Amiga?
I offer a disk of audiotools for the Amiga, for only $8.00. It
includes source and object code in both C and Modula that makes it
easier to add audio to your programs. It includes functions for
obtaining and releasing audio channels, playing notes, explicit
frequencies, sampled sounds, allows queueing of sounds to play, and
even includes an ability to synchronize sound and graphics by having
the audio.device itself tell you when a particular note begins to
play. The audiotools are a continuing project, based on an article I
originally wrote for Amiga World: July, 1987, but updated to add more
capabilities, and with the text of the article now explaining the
latest version of the tools. As of this writing, the audiotools are at
release 3.0, the same level as that released at the Washington DC
developers conference. I encourage submission of additional features
and functions for and from interested parties. Pseudo public
domain... that is, NO ROYALTIES, but I would hope that interested
parties would contact me directly so that I can continue to receive
suggestions for improvements and bug reports. Rob Peck, DATAPATH,
POBox 1828, Los Gatos, CA 95031
Rob Peck
*************************************************************************
From uunet!cbmvax!peter Thu Feb 22 12:18:18 EST 1990
From: peter@cbmvax.commodore.com (Peter Cherna)
Subject: (,AGNUS) the Fatter Agnus
In article <6187@cps3xx.UUCP> hensley@frith.egr.msu.edu (John Hensley) writes:
>He said that without any fast RAM some programs, among them Deluxe Paint III,
>Dungeon Master, and a bunch of other graphics-intensive programs, wouldn't
>operate properly. This made absolutely no sense to me. Isn't the 512K on a
>stock 500 all chip RAM with the Fatter Agnus? Why would programs that run in
that chip RAM run less well with a meg of it?
I don't know whether the programs you mention indeed have this trouble,
but you can write software that has a bug (programmer misunderstanding, really)
that would cause it to fail on 1Meg Agnus machines with no expansion RAM
that would work on 1Meg machines with only 512K of chip. It will have
nothing to do with how "graphics-intensive" the program is - on that
point your dealer is mistaken. It may be that a couple of "graphics-intensive"
programs have this problem, but again, it is a programmer's mistake basically
unrelated to the category of program or its performance needs.
When you allocate memory, you can ask for CHIP memory, FAST memory,
or EITHER. Now, if you need chip, you should always ask for chip, but
if you don't care, you should ask for either. Make sense? Tell that
to people who ask EXPLICITLY for fast memory when they _mean_ either.
So the memory allocation will fail if you have no fast memory installed.
Now if a program required 1 Meg of memory total to run and made the mistake of
asking for fast memory, then it would fail on an all-chip machine, which
yours would be. It would work on a 1 Meg A500 or A2000 with an older
Agnus, but it wouldn't work at all on an 512K machine. I don't see
any reason that a program working on a 512K Amiga would fail on a 1 Meg chip
machine (of course, some "creative" programmers who break rules have
amazed us before).
To add further confusion, you have three basic kinds of memory in the system,
and their advantages:
Usable by Custom Chips? No Chip Contention?
chip yes no
fast no yes
C00000 no no
So while chip memory is good because it can be accessed by the chip set,
it can suffer during high DMA. You may find it strange that the C00000
memory (the 2nd 512K on a 1Meg A2000 or A500 with older Agnus) seems to
have both disadvantages. The old Agnus just doesn't have the addressing
range to use it, but we put it on the chip bus (where it suffers contention)
so that it would become chip memory with a Super-Agnus installed. In
the system, C00000 memory is classified as "fast" memory.
So the "fast" memory that a program got by asking could actually be no
better performing than chip, so clearly it never needed to ask for
fast.
Just to complete the tale, if you ask for "either" kind of memory, the
system will try to give you fast memory in preference to chip memory.
The system utility FastMemFirst we supply ensures that the order of
preference is expansion fast memory (true fast memory), C00000 memory,
and then chip memory (without it the system comes up with C00000 memory
at the highest priority). So for those with expansion RAM and C00000 RAM,
make sure you have FastMemFirst in your startup sequence - you WILL
notice the difference.
--
Peter Cherna, Software Engineer, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com
My opinions do not necessarily represent the opinions of my employer.
*************************************************************************
From uunet!dip.eecs.umich.edu!kamidon Fri May 4 08:15:59 1990
From: Keith Amidon <uunet!dip.eecs.umich.edu!kamidon>
Subject: (,LET) Amiga Programming Newsletter
The purpose of this article is to inform Amiga Programming Newsletter
(APN) subscribers of the current goals and methods of APN, and to solicit
their involvement though a questionaire at the end. This article, updated
as necessary, will be distributed to all new subscribers.
********* Amiga Programming Newsletters -- Goals and Methods *********
PURPOSE: The purpose of APN is to deliver the maximum amount of Amiga
programming information into the hands of its subscribers
in a minimum amount of time. A secondary goal is to increase
its readership to as large a base as possible.
DISTRIBUTION: In keeping with the goals stated above, APN distribution will
be very informal. The core distribution will be a mailing
list of subscribers managed by Keith Amidon (myself). A
subscription to this core distribution can be obtained by
sending a message to:
apn_sub@dip.eecs.umich.edu
Because these messages are processed automatically by a set of
scripts, it is extremely important that the following criteria
be met:
1 - The subject line must include the word "Subscribe"
2 - The body of the message must include a line, starting on
the first column with the following format:
VALID_MAIL_PATH=<a valid mail path to your account>
Please note that there are NO SPACES!
Any message to apn_sub@dip.eecs.umich.edu which does not contain
the keyword Subscribe or one of the other keywords given below,
will be automatically deleted before I ever see it, so make sure
you include it! If the keyword Subscribe is seen, a script will
be invoked that will extract the VALID_MAIL_PATH line from the
message and attempt to send this article to the new subscriber.
If the VALID_MAIL_PATH cannot be extracted, the message will be
saved to a file for later manual update by the mailing list
maintainer. However, this will not endear you to him, so try
to get it right ;^)
SECONDARY
DISTRIBUTION: Anyone who recieves APN is allowed to redistribute it on a not
for profit basis. Copyright of material appearing in APN will
stay with the author of the material, rather than become APN's,
since APN isn't really buying its material, but rather just
providing a convient distribution path for the author. The
only money you can charge for APN would be the cost of disk
or other distribution medium.
DISTRIBUTION
TIMING: Articles for APN will be sent out on an "as they arrive basis."
There may be several regular columns if I can get people
interested in writing them, but otherwise distribution may be
rather erratic.
SUBSCRIBER
INTERACTON: There are several ways in which subscribers to APN can interact
with the distribution personel and authors. The very first
thing you can do is return the questionaire at the end of this
article. This, along with letters for me can be sent to the
address:
apn_sub@dip.eecs.umich.edu
The subject line of your post should include one of the
following keywords:
Questionaire -- For the questionaire obviously.
Letter -- This keyword indicates a letter which you
would like published in APN. Usually this
would be used to correct some problem with
an article.
Suggestion -- This keyword would indicate a message
involving a suggestion for some aspect of
APN, which I would deal with and get a
response back to you ASAP.
Submission -- This is what APN is about; The sharing of
the expertise of its readers. If you have
a project you are working on and would like
to write up as an article for APN, please
send a message indicating your ideas and
include this keyword. I again get back to
you ASAP, including the as yet vaporware
Author's Toolkit, which will include tools
to make articles reasonably formated etc.
NOTE: ALL mail to apn_sub@dip.eecs.umich.edu which does not
contain one of the above listed keywords in
*************************************************************************