Path: utzoo!utgpu!attcan!lsuc!ncrcan!hcr!edwin From: edwin@hcr.UUCP (Edwin Hoogerbeets) Newsgroups: comp.sys.amiga.tech Subject: Introduction to comp.sys.amiga.tech Summary: monthly info posting Message-ID: <5286@hcr.UUCP> Date: 4 Mar 89 01:50:18 GMT Reply-To: edwin@hcrvax.UUCP (Edwin Hoogerbeets) Organization: HCR Corporation, Toronto Lines: 918 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 to save in the file News/newuser. notes: snewuser 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 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 (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 *************************************************************************