Giter VIP home page Giter VIP logo

cc6303's People

Contributors

etchedpixels avatar kwhr0 avatar mokona avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cc6303's Issues

[question/feature] Where is the MC10 code located by default?

Where is the code for the MC10 target located by default when compiled by running the following command?

cc68 -tmc10 foo.c -o foo

Is it located at $4200 just after text mode video ram?
I am asking because I fear that this would break any program that uses graphics mode (as they may take 3k or $4000-$4BFFF) if I am doing the math correctly.

Where are the different sections in memory? rodata? Maybe the code starts at $4C00 but it maybe the C software stack or the rodata is somewhere in $4000-$4BFFF and it is interfering with the graphics.

I have tried to use the -C and --start-addr options with cc68 but they are not available.
I have not found a cfg linker file to control where the sections are in memory (such as the ones in CC65).

Is there a way to output a map file that shows where variables are in memory?

I see there may be a way to do this by using the linker ld68 command, though.

libc.a is 0 byte

Hi
I compiled under cygwin 64 and there is a problem with that file
CC6303\libc\libc.a
Size is 0 byte.

Testing compilation give a failure, saying libc.a is not good.
While processing: /opt/cc68/lib/libc.a
bad object file
cc: /opt/cc68/bin/ld68 failed.

[info/bug?] How do I build the compiler? make all fails under Windows/Cygwin

I am under Windows/Cygwin.
Can I build CC6303 in this environment.

If I run make all I get:

...
../as68/as68 _setjmp.s
make[1]: Leaving directory '/cygdrive/c/Retro/CC6303/lib6803'
(cd lib6303; make)
make[1]: Entering directory '/cygdrive/c/Retro/CC6303/lib6303'
../as68/as68 divide.s
../as68/as68 laddeq.s
../as68/as68 lsubeq.s
../as68/as68 tosudivax.s
make[1]: Leaving directory '/cygdrive/c/Retro/CC6303/lib6303'
(cd libio; make)
make[1]: Entering directory '/cygdrive/c/Retro/CC6303/libio'
(cd 6800; make)
make[2]: Entering directory '/cygdrive/c/Retro/CC6303/libio/6800'
make[2]: *** No targets specified and no makefile found.  Stop.
make[2]: Leaving directory '/cygdrive/c/Retro/CC6303/libio/6800'
make[1]: *** [Makefile:2: all] Error 2
make[1]: Leaving directory '/cygdrive/c/Retro/CC6303/libio'
make: *** [Makefile:21: libc] Error 2

[bug?][right shift] Right shift operator produces broken binary

I may have found a bug in the shift operator >> with this minimal code, which is supposed to display ABC (after pressing a key) on the MC-10. The bug is not related to the MC-10, though, as I am doing nothing special with it.

I have tested this with the very last version of CC6303 as of today 2022/03/26 (but the problem is also present in previous versions).

This minimal code crashes at a = 255>>(b-1);

#define POKE(addr,val)     (*(unsigned char*) (addr) = (val))
#include <stdio.h>
int main(void) {
        unsigned char a;
        unsigned char b;

        b = 1;
        POKE(16384,65);
        getchar();
        a = 255>>(b-1);
        POKE(16385,66);
        getchar();
        POKE(16386,67);
        return 0;
}

The problem does not exist with 255>>0 nor with 255U...

Issue with little CRC-16 program compilation?

Hi EtchedPixels,

You asked me to open this as a bug on your github page for the project. I'm hoping to add a CRC-16 routine to an old 6800 based 1987 car computer. I started with this little program:

#include <stdio.h>
#include <stdlib.h>

#define CRC16 0xa001

unsigned short calc_crc(unsigned char *data, char size)
{
unsigned short crc = 0;
short i;
    while(size--){
        crc ^= *data++;
        for(i = 0; i < 8; i++)
            crc = (crc&1) ? (crc>>1)^CRC16 : (crc>>1);
    }
    return crc;         
}

int main(int argc, char **argv)
{
    if (argc < 3) exit(-1);
    unsigned short crc = calc_crc(argv[1], atoi(argv[2]));
    printf("%04X\n", crc);

}

Which I then pared back to this to run it through cc68:

