Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.sys.atari.8bit
Subject: Re: Problem with AMAC
Message-ID: <53093@bbn.COM>
Date: 6 Mar 90 21:26:11 GMT
References: <53063@bbn.COM> <1895@clyde.concordia.ca>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 56

Thanks much for the responses so far.

In article <1895@clyde.concordia.ca> dcfs018@antares.Concordia.CA writes:
>In article <53063@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
>>I have been using AMAC quite a lot lately, and have determined that
>>there is a bug in it.  [...] it actually silently generates bad code.

>Which opcode is causing the problem (or is it the operand that's getting
>messed up)?  If it's the opcode, you might be able to get around it by
>replacing it with the equivalent byte (i.e. .BYTE opcode) followed by the
>operand (which is either 0,1, or 2 bytes).  For example if CPY #LABEL is
>the problem, you would look up the code for CPY immediate and use .BYTE opcode,
>and on the next line you'd put .WORD LABEL.

This I'm not sure of; perhaps 75% of my code is buried in macros.  Related
to the problem, you suspect?  Me too.  If I get to it tonight, I plan to
get a listing of the bad section with macros expanded (want to bet that
makes the problem go away? :-) ) and start to zero in.

>I remember reading in Analog a long time ago that one of the assemblers
>didn't handle CPY #x properly (I forget which instruction it was exactly).

Good input.  I may be doing some of these; I'll check to see it there 
are any in the bad spots.

>In any case I would consider getting another copy of AMAC (maybe you have a
>bad byte somewhere on your disk)
Shouldn't the checksum barf?  There IS a checksum, isn't there?

>, or better yet, change to MAC/65
Attractive, but you $$ know how $$ it is...

>Programming is hard enough without having to worry
>about your assembler generating wrong codes!
Especially in assembly language, especially with no debugger!

==================
In another article Terry Conklin writes:

>I have compiled probably ten thousand lines in AMAC and never had a
>compile time error. Either I was just lucky, or your bug is obscure.
Me too!  That's what's so weird about it.  So far, it has shown up in 
two (2) places!  Maybe it is one of my macros, using some kind of obscure
sequence.  I will look for any similarity between the two parts that
failed.

>Has anyone else noticed that AMAC really begs for a hard drive?
>ever try and use it on a floppy, single-den no RAMdisk?

OK I'm a caveman but that's all I have.  Well I do use an XF551 which
speeds it up some, but yes I sure wish I'd gone the extra $50 for a 
130XE instead of a 65XE, for that frizzin' ramdisk.  Too late now.

I will post anything I find out.  Keep those email messages and postings
coming!
-Stan