Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!antares!dcfs018 From: dcfs018@antares.Concordia.ca ( STEPHAN BOHM ) Newsgroups: comp.sys.atari.8bit Subject: Re: Problem with AMAC Summary: Which opcode? Message-ID: <1895@clyde.concordia.ca> Date: 6 Mar 90 19:29:47 GMT References: <53063@bbn.COM> Sender: usenet@clyde.concordia.ca Reply-To: dcfs018@antares.Concordia.CA Organization: Concordia University, Montreal Quebec Lines: 32 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. I am sure of this, as I >inserted a few NOP's here and there and the problem went away. > >-Stan 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. 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). In any case I would consider getting another copy of AMAC (maybe you have a bad byte somewhere on your disk), or better yet, change to MAC/65, which I use regularly, and I wouldn't consider using anything else. This thing is able to compile >15,000 line programs (I know, I've been writing Kermit-65 version 4, and version 3 was >400K of source! By the way ver.4 is pretty much complete). I don't know how you can stand working with a program (AMAC) that doesn't work right. Programming is hard enough without having to worry about your assembler generating wrong codes! Jean Goulet Electrical Engineering Class of '89 Concordia University Montreal, Canada