A92: cc68k - An Alternative...


[Prev][Next][Index][Thread]

A92: cc68k - An Alternative...




To All Who Are Interested:

I am currently working with Noah, trying to get the DJGPP (GCC port
for DOS) to work with Fargo II (and PlusShell...).  For those of you
who want to work on other C solutions, here is one I found awhile back.

I noticed one other person mention this program--cc68k.  It does work!
I was able to write a few programs and get some results.  I'll explain
what needs to be done to adapt cc68k for the simplest compatibility
with Fargo II.

STEP 1: Download cc68k.

    ftp://nyquist.ee.ualberta.ca/pub/motorola/m68k/cc68k.arc

STEP 2: Install.

    UnARC it to its own directory.  It contains binaries and source.

STEP 3: Update source and recompile.

    This will require that you have a C compiler for your platform.
    Edit the outcode.c file.  Look for the function upcase().
    Change it to look like the following:

         upcase(stg)      /* Convert string to upper case */
        char stg[];
        {
        #if 0             // ADDED: Bug fix for case-sensitiveness
          int i;

          i=0;
          while(stg[i])
          {
            stg[i]=toupper(stg[i]);
            i++;
          }
        #endif            // ADDED: Bug fix for case-sensitiveness
        }

    Note that this fix requires that your C compiler supports the pre-
    processor commands #if and #endif.  If you cannot support the pre-
    processor commands, you may comment out the code.  It is important
    that you do not remove the function.  It is easier to just remove
    the functionality.

    REASON FOR FIX: This will ensure that the symbols outputted are
    not changed to ALL-CAPS.  A68k _IS_ a case-sensitive assembler.

STEP 4: Write a post-cc68k-pre-a68k-processor

    This option may be omitted if you would simply like to update the
    cc68k program to output properly formatted a68k assembler.  If
    anyone would like to do this, then this step would not be needed.
    For my purposes, it was easier to write a separate program that
    would convert the .S output for cc68k into a .ASM input for the
    fargo.bat (in turn uses a68k).  It's nice that cc68k does NOT
    output a .ASM extension!  I wrote a quick and dirty processor in
    QuickBasic 4.0.  It basically handles all of the features below.

    Here is a sample C program that calls a few library routines.

        /* Testing various function calls */

        #define StatusBusy tios_CC_ST_busy
        #define StatusShowHelp tios_CC_ST_showHelp
        #define ClearScreen flib_CC_clr_scr
        #define IdleLoop flib_CC_idle_loop

        _main ()
        {
                StatusBusy( 0 );
                ClearScreen();
                StatusShowHelp( (char *) "Hello!\0" );
                IdleLoop();
        }

        char _comment[35] = "funcs.c -- Test various func calls",0;

    This program was successfully compiled and processed and then
    assembled and linked for the TI-92.  You will note some of the
    conventions I used.  The symbol "::" is a special symbol and
    therefore couldn't be used in the C file.  If you look at the
    defines, you see "_CC_".  This was converted by my processor
    program to the real "::" (Colon, Colon).  Feel free to choose
    your own symbol.

    I chose to use the macros (defines) as it makes the code easier
    to read.  StatusBusy() looks nicer than tios_CC_ST_showHelp.
    This allows new C include files to be generated from the ASM
    includes so all functions can be accessed easier.

    Here is what the cc68k compiler outputted (.S file):

                SECTION 9
        _main:
                LINK    A6,#0
                CLR.L   -(A7)
                JSR     tios_CC_ST_busy
                ADD.W   #4,A7
                JSR     flib_CC_clr_scr
                MOVE.L  #L_0,-(A7)
                JSR     tios_CC_ST_showHelp
                ADD.W   #4,A7
                JSR     flib_CC_idle_loop
        L_1:
                UNLK    A6
                RTS
                SECTION 15
        _comment:
                DC.B    102,117,110,99,115,46,99,32,45,45,32,84
                DC.B    101,115,116,32,118,97,114,105,111,117,115,32
                DC.B    102,117,110,99,32,99,97,108,108,115,0
                SECTION 9
        L_0:
                DC.B    72,101,108,108,111,33,0
                XDEF    _main
                XREF    tios_CC_ST_busy
                XREF    flib_CC_clr_scr
                XREF    tios_CC_ST_showHelp
                XREF    flib_CC_idle_loop
                XDEF    _comment
                END

    You can see that the format is really close.  In fact the program
    does assemble and link at this stage.  The "_CC_"'s need to be
    converted.  I also remember hearing that the "_main" and "_comment"
    need to be at the head of the program.  In fact, I believe it is
    true also that the first XDEF for libraries must be "_library".  My
    processor moved those XDEF's to the front of the assembler file.

    You can also see those wonderful XREF's.  I used them to my
    advantage.  Since the word before the "_CC_" is the library name,
    I took the opportunity to build the "include" statements at the
    beginning of the source code.  I stripped out the XREFs once I
    had the appropriate library includes.  The "SECTION" keywords
    do not hurt you.  I did not remove them.

    Here is the shell output from my program:

        Scanning FUNCS.S... Done.
         -- External Library Use Detected...
            * Found tios
            * Found flib
         -- Exported Functions Detected...
            * Exporting _main
            * Exporting _comment
        Converting FUNCS.S to FUNCS.ASM... Done.

    Here is the ASM output:

                include "tios.h"
                include "flib.h"
                xdef _main
                xdef _comment
                SECTION 9
        _main:
                LINK    A6,#0
                CLR.L   -(A7)
                JSR     tios::ST_busy
                ADD.W   #4,A7
                JSR     flib::clr_scr
                MOVE.L  #L_0,-(A7)
                JSR     tios::ST_showHelp
                ADD.W   #4,A7
                JSR     flib::idle_loop
        L_1:
                UNLK    A6
                RTS
                SECTION 15
        _comment:
                DC.B    102,117,110,99,115,46,99,32,45,45,32,84
                DC.B    101,115,116,32,118,97,114,105,111,117,115,32
                DC.B    102,117,110,99,32,99,97,108,108,115,0
                SECTION 9
        L_0:
                DC.B    72,101,108,108,111,33,0
                END

    This program will assemble and link properly.  I have run it
    several times and not crashed the TI-92.  Albeit, the comment is
    actually too long.  I believe the max length is 30(?) chars.

