From: winston@merk.com (Winston Smith)
Newsgroups: comp.sys.atari.8bit
Subject: Re: Kermit-65 source code
Keywords: makebin.c, KERMIT-65, assembler, 6502
Date: 5 Jan 93 09:34:34 GMT
Article-I.D.: merk.C0DJxn.7MI
Organization: Technology Partners, Inc.


> "Just when you thought it was safe to go back in the water...."
>  
>                        ...Unfortunately, the program that accompanies the
> assembler, that is supposed to turn the text characters into binary
> code, is written in ANSI C, and the file calls make the K&R C compiler I
> am using do strange things.  <* ARG! *>
 
 
"The saga of 'makebinary.c'...."
 
     Well, I had been trying to compile the program "makebin.c" so that the
executible could turn the hexadecimal text from the 6502 cross-assembler
"as6502" into actual hexadecimal code (also known as binary executible).
At first I thought that the problem was that the program was written in
ANSI C, so I edited all of the file calls and subroutine header statements
to be K&R compliant.  Nothing happened.  After toying with it for a while,
convinced that I didn't understand how ANSI C properly worked, I finally
fell back on the classic desperation move of putting a print statement
(well, in this case a PRINTF statement) in place where anything significant
happens:  before subroutine calls, at the top of procedures, around
calculations -- before and after, etc.  I then compiled again and watched
the execution trace.  It was at this point that I suddenly came to the
realization that the reason the program didn't --DO-- anything was not
because the file calls were wrong, but because --THAT WAS THE WAY THE
PROGRAM WAS WRITTEN-- !?!!  The program read in the input file, but
generated no output because --NO OUTPUT PROCEDURES ARE CALLED-- !
Apparently, the programmer abandoned work on the program when only half-way
through writing it (but posted it to an FTP archive?  I had always assumed
that only --WORKING-- programs existed in FTP directories, but perhaps no one
ever bothered to complain... since it was supposed to be creating
executibles for the ATARI 6502 8-BIT).
 
     This leads me to the situation I am in now.  I can generate a
hexadecimal text assembly listing, but what is the best or most accepted
method for generating an executible binary image from an "as6502" listing?
Apparently AMAC, and ASMED do not allow for "inline hex code".  I don't
have MAC-65 or "ACTION!".  Is there some type of program that can add a
checksum to the end of a hexadecimal text line so that it can be read by a
decoder?  Will FORTH accept straight hexadecimal text, or does it need to
be broken up into "screens" of data first?  Perhaps I can modify a "machine
language entry" program from one of the old ATARI 8-BIT magazines (at least
that is my first thought...)?  Is there a better program called "as6502", one
with a "-v" flag?  Perhaps I am using the wrong "as6502"?  I don't want to
reinvent the wheel if a simple solution exists already.  I suppose if worse
comes to worse I can always enter the entire source code suite by hand, but
if there is a short-cut... I would rather take it.  I guess that resorting
to some kind of hex code loader program using BASIC pokes wouldn't be
--TOO-- awful, but why was the work on "makebin.c" abandoned?  Obviously
a simpler solution must exist already!  Hmm....
 
Newsgroups: comp.sys.atari.8bit