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)