STEP 5: Create a BAT file for automated compiles

    The last step is to build a batch file to make the process easier.
    This is a copy of my cf.bat file.  It also makes backups of the
    previous ASM and 92P files.  This will delete the .S and .LIS
    outputs of the cc68k program.  (NOTE: cc68k.exe and fixasm.exe
    are in the %fargo%\bin directory)

        @echo off
        if not exist %1.c goto error0

        %fargo%\bin\cc68k %1.c
        if not exist %1.s goto error1
        if exist %1.bka del %1.bka
        ren %1.asm %1.bka>nul
        pause
        %fargo%\bin\fixasm /i %1.s /o %1.asm
        if not exist %1.asm goto error1
        if exist %1.bkp del %1.bkp
        ren %1.92p %1.bkp>nul
        pause
        call %fargo%\bin\fargo %1
        if not exist %1.92p goto end
        del %1.s>nul
        del %1.lis>nul
        goto end

        :error0
        echo File not found: %1.c
        goto end

        :error1
        echo There were errors and some files have not been found.

        :end

STEP 6: Enjoy!

    It does take a bit of work and bug testing.  I probably went through
    fifty or so revisions of my processor program.  But don't think this
    is a solve-all solution.  Let me point out a few catches when using
    cc68k:

    * K&R Standard:  For all of you who are quite familiar with the ANSI
            standard, you will hate K&R.  It took me several tries and
            many talks with my dad (who is an expert in just about any
            programming language).  Proto-typing is essentially not there.
            Everything appears to return longs.  Variable passing seems
            to be all in longs.  It's amazing that the one function in
            the C program above, StatusBusy, worked.  The program really
            asks for a WORD as it's parameter.  Since it CLR the long,
            it was zero everywhere.
    * Function Calls:  As I said before, it appears that the compiler
            passes everything as a long.  This makes calls to other
            functions impossible.  It would be necessary to write
            "wrapper" functions to take the variables passed by cc68k
            and properly convert them for passing to functions.  If the
            function passes by registers... who knows.  cc68k does some
            really interesting things when returning values and such.
            It likes to use D0 to pass things back.
    * Want C?  Write it all in C:  This is about the only use for the
            cc68k solution.  If your program is entirely self-contained,
            and you make no function calls where variable passing is a
            problem, you will be safe.  It seems counter-intuitive, but
            to really use cc68k, you almost have to "reinvent the wheel."

Sorry, for the really long post.  But I didn't want to try to upload
stuff to ticalc.org.  This solution really involves that you personally
work with the stuff.  For instance, my convention of "_CC_" may be
impossible for some people to deal with.  Who knows, maybe I'll set a
standard!

Enjoy,
====
Aaron Hill (Redmond, WA)
E-mail: SeracOhw24@msn.com
IRC Nick: SeracOhw (EF-Net)