Message-ID: <335@enmasse.UUCP>
Date: Mon, 4-Feb-85 17:13:17 EST
Article-I.D.: enmasse.335
Posted: Mon Feb  4 17:13:17 1985
Date-Received: Sat, 9-Feb-85 04:37:21 EST
References: <345@snow.UUCP>
Organization: Enmasse Computer Corp., Acton, Mass.
Lines: 49

[squelch]

[color=blue]>   o  Discussions of programs and languages (e.g. the brain-damaged 'records'[/color]
[color=blue]>      in Action.[/color]
[color=blue]>  3. Let's whine about Action; I love the fact that it is in ROM, that it[/color]
[color=blue]>     compiles fast, and *is* fast, but why can't you have pointers in records?[/color]
[color=blue]>     I hate using CARDs. And why are all variables static? Just try writing[/color]
[color=blue]>     recursive programs! (I know you can use arrays, but I want to be[/color]
[color=blue]>     difficult)  >-{[/color]

	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.

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




[color=blue]>  3. Let's whine about Action; I love the fact that it is in ROM, that it[/color]
[color=blue]>     compiles fast, and *is* fast, but why can't you have pointers in records?[/color]

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