#define CRC16 0xa001

void calc_crc()
{
unsigned char *data = 0x6000;
unsigned char size = 0xDD;
unsigned short crc = 0x7654;
char i;
    while(size--){
        crc ^= *data++;
        for(i = 0; i < 8; i++)
            crc = (crc&1) ? (crc>>1)^CRC16 : (crc>>1);
    }
}

I only put those values as the defaults for the variables so I knew which was which in the assembly as so I could set them appropriately post compilation.

I fixed up the assembly so that exorsim is happy with it:

L0002   EQU    $2200
L0004   EQU    $2202
L0006   EQU    $2204
L0008	EQU    $2206
TMP     EQU    $2208
TMP1    EQU    $220A
        ORG  $2800
CALCCRC	LDAA #$24 * START ADDRESS MSB
	CLRB      * END ADDRESS MSB
	STAA L0002
	STAB L0002+1
	CLRA
	LDAB #$0A * DATA LENGTH
	STAB L0004
	LDAA #$00 * CRC MSB
	LDAB #$00 * CRC LSB
	STAA L0006
	STAB L0006+1
	JMP L000B
L0009	LDAA L0006
	LDAB L0006+1
	PSHB
	PSHA
	LDAA L0002
	LDAB L0002+1
	STAA TMP1
	STAB TMP1+1
	ADDB #$01
	ADCA #$00
	STAA L0002
	STAB L0002+1
	LDAA TMP1
	LDAB TMP1+1
	STAA TMP
	STAB TMP+1
	LDX TMP
	CLRA
	LDAB $00,X
	TSX
	EORB $00+1,X
	EORA $00,X
	INS
	INS
	STAA L0006
	STAB L0006+1
	CLRA
	CLRB
	STAB L0008
L000F	CLRA
	LDAB L0008
	CMPB #$08
	JSR BOOLULT
	BNE L0012
	JMP L0010
L0012	LDAA L0006
	LDAB L0006+1
	CLRA
	ANDB #$01
	STAA TMP1
	ORAB TMP1
	BEQ L001A
	LDAA L0006
	LDAB L0006+1
	LSRA
	RORB
	EORB #$01
	EORA #$A0
	JMP L001D
L001A	LDAA L0006
	LDAB L0006+1
	LSRA
	RORB
L001D	STAA L0006
	STAB L0006+1
L0011	CLRA
	LDAB L0008
	INC L0008
	JMP L000F
L0010
L000B	CLRA
	LDAB L0004
	DEC L0004
	TSTB
	BNE L9999
L000A
L0001	RTS
L9999   JMP L0009
BOOLULT LDAB    #0
        TBA
        ROLB
        RTS

Steps to reproduce:

Exorsim:

https://github.com/jhallen/exorsim

Best to get one of the latest commits because otherwise the source needs to be tweaked to eliminate some conflicts. You probably already have it. I built it in cygwin.

Create a text file called 1234567890.txt and put 1234567890 in it.

Then in your cygwin window:

./exor --mon

a 0

[Paste in the assembly above]

read 1234567890.txt 2400

x 2800

d 2200

When I run the full program in cygwin like so:

$ ./testcrc 1234567890 10
C57A

I get a CRC-16 as shown. I was expecting to find the CRC at 2206/2207 in exorsim, but it seems all its doing is counting to 8? I wish I knew if I'm doing something wrong or if I've hit a bug in cc6303.

[question] Assembly and C?

First of all sorry to use an issue for a question.

I would like to have a routine getk that just polls the MC-10 keyboard without waiting.

In BASIC I could just read values at 17023 and 2 to poll the keyboard.
But if I use CC68 and I try to "peek" at location 17023 I do not get the ASCII code of the last key pressed.
Nor does the value at 2 gets updated if any key is pressed.
So I guess something is different. Maybe those values are updated by some interrupt that your crt disables.

So I suppose I need to resort to some little Assembly.
I am not an Assembly coder and my best guess would be a .s file with this content:

.export _getk
.setcpu 6803

.code

_getk:
    pshx
    ldx $FFDC
    jsr ,x
    pulx
    tab
    clra
    rts

