cc65 for the Challenger 1P

[stm]

Hi,

for a while now I've been working to add the C1P as a target for the cc65 C compiler (https://github.com/cc65/cc65). I think it's functional enough to share the current state.

Demo program:

Code: Select all

/*
 * Challenger 1P Hello World Program for cc65.
 */

#include <conio.h>

int main(void)
{
    static const char hello_world[] =
            "Hello world!\r\ncc65 for Challenger 1P";

    unsigned int i;

    clrscr();

    gotoxy(0, 0);

    cputs(hello_world);

    gotoxy(0, 4);

    for (i = 0; i < 256; i += 1) {
        if (i != '\n' && i != '\r') {
            cputc((unsigned char ) i);
        }
    }

    cputsxy(0, 14, "cputsxy\r\n");

    cprintf("cprintf '%s' %d %d\r\n", "string", (int) wherex(), (int) wherey());
    cputs("now type something:\r\n");

    while (1) {
        char c = cgetc();
        cputc(c);
    }

    return 0;
}

This can be run in Jeff Parson's awesome "C1Pjs" simulator:

http://www.pcjs.org/docs/c1pjs/

Screen shot of hello world program

hello_world_screenshot.png (42.19 KiB) Viewed 3379 times

My current approach for the C1P object file format is to convert the binary file produced by the cc65 linker into an ASCII file that can be loaded via the PROM monitor. So far I've tested the compiled programs only in the C1Pjs simulator, as the serial port on my C1P is not working yet.

The code is on GitHub in my fork of the cc65 project:

https://github.com/smuehlst/cc65

A separate repository contains the test programs:

https://github.com/smuehlst/c1pctest

The repositories should be cloned side-by-side, and after the build of the compiler it should be possible to build the test programs in the "c1ptest/src" directory. The object files to upload have the suffix ".c1p".

Documentation is rather rudimentary, and currently the build of the cc65 compiler and the runtime library is only tested on Windows.

Let me know what you think. I will step by step continue to complete the implementation of the "conio" portion of the runtime library. Currently I'm doing this for my own fun, but if there's enough interest, I will contact the cc65 guys and ask what is necessary to get that integrated into the main cc65 repository.

Best Regards
Stephan

[dave]

Hi Stephan,

That's awesome. Is the port primarily the creation of a library for the the C1P, or did you have to make changes to the compiler to avoid interference with page zero locations required by the ROM? Does CC65 use the hardware stack on page 1 for parameters and return addresses, or does it emulate a larger stack?

Best regards,

Dave

[dave]

Stephan,

Also, the srecord utility may be useful for converting a standard output format, or a binary file, to the OSI monitor load format.

Dave

[stm]

That's awesome. Is the port primarily the creation of a library for the the C1P, or did you have to make changes to the compiler to avoid interference with page zero locations required by the ROM?

On the one hand the port consists of the creation of a library for C1P-specific hardware access. At the moment the low-level functions for the so-called "conio" library are implemented. These functions implement character output to the screen, and character input.

The other aspect of the port is a C1P-specific linker configuration file, that tells the linker where to put the code, the stack and the zero-page data.

Apart from that no changes to the compiler itself were necessary.

The implementation does not care about page zero locations required by the ROM, as it does not use any ROM subroutines except the one for getting a single character from the keyboard. With the current snapshot, the memory layout is the following:

1) About 30 bytes in page zero.
2) Page 1 for the hardware stack
3) Page 2 unused
4) Executable code starts by default at 0x300
5) 1 kB parameter stack at the top of the assumed 8 kB RAM

The size of the parameter stack, the start address and total size of RAM should be configurable by linker command line parameters.

There might be opportunities for optimizing the memory layout, and I appreciate any suggestions,

Does CC65 use the hardware stack on page 1 for parameters and return addresses, or does it emulate a larger stack?

It uses the hardware stack on page 1 only for return addresses, and has a separate stack for parameters. See also the corresponding documentation in the cc65 wike: https://github.com/cc65/wiki/wiki/Param ... urn-stacks

Best regards
Stephan

[stm]

Also, the srecord utility may be useful for converting a standard output format, or a binary file, to the OSI monitor load format.

I was not aware of the srecord utility, so I wrote my own converter from the cc65 output format to a format loadable by the OSI monitor.

Where is the srecord utlity available? If that is a standard tool in the OSI community, I can get rid of my own converter.

Thanks
Stephan

[MK14HAK]

Stephan,

Great work, OSI at last at the rear of the pack of other targets!

srecord is here: http://srecord.sourceforge.net/

My recent purchase of an Atari 800XL had got me interested in this.
Is c1p.h ; c1p.cfg and libsrc c1p and src c1p folders all I need to add to my cc65 installed ?

Ive wanted to do this for the winOSI emulator. Could we borrow the fileio from its sources to support its disk images and .LOD files ?
What changes are needed for C2/C4 keyboard/video ?

... Did you fix your serial port ?

Mike

[stm]

Hello Mike,

srecord is here: http://srecord.sourceforge.net/

thanks for the pointer, I will try srecord, and if it works as expected I will throw out the self-written object file converter.

My recent purchase of an Atari 800XL had got me interested in this.
Is c1p.h ; c1p.cfg and libsrc c1p and src c1p folders all I need to add to my cc65 installed ?

I'm not sure that I understand your question. Are you asking whether you can extend your current cc65 binary installation with the mentioned files to get C1P support? That is not possible, because several cc65 binaries must be recompiled to know the "c1p" target. I'm afraid you need to build from my GitHub fork to get C1P support.

