slackey@bbn.com (Stan Lackey) (03/06/90)
I have been using AMAC quite a lot lately, and have determined that there is a bug in it. I know about the one where it sometimes doesn't find the macro name for a symbol after a label; I put a : after each label, and made that one go away. No, this one is more subtle; 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. If you know anything about this, you may be the one person that reads this that can help. Please respond; for nearly all my technical questions I ask on this newsgroup, I get no response. For most of the others I have found work-arounds, and I probably will for this one too, but ANY help is greatly appreciated. Even the most insignificant-seeming idea could save me a tremendous amount of time. I am developing something for release, I think lots of people can use it. -Stan
usenet@cps3xx.UUCP (Usenet file owner) (03/07/90)
In article <53063@bbn.COM> slackey@BBN.COM (Stan Lackey) writes: >I am developing something for release, I think lots of people can use >it. >-Stan Thought for the day - if you are in active development, at this point that makes YOU one of the experts with the answers. 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. Of course, that could be wrong. I never had the compiled program not _work_, whether it was byte for byte what the source code said is a different issue entire. Has anyone else noticed that AMAC really begs for a hard drive? My guess has always been that Old Atari Eng. had a hard disk in development and AMAC's flavor (ever try and use it on a floppy, single-den no RAMdisk? It was all there was for a looooonnnngggg time) came from the fact that it was used in-house. Terry Conklin conklin@egr.msu.edu uunet!frith!conklin The Club (517) 372-3131 The Club II (313) 334-8877 <-- 8-bit files online. Lots, in fact.
dcfs018@antares.Concordia.ca ( STEPHAN BOHM ) (03/07/90)
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
slackey@bbn.com (Stan Lackey) (03/07/90)
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
rvp@cbnewsh.ATT.COM (rob.v.phillips) (03/07/90)
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. ... > If you know anything about this, you may be the one person that reads > this that can help. Please respond; > ...ANY help is greatly appreciated. Even the most > insignificant-seeming idea could save me a tremendous amount of time. > OK! You opened the floodgates for insignificant-seeming ideas! I, for one, believe that ANY news is GOOD news in SOME groups where the traffic flow seems too low for my interests, so I'll throw in 2 cents! First off, I have just a little experience on AMAC, so I can only suggest that you may be encountering a rare but bad assumption concerning 6502 programming in general. A book by "Leventhal" on 6502 Programming has a good section on "Common Programming Errors" that I have found invaluable. A couple of glimmers through the fog of my memory: There is some problem with indirect jumps on the 6502 if the address crosses a page boundary (specifically, it doesnt work right). There is something unusual about the brk instruction... I think it pushes the Program counter PLUS 2 on the stack, so you might need to stuff in a nop or something after a break? Another possiblity that I have encountered on other assemblers is that they support the 6502c, and if you use 6502c instructions, they assemble them OK, but your target CPU may not understand these and punt. One problem that troubled me for hours recently...perhaps a SYNTACTICAL one! I said "TXS" where I meant TSX! That was tough to debug! Finally, if you have the resources, and have not tried it, you could of course, check this code out on another assembler. However, if any of my above statements is interesting and it inspires you to broaden your vistas on 6502 programming...why, your life will be generally heightened! On the other hand, if any of my statements is false (I do not attest to these), perhapse more responses on the net will heighten MY life! What a country!
landon@Apple.COM (Landon Dyer) (03/08/90)
> Has anyone else noticed that AMAC really begs for a hard drive? My guess > has always been that Old Atari Eng. had a hard disk in development and > AMAC's flavor (ever try and use it on a floppy, single-den no RAMdisk? > It was all there was for a looooonnnngggg time) came from the fact that > it was used in-house. No. Actually we used Data General MV/8000 ("Eclipse") minis, and ran AMAC as a cross assembler. Pretty fast turnaround, except for the 9600 baud downloads. At night, turning a 16K game around took about five minutes. During the day ... forget it. [I once tried to use AMAC on a 32K Atari 400 with a single 810 ... and went back to using the Assembler/Editor cartridge. Whoof!] I wrote twenty or thirty thousand lines of AMAC before moving on to more powerful and more obscure assemblers, and never ran into any serious problems. But it is likely that the in-house version of AMAC had some bug fixes that did not make it to customers. The Atari consumer engineering department was like that -- basically clueless as far as customer support was concerned. One of the better (faster) development systems I've ever used was a two machine setup that Jack Palevich and I whipped up one summer: Development 800 Target 400/800 (slave) +-----------------------+ +---------------+ | Axlon RAMDisk | | Debugger or | | SynAssembler | | emulator | | + screen editor | | | | | | | | X: device driver =============> X: slave ROM | +-----------------------+ +---------------+ The two 800s communicated with a two-wire or ten-wire cable hooked to both systems' joystick ports. The protocol automatically adjusted for the number of wires present -- downloads were faster with more. We used the Synapse assembler because it was fast, and we'd written a simple Emacs-style screen editor so we didn't have to deal with line numbers. It's amazing what you can put up with (no macros, no operators other than '+' and '-') for the sake of speed. The SynAssembler could direct the object code to any file, so by resetting the target system, and then assembling to the 'file' X:, the code was automatically downloaded and run. We got "one-button" five or ten second turnaround time, and the development system never, ever crashed. This was in 1983. A year ago I dragged all my 8-bit equipment out of the closet and tried to make it work. The RAMDisk was dead, the 810 wouldn't read anything, and the screen was too small. But it was fun while it lasted. -- ----------------------------------------- "Mmmph! Urghurmph! Grugmph!" Landon Dyer, Apple Computer, Inc. "What's he trying to say?" Development Systems Group (MPW / DSG) "I dunno -- someone shoved a NOT THE VIEWS OF APPLE COMPUTER lawyer in his mouth."
slackey@bbn.com (Stan Lackey) (03/08/90)
In article <8724@cbnewsh.ATT.COM> rvp@cbnewsh.ATT.COM (rob.v.phillips) writes: >In article <53063@bbn.COM>, slackey@bbn.com (Stan Lackey) writes: >> ...ANY help is greatly appreciated. Even the most >> insignificant-seeming idea could save me a tremendous amount of time. >OK! You opened the floodgates for insignificant-seeming ideas! >I, for one, believe that ANY news is GOOD news in SOME groups where the >traffic flow seems too low for my interests, so I'll throw in 2 cents! > [good list of 6502 crocks deleted] Thanks but I am not doing any of those things. Nonetheless, they are good to know, especially the indirect jump problem. My personal thanks for the responses I have received so far. I don't know the exact problem yet, but I may have a work-around; the problems went away when I set the listing option to expand macros (so I could see if that was the problem), and it went away. Now I made some other "insignificant" changes as well, unfortunately. If the error happens again, I will be more careful to keep the bad binary and this time diff it against the closest working one I can get. If I end up finding out any more I will post. -Stan
HILLKR@cc.utah.edu (03/15/90)
An old buddy of mine once told me that there was a bug in the macro handling in emacs-- something about either a maximum number or maximum size, sorry I don't remember which it was. This may not be of any help, but something about 100 sticks in my mind. I'm sorry I can't be more definite, but it's been quite a while. Hillkr@cc.utah.edu hillkr@utahcca.bitnet