If I try to compile it, cc68 complains with multiple errors of this type:
test/mc10_getk.s: 1: Q: unexpected character.

With CC65 I can compiler and link a mix for .c and .s. How do I do it with CC68?

Cassette file produced by Tapify gets me ?FM Errors

Hello,

I've been trying to produce a ".c10" file and load it in both DCAlice and Mame emulator, with different configuration of the computer. Each time, a CLOAD gives me a "?FM Error", which from the documentation means "File Mode error".

I've compared the tapify output with some reference other file that I load successfully and don't see any blatant difference, except maybe the trailing data, which sometimes as synchro bits at the end of the tape (I've had the similar problem with the VG5000µ in the past).

But modifying tapify.c to output more "0x55" at the end of the file didn't solve the problem.

I'm short of ideas. Is this a known problem? Am I doing something wrong?

Here is the project that I wrote : https://gitlab.com/mokona/matraalicebaseproject

[feature request] Future support for the TMS9900? (if possible with minimal lib for the TI99/4A?)

I have seen some of your very recent development for the TMS9995.
Do you plan to also support the plain TMS9900. They almost have the set instruction set, with the TMS9995 maybe adding only 4 opcodes.
If that is the case, would you also consider adding a target for the (memory expanded) TI99/4A with very minimal input/output (as you have done for the MC-10)?

For a reference on a similar project (GCC for TI99/4A) you may find this useful:
https://atariage.com/forums/topic/164295-gcc-for-the-ti/

I have been able to use it here:
https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/games/chase/makefiles.chase/Makefile.gcc_tms9900_targets

Some of the tools and crt are described in the thread above.
What I use for my project is also found here:
https://github.com/Fabrizio-Caruso/CROSS-LIB/tree/master/tools/ti99

There is also a CONIO implementation here that may be useful:
https://github.com/tursilion/libti99

[bug] Probably wrong arithmetic or cast

I am compiling a simple program that is supposed to fill the screen with screen code 67 ('C' on many systems include the MC-10):

#if defined(__MC10__)
    #define SCREEN 0x4000
    #define YSize 16
    #define XSize 32
#elif defined(__C64__)
    #define SCREEN 0x0400
    #define YSize 25
    #define XSize 40
#elif defined(__VIC20__)
    #define SCREEN 7680
    #define YSize 23
    #define XSize 22
#endif
#define POKE(addr,val) (*(unsigned char*) (addr) = (val))
#include <stdint.h>

int main(void)
{
    uint8_t i;
    uint8_t j;
    for(i=0;i<YSize;++i)
    {
        for(j=0;j<XSize;++j)
        {
            POKE((uint16_t) SCREEN+((uint16_t)i)*XSize+j,67);
        }
    }
    while(1){};
    return 0;
}

I compile it with CC65 and CC6303 with something like:

mc10_test:
	cc68 -tmc10 -D__MC10__ $(SOURCE_PATH)/../../test/mc10_test1.c -o $(BUILD_PATH)/$@

vic20_test: 
	cl65 -tvic20 -D__VIC20__ $(SOURCE_PATH)/../../test/mc10_test1.c -o$(BUILD_PATH)/[email protected]

c64_test: 
	cl65  -D__C64__ $(SOURCE_PATH)/../../test/mc10_test1.c -o$(BUILD_PATH)/[email protected]

It works fine on both the C64 and VIC20 but on the MC10, it just fills half the screen as if there were some sort of overflow:
image

I have attached the MC10 binary and the .c10 file
build.zip

[Question]

I’m experimenting with your compiler for the Matra Alice 32/90

I can compile and run the program.
But using a little more calculations like some divisions, I get these error codes when compiling:

/opt/cc68/lib/lib6803.a: Unknown symbol 'div16x16'.
/opt/cc68/lib/lib6803.a: Unknown symbol 'pop2'.

Second to be able to take advantage a little more of the capabilities of the machine.
I need to be able to embed ASM code, but I can’t:
Error: Error in __asm__ format specifier 1

thank you for your work

[bug] Broken Conditional or assignment

If I compile:

#if defined(__MC10__)
    #define SCREEN 0x4000
    #define YSize 16
    #define XSize 32
#elif defined(__C64__)
    #define SCREEN 0x0400
    #define YSize 25
    #define XSize 40
#elif defined(__VIC20__)
    #define SCREEN 7680
    #define YSize 23
    #define XSize 22
#endif

#define POKE(addr,val) (*(unsigned char*) (addr) = (val))
#include <stdint.h>

#define FOO 10
#define BAR 1
uint8_t bar;

int main(void)
{
    bar = BAR;
    POKE(SCREEN,65);
    while(1 && (bar < FOO + 1))
    {
        POKE(SCREEN+1,66);
    }
    POKE(SCREEN+2,67);

    while(1){};
    return 0;
}

I expect to see "AB" (as I do if I compile with CC65) but if I compile with CC6303 for the mc10 I get: "A C" on the top left corner of the screen.
image

I have attached the binary and c10 file.
build.zip

6800 build generates a relocation failure when building Fuzix "dc"

cc68 -o dc /bulk/home/alan/UZI/External/FUZIX/Library/libs/crt0_6800.o dc.o  -m6800 -tfuzix -s -L /bulk/home/alan/UZI/External/FUZIX/Library/libs -lc6800 -M 
width 1 relocation offset 218, 58, 276 does not fit.
While processing: dc.o
relocation exceeded
cc: /opt/cc68/bin/ld68 failed.
```

[bug] Arrays seem to return their index

If I compile:

#if defined(__MC10__)
    #define SCREEN 0x4000
    #define YSize 16
    #define XSize 32
#elif defined(__C64__)
    #define SCREEN 0x0400
    #define YSize 25
    #define XSize 40
#elif defined(__VIC20__)
    #define SCREEN 7680
    #define YSize 23
    #define XSize 22
#endif

#define POKE(addr,val) (*(unsigned char*) (addr) = (val))
#include <stdint.h>

static const char foo[5] = {'H','E','L','L','O'};

int main(void)
{
    uint8_t i;

    for(i=0;i<5;++i)
    {
        POKE((uint16_t) SCREEN+i,foo[i]);
    }
    while(1){};
    return 0;
}

I get reversed @abcd instead of reversed HELLO on the left top corner of the screen as I do on the Vic 20 and C64.
image

I have attached the binary and C10 file:
build.zip

[bug?] make clean does not clean libs and other files. Is it wanted?

If I run make clean I see that many files are not cleaned:

        copt/killdeadlabel.exe
        copt/killdeadlabel.o
        libio/6800/libio6800.a
        libio/6803/libio6803.a
        target-flex/lib/crt0.o
        target-flex/lib/libflex.a
        target-mc10/lib/crt0_mc10.o
        target-mc10/lib/libmc10.a
        tmp/

Is this the desired behavior?

Syntax errors with conditional jumps

Hi, I am attempting to build the FUZIX Compiler Kit for Z80 which depends on /opt/ccz80/bin/asz80 from this repo. It works up until it gets to the part where it compiles the Z80 support code (in the supportz80 directory). I'm getting errors similar to the following:

make[1]: Entering directory '/home/ry/FUZIX/Fuzix-Compiler-Kit/supportz80'
ccz80 -c __switchc.s
__switchc.s: 26: Q: syntax error.
__switchc.s: 31: Q: syntax error.
make[1]: *** [Makefile:65: __switchc.o] Error 1
make[1]: Leaving directory '/home/ry/FUZIX/Fuzix-Compiler-Kit/supportz80'
make: *** [Makefile:140: supportz80] Error 2

Lines 26 and 31 of __switchc.s contain conditional jr instructions which look correct to me. I tried changing them to jp but that results in the same error. Attempting to assemble other files which contain conditional jumps also give similar errors. Removing the condition makes it assemble without error.

asz80 was built by running make -f Makefile.z80 install in the as68 directory, using GCC 11.4.0 on Ubuntu 22.04.

[info] How to use? Can it be used for the TRS-80 MC-10?

Cool! I don't know of any other 6803 C compiler!

Can it be used to compile code for the TRS-80 MC-10 or Alice Matra 4k?

Could you please provide a simple example?
Even a simple hello world example on a real specific computer?
Is there a library for any 6803 computer such as the TRS-80 MC-10?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.