Megalextoria - RDF feed
https://www.megalextoria.com/forum2/
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.Action! Brain damage
https://www.megalextoria.com/forum2/index.php?t=rview&goto=85919&th=39718#msg_85919
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.
]]>mroddy2013-06-17T21:20:29-00:00RE: Action! Brain damage
https://www.megalextoria.com/forum2/index.php?t=rview&goto=85921&th=39718#msg_85921
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
]]>sah95772013-06-17T21:20:30-00:00