Ive wanted to do this for the winOSI emulator. Could we borrow the fileio from its sources to support its disk images and .LOD files ?

Could you explain a little bit what you want to accomplish? I don't think that it does make sense to add any source code of the emulator to the cc65 runtime library. If you want to support disk I/O in cc65, it should be implemented natively for the real machine, and the emulator should just handle it transparently.

What changes are needed for C2/C4 keyboard/video ?

Sorry, I don't have a clue about the C2/C4 machines and how they differ from the C1P. It is certainly possible to support a family of similar machines with a single cc65 target. There is support in c65 for the Atari 8-bit machines and PET/CBM machines, and there's a lot of common code for these machine families in the cc65 runtime library.

Contributions are of course welcome.

Did you fix your serial port ?

Not yet. I've planned to do give it another try at the end of the year when I have time during my vacation.

Best regards
Stephan

[MK14HAK]

Stephan,
I had tried following the custom target creation docs on cc65.org having installed cc65 and generated a hello word program that runs ok on Vice for C64.
Will compiling the library for the CIP from your sources not work? I have used a modified makesim file after reading 6502.org forums and downloading from http://sbc.rictor.org/( thank you Daryl Rictor).

Its not compiling the library without errors using cc65 to compile. I was going to try gcc.
Is this not going to work and will I have to do the re compile of cc65 with Perl etc from your githup sources as you have suggested? That's a bit scary for a C++ noob !

Could you add your compiled hello world so we can try on hardware please. Thanks and sorry for all the questions.
Mike

[MK14HAK]

Here is the make lib file and resultant output:

[*]----------------------------------------------------------------------
echo off
rem
rem This batch file will compile the SIM/C1P library files and place
rem them in proper folders. It will then cleanup all non-source files.
rem
rem Use this at your own risk. I assume no liability for its use.
rem
rem (c) Daryl Rictor 2012
rem
rem sim > c1p Mike 24.11.14
rem

@echo off
path = C:\cc65\bin;c:\cc65;c:\cc65\include;c:\cc65\asminc;%PATH%
echo C1P
cd c1p
for %%i in (*.s) do ca65 %%i
copy crt0.o ..\c1p.o >nul

echo common
cd ..\common
for %%i in (*.c) do cc65 -Osir -g -I..\..\include %%i
for %%i in (*.s) do ca65 %%i

echo conio
cd ..\conio
for %%i in (*.s) do ca65 %%i

echo dbg
cd ..\dbg
for %%i in (*.s) do ca65 %%i
pause

echo runtime
cd ..\runtime
for %%i in (*.s) do ca65 %%i
pause

echo Build library
cd ..
if exist c1p.lib del c1p.lib >nul:

ar65 a c1p.lib common\*.o
ar65 a c1p.lib runtime\*.o
ar65 a c1p.lib conio\*.o
ar65 a c1p.lib dbg\*.o
ar65 a c1p.lib c1p\crt0.o ; changed from c1p\*.o to test archive of single module.

echo Move library files
if not exist %CC65%\lib\nul mkdir %CC65%\lib
copy c1p.lib ..\lib >nul
copy c1p.o ..\lib >nul

echo Cleanup
rem del c1p\*.lst
rem del c1p\*.o
del common\*.o
del conio\*.o
del dbg\*.o
del runtime\*.o
del c1p.lib
del c1p.o
----------------------------------------------------------------------------
output:

C:\CC65\libsrc>makec1pt.bat
C:\CC65\libsrc>echo off
C1P

common

getchar.c(21): Error: Conflicting types for `getchar'
_scanf.c(32): Error: Conflicting types for `_seterrno'

conio

dbg

runtime

Build library
ar65: Error: Could not open `common\*.o': Invalid argument
ar65: Error: Could not open `runtime\*.o': Invalid argument
ar65: Error: Could not open `conio\*.o': Invalid argument
ar65: Error: Could not open `dbg\*.o': Invalid argument

Move library files
Cleanup

C:\CC65\libsrc>
----------------------------------------------------------------
I previously changed '#pragma staticlocals to static-locals in a couple of files as error obsolete usage was reported.

But how do I correct:

ar65 a c1p.lib common\*.o
ar65 a c1p.lib runtime\*.o
ar65 a c1p.lib conio\*.o
ar65 a c1p.lib dbg\*.o

the \*.o is causing problems.Too many files to add them manually.

Anyone ??

[stm]

Hello Mike,

Stephan,
I had tried following the custom target creation docs on cc65.org having installed cc65 and generated a hello word program that runs ok on Vice for C64.
Will compiling the library for the CIP from your sources not work? I have used a modified makesim file after reading 6502.org forums and downloading from http://sbc.rictor.org/( thank you Daryl Rictor).

Its not compiling the library without errors using cc65 to compile. I was going to try gcc.
Is this not going to work and will I have to do the re compile of cc65 with Perl etc from your githup sources as you have suggested? That's a bit scary for a C++ noob !

Could you add your compiled hello world so we can try on hardware please. Thanks and sorry for all the questions.
Mike

the cc65 compiler with my modifications and the runtime library for the "c1p" target should build out-of-the-box, no special build scripts are necessary. In the next post I will provide a walk-through for Windows and Unix/Linux.

You can download the compiled hello.c1p program here:

https://www.dropbox.com/s/nh85n5sp7bvj6 ... o.c1p?dl=0

The forum software didn't let me upload the file with a .c1p or .txt extension as attachment, and when I tried to upload the file as a .jpg file it complained about bad dimensions...

I'm very interested whether this can be executed on a real machine after upload via the serial port.

Best regards
Stephan