[info] How to use? Can it be used for the TRS-80 MC-10? about cc6303 HOT 33 CLOSED

You should be able to build a raw binary for the MC10 with something like

cc68 -m6803 -c *.c
ld68 -b -C 17500 libc/crt0.o *.o lib6803/lib6803.a -o my.bin
tapeify my.bin my.cas 17500 xxx 17500
where xxx is the length you need for it all to fit.

(tapeify currently lives in my ScottAdams6800 tree - a load of adventure games for the MC10)

That should build you a binary at 17500 and run it as main(NULL,NULL). You may need to change crt0.s to put the stack pointer somewhere. (lds #lastbyteofstackinclusive )

from cc6303.

Your command line is right - but I've not yet ported tapeify from the old motorola as1 to these tools.

I've just done a quick conversion - only had time to check it with a hexdump of the output but it looks right

from cc6303.

I will update it - or make it dynamic.

from cc6303.

In theory if you write some kind of support library for it. At the moment I am just doing that for Fuzix on my 6303 board. 6803 is a bit different in the support code but not much (mostly it lacks XGDX) so a few bits of the support code will need to be different (eg divide)

There is a fair bit missing before it's that useful - the support library needs more routines adding and there is a ton of debugging left to do.

But eventually yes it should be possible to write C code for the Alice or MC10. Not sure it's that useful given 680x asm is nice and you don't have much memory.

from cc6303.

Even without a library, it would be cool to build a binary for 6803 targets.
I know the 4k on the TRS-80 MC-10 are not much but some simple C games can be written. Moreover there were memory expansions and some 32k models (Alice Matra 32k).

from cc6303.

@EtchedPixels, how do I build and use your compiler?
I would like to give a try. I may try to implement some simple output function to produce a visible output on the screen.
The goal for me is to build my universal 8-bit game Cross Chase and its library CrossLib
https://github.com/Fabrizio-Caruso/CROSS-CHASE
on systems with the Motorola 6803.

from cc6303.

I think the best answer is probably "come back in a few months". It's not really ready for general consumption yet.

from cc6303.

Ok! Your project is very exciting! I understand it is not ready, yet, to do much for the public.
When the moment comes, I would like to test it and maybe help you find bugs and missing features.

from cc6303.

"make all" fails because there is no Makefile in lib6303.
I see you are working right now on the project.
Should I report bugs now? Or rather wait? I don't want to annoy you with GitHub issues.

from cc6303.

Please report them now especially on integer code. I know 32bit divide is broken, I need to stare at the support code again and debug that. Currently it's good enough I can boot a Fuzix kernel on my 6303 box, run through init and the start of the rc script then get stuck setting the date (because the time code is full of 32bit maths)

The -X option is useful when looking at misbehaving code - it saves all the compiler temporary files so you get a .@ file (before optimizing) and a .s file (optimized a bit).

Also be careful with emulators. The signed maths makes heavy use of the V flag and not all emulators get it right.

from cc6303.

At the moment I am not able to build your compiler because of the missing Makefile in lib6303.
I am not familiar with Fuzix... I can help you test it with Fuzix if you give me the necessary instructions (or link to instructions) on how to build the compiler, emulate Fuzix, run and test some code. I could some tests.

As already mentioned my primarily use of your compiler in the future would be to add it to my universal tool chain for vintage computers/consoles:
https://github.com/Fabrizio-Caruso/CROSS-CHASE
If your compiler/linker produces relocatable code or you can set the initial address, then your compiler may be used for any system with 6303/6803 (and maybe 6800) CPUS.
So the long term goal for me would be to rather use it with things like TRS 80 MC-10, Alice Matra (they all support memory expansions), and Alice Matra 32k, etc.

from cc6303.

You just fixed the Makefile! Thanks!

from cc6303.

Alan, can you please share the details of your 6303 hw?

from cc6303.

RC2014 backplane, RC2014 512K RAM/ROM card, my 6303 CPU card, 7.3728MHz clock, RC2014 CF adapter.

For the 6800 side I've just done and sent off the CPU board design for a 6808 (6800 with less supporting chips needed) so I can bootstrap Flex on it and use that to test the 6800 native target and build a basic C library for Flex.

I've also got a 68HC11 that once I start hardware testing I'll do test runs on as well. The HC11 is a superset of the 6803 (but not 6303), and the 6303 CPU card can be built for a 6803 so eventually I'll probably test that too.

from cc6303.

@EtchedPixels
I am trying to use the new option -t but I cannot find any example.
If i try cc68 -tmc10 bar.c I get

$ cc68 -tmc10 bar.c
[/opt/cc68/lib/cc68 -I /opt/cc68/inc/ -r --add-source --cpu 6303 -D__6303__ -D__TANDY_MC10__ bar.c ]
[/opt/cc68/lib/copt /opt/cc68/lib/cc68.rules ]
[/opt/cc68/bin/as68 bar.s ]
[/opt/cc68/bin/ld68 -b -C 17500 -Z 32 -o a.out /opt/cc68/lib/crt0.o bar.o /opt/cc68/lib/libc.a /opt/cc68/lib/libio6803.a /opt/cc68/lib/libmc10.a /opt/cc68/lib/lib6303.a ]
[/opt/cc68/lib/mc10-tapeify a.out a.out.tap 17500 35 17500 ]
a.out: not an as1 memory image
cc: /opt/cc68/lib/mc10-tapeify failed.

What am I doing wrong? Could you provide an example?

In my case the test program is just an empty main function:

int main(void)
{
        return 0;
}

from cc6303.

Thanks for your work! I will wait for your adaptation. I am looking forward to using you cross-compiler in my Cross-Lib project.

from cc6303.

@EtchedPixels Thanks a lot for the update! I have now managed to compile a program and build a tape image.
I have not tried a program with some output, yet. I will try something that pokes onto video ram to see some effect.

I wonder what I need to include and/or link to get putc, putchar, getc, etc.
Isn't -tmc10 already linking with the mc10 library?

#include<stdio.h> fails.

from cc6303.

Which emulator do you use with the .tap files produced by tapeify?
VMC-10 complains it is not 8-bit mono.

from cc6303.

I don't know whether you have tested your latest changes on tapeify and whether you are still working on it. I see you have commited some changes and I see that the -t option produces both a binary a.out and .tap file.

It seems that the .tap file produced is broken.
If I try to compile:

#define POKE(addr,val) (*(unsigned char*)(addr)=(val))
#define SCREEN 16384
int main(void) {
        POKE(SCREEN,65);
        POKE(SCREEN+1,66);
        POKE(SCREEN+2,67);
        return 0;
}

with:
cc68 -tmc10 bar.c
I get:

-rwxr-xr-x+ 1 fabri fabri 17553 May 30 23:44 a.out*
-rwxrw-r--+ 1 fabri fabri   342 May 30 23:44 a.out.tap*

It seems that the .tap file is way too small to be a function tape image. I tried to load it with VMC-10 but I failed.

I also tried to load a.out at $4c00 and $4c5c (17500).
I tried to load a.out.tap as if it were a .c10 file with CLOAD.

from cc6303.

The tap file length looks right - it's starting from a memory image which is mostly leading zeros (hence the 17K).

I've cleaned up a few things to get it working for me. Not sure why the tape bit would fail but there was a 1 byte difference from the actual MC10 exec files. With that changed, the .c10 ending and a few other fixes pushed I can compile a hello world tester and upload the C10 file and run it on mc-10.com (browse, select the C10 file, then EXEC)

from cc6303.

Cool! It works indeed with a hello world example! Thanks!

I am now trying to use it with the same syntax as CC65, i.e., multiple source files to compile and link at the end.

If I try to compile my universal games written with Cross-Lib I get this error:

$ make mc10 -f Makefile.bomber
cc68 -tmc10  -Icross_lib -Icross_lib/sleep -Icross_lib/display -Icross_lib/display/graphics_mode -Icross_lib/display/alt_print -Icross_lib/include -Icross_lib/sound -Icross_lib/sound/cc65/atmos -Icross_lib/sound/cc65/c264 -Icross_lib/sound/cc65/pokey -Icross_lib/sound/cc65/sid -Icross_lib/sound/cc65/vic20 -Icross_lib/sound/cc65/gamate -Icross_lib/sound/cc65/creativision -Icross_lib/sound/cc65/pet -Icross_lib/sound/z88dk/bit_bang -Icross_lib/sound/z88dk/gb -Icross_lib/sound/z88dk/psg -Icross_lib/sound/lcc1802/comx -Icross_lib/sound/cmoc/mo5 -Icross_lib/sound/generic -Icross_lib/text -Icross_lib/input -Icross_lib/rand -Icross_lib/display/redefine_characters -Icross_lib/display/tiles -Igames/bomber/generated_assets -Igames/bomber/ \
-D__MC10__ \
...
-DDEFAULT_CLEAR_SCREEN \
cross_lib/display/alt_print/memory_mapped_alt_print.c \
cross_lib/display/display_macros.c cross_lib/input/input_macros.c cross_lib/text/text_macros.c games/bomber/main.c  -o xbomber
cc: too many arguments to command.
make: *** [Makefile.bomber:1387: mc10_buffered] Error 1

Does your command line support multiple source files? Do I have to compile each file separately and link it afterwards?

from cc6303.

It does but I set MAXARG to 64 in frontend/cc.c - change that for a much bigger number and all should be well

from cc6303.

Thanks! I will try that.
By the way the CC65 version your project is based on may also have a low limit on the number of nested #if statements if you are using the same preprocessor. How can I bring that value to 256 (as current CC65)?
This is needed to correctly process a long list of #elif (that may also be interpreted in a non-nested way but CC65 sees that as nested).

from cc6303.

I track cc65 updates now and then so I'll have a look at the cc65 git log for things to pick when I get some time.

from cc6303.

Thanks a lot! If I set MAXARG to a 255, the compilation does not fail with the error any more. I still get errors but they are related to missing stuff, which I have to implement. Thanks to your compiler, I may add support for the MC-10 in my framework. I am looking forward to seeing if I manage to get working versions of my games on the MC-10.

If it is not too bad for you, would you raise MAXARG to whatever CC65 uses in its front-end or just a higher value like 255?
If not, it is not a big issue as I can always change it myself.

from cc6303.

If I provide the missing bits, the compilation of one of my games fails with:

games/chase/main.s: 1278: M: multiple definitions.
Phase 2: Dot e7 Should be ea
games/chase/main.s: 1278: P: phase error.
games/chase/main.s: 1284: M: multiple definitions.
games/chase/main.s: 1294: M: multiple definitions.
Phase 2: Dot ef Should be f1
games/chase/main.s: 1294: P: phase error.
games/chase/main.s: 1296: M: multiple definitions.
Phase 2: Dot f0 Should be f1
games/chase/main.s: 1296: P: phase error.
games/chase/main.s: 1298: M: multiple definitions.
cc: /opt/cc68/bin/as68 failed.
make: *** [makefiles.chase/Makefile.cc6303_targets:37: mc10_no_print] Error 1

I am not an Assembly coder but I am willing to help you debug your compiler/linker if I can.

In case you would like to try to compile it yourself, you just need to clone Cross-Lib (https://github.com/Fabrizio-Caruso/CROSS-LIB) and run: make mc10

If I compile with the -S option I can see the .s files. See in the attachment.
chase.zip

from cc6303.

from cc6303.

@EtchedPixels would it ne possible in the next versions to have a check on more characters? Possibly at least 40? Or even more.

Could you please point me to the source code where I can set the limit to a higher value?

It looks hard-coded in at least ld.c, ld.h and as.h if I understand your code.

I have tried to change NCPS in as.h and the hard-coded value 16 in ld.c and ld.h but the result is an unspecified error by the linker. Maybe the value 16 is hard-coded elsewhere.

from cc6303.

The object file format, linker and other tools used are designed to be able to run native on an 8bit micro so it is intentionally limited and there is a big memory cost in supporting long names. C89 requires only 6 significant characters for linking. Even C99 only guarantees 32 if I remember rightly.

The 16 is probably hardcoded in places it shouldn't be.

from cc6303.

@EtchedPixels I see. The best solution would be to have these limits set by a parameter. So that one can also compile your framework as a cross compiler with higher limits for things like name length and number of arguments and pre-processor stack depth.
I don't know the standard values but I can tell you that I compile Cross-Lib with more than a dozen cross-compilers and native compilers with no problem including native GCC, several GCC mods as cross-compilers, CC65, Z88DK (both SCCZ80 and SDCC), LCC(1802), CMOC, VBCC, etc.

from cc6303.

I have tried to raise 16 to a higher value and I get everything to compile but the linker fails with an unspecified error. How can I debug it? If I use the verbose mode, it seems to fail because the verbose mode writes log stuff into the .s files. You probably know where the 16 value can be found. I have tried by modifying ld.c, ld.h and as.h and no other file.

from cc6303.

Updated to support the C99 standard requirement as an option, and to build cross tools with that format.

from cc6303.

@EtchedPixels Thanks!
I guess it is set automatically to 32 chars by default if I build it on a PC.
I have seen it and pulled the changes. There seems to be a bug that prevents my games to compile. I have reported it in #4.

from cc6303.