home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / atari / 8bit / 5786 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  3.5 KB
  1. Path: sparky!uunet!wupost!emory!ogicse!das-news.harvard.edu!spdcc!merk!winston
  2. From: winston@merk.com (Winston Smith)
  3. Newsgroups: comp.sys.atari.8bit
  4. Subject: Re: Kermit-65 source code
  5. Keywords: makebin.c, KERMIT-65, assembler, 6502
  6. Message-ID: <C0DJxn.7MI@merk.com>
  7. Date: 5 Jan 93 09:34:34 GMT
  8. Article-I.D.: merk.C0DJxn.7MI
  9. References: <BzyKMB.CMJ@merk.com> <72769@cup.portal.com> <C07sBJ.Juv@merk.com>
  10. Organization: Technology Partners, Inc.
  11. Lines: 51
  12.  
  13.  
  14. > "Just when you thought it was safe to go back in the water...."
  15. >  
  16. >                        ...Unfortunately, the program that accompanies the
  17. > assembler, that is supposed to turn the text characters into binary
  18. > code, is written in ANSI C, and the file calls make the K&R C compiler I
  19. > am using do strange things.  <* ARG! *>
  20.  
  21.  
  22. "The saga of 'makebinary.c'...."
  23.  
  24.      Well, I had been trying to compile the program "makebin.c" so that the
  25. executible could turn the hexadecimal text from the 6502 cross-assembler
  26. "as6502" into actual hexadecimal code (also known as binary executible).
  27. At first I thought that the problem was that the program was written in
  28. ANSI C, so I edited all of the file calls and subroutine header statements
  29. to be K&R compliant.  Nothing happened.  After toying with it for a while,
  30. convinced that I didn't understand how ANSI C properly worked, I finally
  31. fell back on the classic desperation move of putting a print statement
  32. (well, in this case a PRINTF statement) in place where anything significant
  33. happens:  before subroutine calls, at the top of procedures, around
  34. calculations -- before and after, etc.  I then compiled again and watched
  35. the execution trace.  It was at this point that I suddenly came to the
  36. realization that the reason the program didn't --DO-- anything was not
  37. because the file calls were wrong, but because --THAT WAS THE WAY THE
  38. PROGRAM WAS WRITTEN-- !?!!  The program read in the input file, but
  39. generated no output because --NO OUTPUT PROCEDURES ARE CALLED-- !
  40. Apparently, the programmer abandoned work on the program when only half-way
  41. through writing it (but posted it to an FTP archive?  I had always assumed
  42. that only --WORKING-- programs existed in FTP directories, but perhaps no one
  43. ever bothered to complain... since it was supposed to be creating
  44. executibles for the ATARI 6502 8-BIT).
  45.  
  46.      This leads me to the situation I am in now.  I can generate a
  47. hexadecimal text assembly listing, but what is the best or most accepted
  48. method for generating an executible binary image from an "as6502" listing?
  49. Apparently AMAC, and ASMED do not allow for "inline hex code".  I don't
  50. have MAC-65 or "ACTION!".  Is there some type of program that can add a
  51. checksum to the end of a hexadecimal text line so that it can be read by a
  52. decoder?  Will FORTH accept straight hexadecimal text, or does it need to
  53. be broken up into "screens" of data first?  Perhaps I can modify a "machine
  54. language entry" program from one of the old ATARI 8-BIT magazines (at least
  55. that is my first thought...)?  Is there a better program called "as6502", one
  56. with a "-v" flag?  Perhaps I am using the wrong "as6502"?  I don't want to
  57. reinvent the wheel if a simple solution exists already.  I suppose if worse
  58. comes to worse I can always enter the entire source code suite by hand, but
  59. if there is a short-cut... I would rather take it.  I guess that resorting
  60. to some kind of hex code loader program using BASIC pokes wouldn't be
  61. --TOO-- awful, but why was the work on "makebin.c" abandoned?  Obviously
  62. a simpler solution must exist already!  Hmm....
  63.  
  64.