wakres01@pa.usl.edu (1712 Stelly John B) (05/28/90)
In article <265377fd-662.2comp.sys.amiga.tech-1@tronsbox.UUCP> dfrancis@tronsbox.UUCP (Dennis Francis Heffernan) writes: > I haven't found any good ones yet, either. I'm new to this too >and the best info I've found has been in Abacus' AMIGA MACHINE LANGUAGE >(which at one point seems to advocate ignoring the rules and programming >the sound chips directly) and Jim Butterfield's articles in Trans-Ami I have the Abacus book, and don't find it to be particularly useful... I didn't appreciate the fact that most of the code in the book requires you to modify it (if you don't have assemPro, and I bought CAPE 68K), and there are no instructions for modifying the code for other assemblers, alothough they do mention the K-SEKA assembler briefly. At any rate, "68000 Assembly Language" by Donald Krantz,and James Stanley is an excellent reference for 68000 assembly, as far as amiga specific, books, none come to mind, in fact, although I already knew LOTS of assembly when I got my amiga, I've taken to learning the ins and outs of the OS in C to avoid figuring it out in assembly, there are really *NO* good references to interfacing your assembly programs with the Amiga's OS that I know of, which is sad because its keeping me from developing faster applications ( I don't have the time or the will power to keep crashing the machine until something works !) John B Stelly III wakres01@pa.usl.edu
jesup@cbmvax.commodore.com (Randell Jesup) (05/29/90)
In article <9074@rouge.usl.edu> wakres01@pa.usl.edu (1712 Stelly John B) writes: >In article <265377fd-662.2comp.sys.amiga.tech-1@tronsbox.UUCP> dfrancis@tronsbox.UUCP (Dennis Francis Heffernan) writes: >> I haven't found any good ones yet, either. I'm new to this too >>and the best info I've found has been in Abacus' AMIGA MACHINE LANGUAGE >>(which at one point seems to advocate ignoring the rules and programming >>the sound chips directly) and Jim Butterfield's articles in Trans-Ami > >I have the Abacus book, and don't find it to be particularly useful... >I didn't appreciate the fact that most of the code in the book requires >you to modify it (if you don't have assemPro, and I bought CAPE 68K), and >there are no instructions for modifying the code for other assemblers, >alothough they do mention the K-SEKA assembler briefly. As a personal opinion, I dislike most of the Abacus Amiga books. They tend to encourage poor programming practices (like not using symbolic constants, not using standard include files, making direct rom references, making MAJOR assumptions about how system tasks work (assuming that clearing a bit in some system task's structure will stop it from running), etc, etc.) Note that is a personal opinion. >to avoid figuring it out in assembly, there are really *NO* good references >to interfacing your assembly programs with the Amiga's OS that I know of, >which is sad because its keeping me from developing faster applications ( I >don't have the time or the will power to keep crashing the machine until >something works !) Just get a good book on general amiga programming. That (and the autodocs in the "Includes and Autodocs" RKM) will do you pretty well. The Autodocs define all the interfaces to the system routines. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
mt87692@tut.fi (Mikko Tsokkinen) (05/29/90)
Yo! The very best assembler books for amiga in my opinion are orginal Motorola processor books :-) They are the only books I have ever seen with right clock cycles for example. But if you don't know much about amiga assembly programming buy (or lend, take a look) for example Devpac2 and check out what information it gives you before buying any other books. BTW without Harware Reference Manual you will have big trouble with blitter, copper and bitplanes. If you want to make utilities (I find it boring but it's great that some people makes 'em :-) you almost certainly have to buy RKM's and in most cases DOS manual (DOS Manual BTW has some info on assemlers (ASM& ALINK)) too. Sounds lot of buying and it is! MITT -- Mikko "Assembler rules OK!" Tsokkinen Internet mt87692@tut.fi : UUCP tut!mt87692 : Bitnet mt87692@fintut
vilkas@ultima.cs.uts.oz (Iron Wolf) (05/30/90)
jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <9074@rouge.usl.edu> wakres01@pa.usl.edu (1712 Stelly John B) writes: > As a personal opinion, I dislike most of the Abacus Amiga books. >They tend to encourage poor programming practices (like not using symbolic >constants, not using standard include files, making direct rom references, >making MAJOR assumptions about how system tasks work (assuming that clearing >a bit in some system task's structure will stop it from running), etc, etc.) >Note that is a personal opinion. > Just get a good book on general amiga programming. That (and the >autodocs in the "Includes and Autodocs" RKM) will do you pretty well. The >Autodocs define all the interfaces to the system routines. >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup >Common phrase heard at Amiga Devcon '89: "It's in there!" Thing to understand about the abacus books, they aren't intended for the application programmer. They are for the programmer who wants to know the guts of the machine and how to get the very best possible performance. An example if this is the Amiga Systems Programmer's Guide. This book is fabulous if you want to learn how to program the amiga at a low level. That is at a level which makes the most of the speed of the machine. If for instance, you were working on a commercial game, you would want the fastest routines and such with which to work. In this case...out goes the OS, program the hardware! (not a good practice for application programming) If you just keep in mind what the book you are looking at is aimed at, then you will make sure you get the right book to teach you the right thing. I am not trying to disagree with you. you are right in saying that the Abacus books teach bad practices (unless you are writing games or other speed intensive programs) And I would also suggest the RKM's with another good introductory book with which to learn how to program. The RKM's also contain a section explaining what is considered good programming and what isn't. See Ya Iron Wolf
jesup@cbmvax.commodore.com (Randell Jesup) (05/30/90)
In article <17861@ultima.cs.uts.oz> vilkas@ultima.cs.uts.oz (Iron Wolf) writes: >Thing to understand about the abacus books, they aren't intended for the >application programmer. They are for the programmer who wants to know the guts >of the machine and how to get the very best possible performance. An example >if this is the Amiga Systems Programmer's Guide. This book is fabulous if you >want to learn how to program the amiga at a low level. That is at a level which >makes the most of the speed of the machine. >If for instance, you were working on a commercial game, you would want the >fastest routines and such with which to work. In this case...out goes the OS, >program the hardware! (not a good practice for application programming) Argh. When will people learn that games _are_ applications? Plus, the techniques used lead to programs that break if the roms are changed, or the machine has a different configuration, or a different processor, not work with hard drives, etc, etc. It's these sort of practices that contribute to some people dismissing the amiga as "just a game machine". >I am not trying to disagree with you. you are right in saying that the >Abacus books teach bad practices (unless you are writing games or other speed >intensive programs) And I would also suggest the RKM's with another good >introductory book with which to learn how to program. The RKM's also >contain a section explaining what is considered good programming and what isn't. Even speed-intensive programs can be relatively nice to the system - for example, re-enable multitasking while paused, for example. However, you're wrong that the RKM's are good for "laerning how to program". They are good (and IMHO necessary) for learning how to program an Amiga (for anything). they are not programming tutorials, though - they assume you know how to program (and to a certain extent that you can read C). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
bjornk@bula.se (Bjorn Knutsson) (05/30/90)
In article <MT87692.90May29181133@kaarne.tut.fi> mt87692@tut.fi (Mikko Tsokkinen) writes: [...] > BTW without Harware Reference Manual you will have big trouble with blitter, >copper and bitplanes. If you want to make utilities (I find it boring but it's >great that some people makes 'em :-) you almost certainly have to buy RKM's >and in most cases DOS manual (DOS Manual BTW has some info on assemlers (ASM& >ALINK)) too. Sounds lot of buying and it is! Regardless of what you do, you should have the RKM's. Just because you're not making "boring utilities" doesn't mean you should disregard the guidelines given for programming the Amiga. If more game programmers followed the guidelines I'd be buying more games. I just can't justify paying a lot of money for a program that treats my Amiga as a souped up C64. I didn't buy this machine for the (back then) fancy graphics and sound. I bought it because it had a multitasking operating system. I have never been interested in graphics as such. High resolution is, for me, just a way of stuffing more data on one screen. I don't care about colors. My default preferences are a black background and three shades of gray. >-- >Mikko "Assembler rules OK!" Tsokkinen >Internet mt87692@tut.fi : UUCP tut!mt87692 : Bitnet mt87692@fintut --- Bjorn Knutsson / USENET: bjornk@bula.se or sunic!sics!bula!bjornk Stangholmsbacken 44 / Phone : +46-8-710 7223 S-127 40 SKARHOLMEN / "Oh dear, I think you'll find reality's on the S W E D E N / blink again." -- Marvin The Paranoid Android
blatter@ifi.unizh.ch (Martin Blatter) (06/01/90)
In article <11891@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: > > As a personal opinion, I dislike most of the Abacus Amiga books. >They tend to encourage poor programming practices (like not using symbolic >constants, not using standard include files, making direct rom references, >making MAJOR assumptions about how system tasks work (assuming that clearing >a bit in some system task's structure will stop it from running), etc, etc.) >Note that is a personal opinion. > I agree. This seems to be the reason why a lot of German programs crash on different configurations. (Abacus books are originally published in German by Data Becker) > > Just get a good book on general amiga programming. That (and the >autodocs in the "Includes and Autodocs" RKM) will do you pretty well. The >Autodocs define all the interfaces to the system routines. > How about a German translation of "libraries & devices"? It will keep a lot of German programmers from those poor programming practices, because they'll have an alternative to Data Becker's "books". > >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. --Martin ------------------------------------------------------------------------- /// Martin A. Blatter /// University of Zurich, department of Computer Science /// Switzerland (Europe) \\\/// E-Mail: blatter@ifi.unizh.ch \XX/ ---------------------------- "A day without sunshine is like night" "There's a light where the darkness ends" (Taupin) -------------------------------------------------------------------------
farren@well.sf.ca.us (Mike Farren) (06/05/90)
vilkas@ultima.cs.uts.oz (Iron Wolf) writes: >If for instance, you were working on a commercial game, you would want the >fastest routines and such with which to work. In this case...out goes the OS, >program the hardware! (not a good practice for application programming) Wrong! In stays the OS, program the hardware. It isn't hard - why do you people have such a hard time comprehending this? YOU CAN PROGRAM THE HARDWARE IN AN OS-FRIENDLY WAY. Really. You don't need to kill the OS. You don't need to kill the multitasking (usually). You don't need to take over anything, and you damned well don't need to write directly to hardware locations which probably will not exist five years from now, or will do different things. Besides, I've seen a lot of games programmers who claimed to need "every cycle the machine has to offer", and every one who made such a claim was simply a less-than-competent programmer, disguising his own inability to be truly creative by blaming it on the OS. I haven't seen one single game for the Amiga yet which I could not replicate, given time, in an OS-friendly way. Not one. And almost every time I've actually had the chance to see some of the "lightning fast" code that people have actually produced, there have been eleventy-seven different ways of improving their speed by a factor of four or more, simply by analyzing the code and eliminating deadwood. And I've been doing this professionally (games, that is) since 1978, so I suggest that perhaps I know what I'm talking about :-) For me, I'll take the word (the work, actually) of someone like Mark Riley, who managed to cram all of Sonix into less than 75K, complete with OS interface and all, over the word of some whizbang kid programmer who has been using assembler for a whole year now :-) You say you can't do it? I say you don't even have a clue as to whether you can or you can't. Further, I say you can damn well do it - if you think you can't, work a little harder at it, learn a little more. You'll be amazed at what you'll be able to do that you never thought you could. -- Mike Farren farren@well.sf.ca.us
mcmahan@netcom.UUCP (Dave Mc Mahan) (06/06/90)
In a previous article, farren@well.sf.ca.us (Mike Farren) writes: >vilkas@ultima.cs.uts.oz (Iron Wolf) writes: >>If for instance, you were working on a commercial game, you would want the >>fastest routines and such with which to work. In this case...out goes the OS, >>program the hardware! (not a good practice for application programming) > >Wrong! In stays the OS, program the hardware. It isn't hard - why do >you people have such a hard time comprehending this? YOU CAN PROGRAM >THE HARDWARE IN AN OS-FRIENDLY WAY. Really. There are mechanisms for this, and in general I have found it to be true. But.. >You don't need to kill the OS. You don't need to kill the multitasking >(usually). You don't need to take over anything, and you damned well don't >need to write directly to hardware locations which probably will not >exist five years from now, or will do different things. ..the program I have written for the amiga does have a problem with AmigaDos in that the Dos inhibits interrupts for up to 250 uSeconds every 'once in a while'. This screws with my data, as I use interrupts to detect events, and the events are VERY sensitive to even that much time delay. The problem is minor, but it IS noticable if you look. It does show up in the image being created. The interrupt is from an external data source, and comes in via the parallel port. I have spoken via phone with Bob 'Kodiak' Burns in Los Gatos (an original Amiga Design team member and can be classified as One-who- should-know-what-he-is-talking-about) and he said that the only way to get the problem to go away is to start shutting down various portions of AmigaDos. Throwing out AmigaDos is something I REALLY don't want to do, so I have decided to live with the slight (but noticable) problem. I could make the external hardware supplying the signal more complicated, but the idea was to keep it ultra-simple so anyone with a little experience could build it. >Besides, I've seen a lot of games programmers who claimed to need >"every cycle the machine has to offer", and every one who made such a >claim was simply a less-than-competent programmer, disguising his own >inability to be truly creative by blaming it on the OS. I haven't seen >one single game for the Amiga yet which I could not replicate, given >time, in an OS-friendly way. Not one. And almost every time I've >actually had the chance to see some of the "lightning fast" code that >people have actually produced, there have been eleventy-seven different >ways of improving their speed by a factor of four or more, simply by >analyzing the code and eliminating deadwood. And I've been doing this >professionally (games, that is) since 1978, so I suggest that perhaps I >know what I'm talking about :-) Well, if you can figure out how to get around my little dilema without adding anything to the cost or complexity of the external hardware, I'm ALL ears. >Mike Farren farren@well.sf.ca.us -dave