Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ritcv.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxb!mhuxn!mhuxm!mhuxj!houxm!whuxlm!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!panda!talcott!harvard!seismo!rochester!ritcv!sah9577 From: sah9577@ritcv.UUCP (Scott Hossler) Newsgroups: net.micro.atari Subject: RE: Action! Brain damage Message-ID: <1522@ritcv.UUCP> Date: Thu, 7-Feb-85 04:54:12 EST Article-I.D.: ritcv.1522 Posted: Thu Feb 7 04:54:12 1985 Date-Received: Sun, 10-Feb-85 04:36:44 EST Distribution: net Organization: Rochester Institute of Technology, Rochester, NY Lines: 112 > 3. Let's whine about Action; I love the fact that it is in ROM, that it > compiles fast, and *is* fast, but why can't you have pointers in records? Sure, it's easy to whine about a product, but do you really think that it will really help. We could TALK about Action!, and any of it's short commings and benefits, and then maybe get something useful out of it. Granted, Action! is not a full implementation of Pascal, C or Ada, but neither is it BASIC. I don't want to argue about about BASIC, it has it's uses on the Atari, but we all know it's disadvantages. One of them being a complete lack of pointers. Having pinters available makes programming some tasks so much easier. That, with the ability to bind variables to a physical location, and bit-wise logical operators give the programmer great control over their machine without all the details that a complete assembly language program would require. As an example, here is a procedure that I wrote to overcome a feature of the Sound procedure in the library that came with the early versions. ;************************************** ;* PROC: sound * ;* PURPOSE: Loads the sound registers * ;* with desired values for channel, * ;* frequency, distortion and volume * ;* as compatible with the BASIC * ;* sound function. * ;* CALLED BY: any PROC or FUNC * ;* CALLS: nothing * ;************************************** PROC sound(BYTE chan, freq, dist, vol) DEFINE AUDIOBASE = $D200 ; Beginning of sound register table BYTE AUDCTL = $D208, ; Audio control option byte SKCTL = $D20F ; Serial control byte BYTE POINTER audio ; An index into the sound table AUDCTL=0 ; Set no options SKTL=3 ; ditto vol = vol & $F ;Strip off volume bits dist = dist RSH 1 ; Divide by 2 to adjust for 3 bit value dist = dist LSH 5 ; Align to proper bit locations chan = chan & $3 ; Strip off channel info audio = AUDIOBASE + 2*chan ; Align to proper channel in table ; of sound control bytes. audio^ = freq ; Store an 8 bit value audio==+1 ; Point to next control byte audio^ = dist + vol ; Store concatenated bits into byte RETURN I wrote this a year ago December in about twenty minutes, including the time needed to read through "MAPPING THE ATARI" to figure out where the sound channel bytes were located, how they were used .... Now, try doing this in BASIC, sure it could be done, but I wouldn't want to. Assembly, sure possible here too, but this is certainly clearer to read and understand, and was much easier for me to write. What also made it so easy to do was: 1) Bind variables to memory locations. No POKEs here, ( POKEing in Action! IS Brain Damaged ) I used the Atari's hardware registers as any other variable would have been. 2) Bit-wise operators. The sound registers store the three parameters into two bytes, so the two have to be isolated and then combined. Is there really any other way you would want to do this? 3) Pointers. This made getting into the table a simple offset problem. But in fact this may not have been needed, I probably would have been able to declare a byte array to reside there and then used the array index for access. I have not tried this here, but I like the pointer it makes sense. So I think the language is very useful for a variety of tasks. Sure, the manual SUCKS!, Clint admits this but he didn't write it so he has to live with it too. It is misleading and in certain instances WRONG. Action! is not a complete language, full of everything you would want, but it has enough to get by. If you play with it awhile you start to learn it's peculiarities and can make adjustments to them. MY big gripe is the cartridge itself. It is a piece of ****. I have had my cartridge a little over a year and the tin-foil that OSS tries to pass for contacts on the board are a joke. Mine are already worn out so that when I boot the system the cartridge is NOT RECOGNIZED. I end up in DOS-XL and when I try to go to it I get some sort of "NO CARTRIDGE" error message. This little trick is really irritating when the cartridge "DISAPPEARS" while I am using it. No amount of cleaning helps and this does not happen with any other cartridge. What really sets me off about this is that I really have not used it that much. In fact I didn't touch it at all during September - November. I could not have had it in and out of the machine more than 100 times if that. I do not think that it's life should have been entirely consumed already. I imagine this is a common problem but I do not know for sure. This just started 5 weeks ago and I have not tried to contact OSS about it yet. Scott Hossler rochester!ritcv!sah9577