mroddy@enmasse.UUCP (Mark Roddy) (02/05/85)
[squelch] > o Discussions of programs and languages (e.g. the brain-damaged 'records' > in Action. > 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? > I hate using CARDs. And why are all variables static? Just try writing > recursive programs! (I know you can use arrays, but I want to be > difficult) >-{ Really the problem is that for fast code Action doesn't use a stack frame- on a 6502 you only get 256 bytes of stack so if you want truly recursive procedures you have to use the hardware stack to hold pointers to a software stack. C65 does this, but as we all know, that language is truly brain damaged, and SLOOOOOOWWWW. Not only won't Action! let you have pointers in records, but I ran into the following bug: ;* excuse syntax errors, I can never switch from c to action too well CARD ARRAY dur(4) BYTE count init_dur(); FOR i=0 to 3 DO dur(count) == -1; if (dur(count) = 0) then do_something(); fi; OD This code was supposed to decrement card values in the card array dur, except that the compiler got all confused... refused to byte reverse values in dur before decrementing. It didn't matter what I used to point into the array.... same results. I fixed it by calling a function to perform the decrement, i.e. decr(dur,count)!!!!! WORSE YET- this was entirely context sensative!!!!! Similar code worked fine in different situations. Add this to the inability of the compiler to operate on cardinal values greater than 0x7fff, and you have a piece of software that should never be used by anyone. What really bugs me is that OSS has no intention of fixing any of this sh*t. And if they do... you can bet that it won't be the free upgrade that it should be.
parker@rochester.UUCP (Clint Parker) (02/06/85)
> [squelch] > > > o Discussions of programs and languages (e.g. the brain-damaged 'records' > > in Action. > > 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? > > I hate using CARDs. And why are all variables static? Just try writing > > recursive programs! (I know you can use arrays, but I want to be > > difficult) >-{ > > Really the problem is that for fast code Action doesn't use > a stack frame- on a 6502 you only get 256 bytes of stack so > if you want truly recursive procedures you have to use the > hardware stack to hold pointers to a software stack. C65 > does this, but as we all know, that language is truly brain > damaged, and SLOOOOOOWWWW. The real problem is that the 6502 doesn't really support a stack. ACTION! doesn't support recursion for just this reason. Come on now, how often do you really write recursive routines? How many of them need to be? Not too many I'll bet. I think most people would rather have the speed advantage. If you don't, used Deap Blue C or C/65 (which are missing several other features). > Not only won't Action! let you have pointers in records, but > I ran into the following bug: True, ACTION! on the Atari doesn't support pointers in records, but there were some features that had to be left out to fit it in the 16K cartridge. > ;* excuse syntax errors, I can never switch from c to action too well > > CARD ARRAY dur(4) > BYTE count > init_dur(); > FOR i=0 to 3 DO > dur(count) == -1; > if (dur(count) = 0) then > do_something(); > fi; > OD > > This code was supposed to decrement card values in the card array dur, > except that the compiler got all confused... refused to byte reverse > values in dur before decrementing. It didn't matter what I used to point > into the array.... same results. I fixed it by calling a function to > perform the decrement, i.e. decr(dur,count)!!!!! > > WORSE YET- this was entirely context sensative!!!!! Similar code > worked fine in different situations. I sure wish I knew what you did. My guess is that the program was incorrect (like this one is). I tried the following and it works just fine: CARD ARRAY dur(4) BYTE count, i count = 1 dur(count) = 3 FOR i = 0 TO 3 DO dur(count) ==- 1 IF dur(count)=0 THEN PrintE("works") FI OD > Add this to the inability of the compiler to operate on cardinal > values greater than 0x7fff, and you have a piece of software > that should never be used by anyone. I only know of one place where hex values do not work properly. That is for declaring the size of an array. This is a known (and documented by OSS) bug that has been fixed for the next revision of ACTION!. If you would like to provide an example (other than that mentioned above) where hex constants or CARDinals don't work properly, I would like to see it. Reported bugs in ACTION! ARE FIXED!!! But it is hard to fix a bug if you don't know that it exists. > What really bugs me is that OSS has no intention of fixing any of > this sh*t. And if they do... you can bet that it won't be the free > upgrade that it should be. I normally don't post messages here, but I could not let this one go by without a response. First, OSS does support its product. They have come out with 4 revisions to ACTION! since its initial release. The current version is 3.6. They also will give you a bug list if you request it and many of these have been described (with fixes) in their newsletter. If you didn't get a news letter, then you probably didn't send in the registration card (how are they going to send you a copy if they don't know who you are). They provide upgrades for old versions of the cartridge for $30.00. Now I know that isn't exactly cheap, but they do have to give you a whole new cartridge when they do it. (Let's face it, ACTION! isn't the biggest selling program in the world and low volume items carry a lot of overhead.) - Clinton Parker Action Computer Services ps: ACS really does like to here reports of bugs in ACTION!, but to be fair many of the reported bugs are actually programmer errors. I know this does not make the programmer feel too good when he/she is told this, but you should realize that it is very hard to fix something that isn't broken. Many reported bugs (that aren't) also deal with misunderstandings of what the user think ACTION! can do and what it really can do. For these, I am sorry, and again, would be willing to listen on how the manual could be improved (yes I know it's not that great) to correct these misunderstandings (specific examples would really help here). Thanks.
sah9577@ritcv.UUCP (Scott Hossler) (02/07/85)
> 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
mroddy@enmasse.UUCP (Mark Roddy) (02/07/85)
[squelch] > > I normally don't post messages here, but I could not let this one go by > without a response. First, OSS does support its product. They have come > out with 4 revisions to ACTION! since its initial release. The current > version is 3.6. > The version 3.6 has been out for about a year. It has numerous bugs. Given the state of the 800 series, I really doubt that a new version will be released. I don't think that asking $30.00 for a new cartridge to replace the previous bug infested version qualifies as support. Not when the stuff comes with the standard shrink wrap disclaimer "this product not guarenteed to function." Despite my non-recommendation of Action, it's still the best high level language available for home computers. I accept that most software has bugs, but companies that sell software tools, such as compilers, operating systems, word processors, etc. should be responsible enough to provide support. Presumably, thats why this kind of product demands a higher price than pac-man. Mark Roddy >
ravi@mcnc.UUCP (Ravi Subrahmanyan) (02/26/85)
I'm not sure why Scott Hessler's cartridge would tend to 'disappear', but I've had my ACTION! cartridge for about 9 months now, and it certainly has been inserted more than 100 times, but the plating on the contacts is still very much there. I think there may be a problem with that particular piece ( sure that spilled tea didn't get just a little too close to the cart?? Tannic acid does wonders for tinplate..), and OSS should replace it without complaining. Re. the lack of features, I agree with Scott that what is present is pretty good, considering BASIC is really the only alternative.. I guess I can always think of features I would like it to have, but there is so much I can do with what there is now .. again, the bitwise operations and structures are such an improvement over Basic. With ATARI apprently planning to keep the 800 series alive with the new XE's, I hope OSS will keep ACTION! alive and bring out bug-freer versions (you listening, Clint?) -=ravi=-