🚀 go-pugleaf

[ddt]

> 	I evaluated the operating systems by two sets of criteria. 
> 	First, they had to meet three requirements: 
> 
> 		1) double-sided double density support;
> 		2) ADOS compatibility- if it runs using the
> 		   Atari OS it has to run under the tested OS;
> 		3) reliability- disks should not be routinly trashed;
> 		4) Atari DOS file compatability (or conversion utilities;
> 		5) accurate user documentation.

 ooops! try five requiremnts

[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.

> [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.
 

 [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
>