[Coco] CASM Cross Assembler V3.0 Alpha

[secure at ytunnelpro.com]

On 4/9/2004, "Roger Taylor" <rtaylor at bayou.com> wrote:

>Ok, that'll work great.  Your -raw option looks like CCASM's -nr option, as
>I suspected.  This forces a ROM-like binary without any padding, as
>well.  Any RMB's are converted to data, and ORG headers are not output
>(however, they can be used to set the base address).

Exactly! Now I just need to finish cleaning up all the pseudo ops to make
sure that they catch the code emission stuff correctly. Chances are
I'll add more options to the main code emitter to be a bit more robust
and have it handle it rather than the pseudo's since it can be handled
differently between output types and I want to make it possible to
create code emitters in a .dll instead of in the main code to support
plugins.....ugh it's a growing beast :/


>Disk BASIC, ofcourse, deals with multi-record binary files (LOADMable)
>quite well no matter how many ORGigin headers are encountered or (to my
>knowledge) the size of each.  I don't have a clue why EDTASM output such
>small packets, but that's the first thing I did away with when I created
>CCASM.  I haven't had a file yet to be rejected by Disk BASIC.  In fact,
>you can manually SAVEM a block of RAM of a large size and go check that
>disk file and it will be a single-record file instead of a multi-record.

I talked to Bill Vergona about this once when I noticed his assembler was
creating bins that were a little larger than I was used to (after
switching from a patched Edtasm+). His reasoning was that it was just
easier to do it that way than to do random access file I/O or keep track
of each record and it's size. So most native assemblers just used a 128
or 256 byte buffer and output a record for each one.

Of course with C it's easier to use ftell/fseek to jump to the record
and update it then jump back to the end. Of course there are all kinds
of ways to do it.

Interestingly enough if you ever disassemble any of the Cer-Comp
utilities you'll see that most if not all retain the original record
blocks prior to the disk being copy protected.

>Also, your -o= option appears to accept a pathname instead of just a
>directory name.  Portal-9 forces an output file based on what you tell it
>to create.  Without the filename being known, any assembler could really
>output anything it wanted to and the IDE would have no way of knowing what
>file was created for the binary.  CCASM accepts a full pathname for the
>output file.

Yes, you should be able to include a full pathname on the -o and have it
work just fine. I think there's still a conflict between using -O and
-o together as IIRC -O is a legacy option from the original as9 or was
something I added REALLY early on.

>Oh, I am getting some phasing errors with CASM with source that is quite
>simple, so I will write you about this in a while with the code and let you
>take a look.  Other than that, I have one Portal-9 project (called 'Rom
>Pak') which is assembling and running in M.E.S.S. perfectly when assembled
>using your CASM.  Your -rom option computes an 8k rom, which mounts fine,
>ofcourse.

I looked into it and it appears that either the expression code is hosed,
 the forward reference manager isn't working correctly, the extended
and direct handlers aren't cooperating, or a combination of all three.
I know that I added about 4 FIXME or VISITME comments in the source of
the diect, extended, and indexed addressing mode handlers for things
that looked like potential bugs dealing with consistent code emission.

I do know that the error is being caused by the forward referencing a
symbol and I was able eliminate the problem by moving the data to the
front of the file. I'm wondering if the switch to a recursive decent
eval parser is causing or is partial the cause. Luckily the extended and
direct processing is farily isolated and easy to step through.


I'm going to try and do daily builds sunday thru friday around 8pm PST
to give everyone a chance to test things to make sure the problem isn't
already fixed. I'll probably go through and build all of the CCASM
examples along with all of the regression souce I have as raw binaries
and generate expected MD5 checksums for doing some of the testing.


I'll send you a reply tomorrow after I get a chance to look at it and
get you the latest souce tree and regression files.