cc65 for the Challenger 1P

[stm]

Mike,

Here is the make lib file and resultant output:

...

Anyone ??

no special build scripts should be necessary.

This is a walk-through how to build the compiler, the run time library and finally the hello world test program on Windows:

Requirements:

- Microsoft Visual Studio Community Edition 2013 (includes msbuild)
- GNU make for Windows as recommended in the cc65 Wiki: http://gnuwin32.sourceforge.net/packages/make.htm

I used Microsoft Visual Studio Community Edition 2013 because it comes with msbuild for building from the command line. It might be possible to use Visual Studio Express 2013 as well and build the compiler binaries in the IDE.

The following protocol shows the steps:

1) Clone cc65.git repository
2) Clone c1pctest.git repository
3) Use msbuild to build the compiler binaries in cc65\src with Visual Studio
4) Use GNU make to compile the "c1p" runtime library with the cc65 compiler
5) Build the hello world test program "hello,c1p" in the c1pctest\src directory

Code: Select all

C:\Users\stm\Documents\GIT> git clone https://github.com/smuehlst/cc65.git
Cloning into 'cc65'...
remote: Counting objects: 61233, done.
remote: Compressing objects: 100% (22902/22902), done.
remote: Total 61233 (delta 37571), reused 61180 (delta 37537)
Receiving objects: 100% (61233/61233), 37.36 MiB | 890.00 KiB/s, done.
Resolving deltas: 100% (37571/37571), done.
Checking connectivity... done.
Checking out files: 100% (2457/2457), done.
C:\Users\stm\Documents\GIT> git clone https://github.com/smuehlst/c1pctest.git
Cloning into 'c1pctest'...
remote: Counting objects: 69, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 69 (delta 6), reused 0 (delta 0)
Unpacking objects: 100% (69/69), done.
Checking connectivity... done.
C:\Users\stm\Documents\GIT> cd cc65\src
C:\Users\stm\Documents\GIT\cc65\src [c1p]> msbuild cc65.sln
Microsoft (R)-Buildmodul, Version 12.0.31101.0
[Microsoft .NET Framework, Version 4.0.30319.18444]
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.
<... lots of build output ... >
Der Buildvorgang wurde erfolgreich ausgeführt.
    0 Warnung(en)
    0 Fehler

Verstrichene Zeit 00:01:28.36
C:\Users\stm\Documents\GIT\cc65\src [c1p]> cd ..\libsrc
C:\Users\stm\Documents\GIT\cc65\libsrc [c1p]> make TARGETS=c1p
c1p - common/_afailed.c
c1p - conio/_cursor.s
c1p - common/_cwd.s
c1p - common/_environ.s
<... lots of build output ... >
C:\Users\stm\Documents\GIT\cc65\libsrc [c1p]> cd ..\..\c1pctest\src
C:\Users\stm\Documents\GIT\c1pctest\src [master +0 ~4 -0]> make
../../cc65/bin/cl65 --start-addr 0x300 --mapfile hello.map -vm -t c1p hello.c
../../cc65/bin/c1p65 -S 0x300 hello
../../cc65/bin/cl65 --start-addr 0x300 --mapfile minimal.map -vm -t c1p minimal.c
../../cc65/bin/c1p65 -S 0x300 minimal

The same walk-through on Linux (it's a little bit easier because the compiler and the runtime can be built with a single make invocation from the top-level cc65 directory):

Code: Select all

[stm@centos ~]$ git clone https://github.com/smuehlst/cc65.git
Initialized empty Git repository in /home/stm/cc65/.git/
remote: Counting objects: 61233, done.
remote: Compressing objects: 100% (22902/22902), done.
remote: Total 61233 (delta 37571), reused 61180 (delta 37537)
Receiving objects: 100% (61233/61233), 37.36 MiB | 195 KiB/s, done.
Resolving deltas: 100% (37571/37571), done.
[stm@centos ~]$ git clone https://github.com/smuehlst/c1pctest.git
Initialized empty Git repository in /home/stm/c1pctest/.git/
remote: Counting objects: 69, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 69 (delta 6), reused 0 (delta 0)
Unpacking objects: 100% (69/69), done.
[stm@centos ~]$ cd cc65
[stm@centos cc65]$ make TARGETS=c1p
ar65/add.c
ar65/del.c
ar65/error.c
ar65/exports.c
<... lots of build output ...>
[stm@centos cc65]$ cd ../c1pctest/src
[stm@centos src]$ make
../../cc65/bin/cl65 --start-addr 0x300 --mapfile hello.map -vm -t c1p hello.c
../../cc65/bin/c1p65 -S 0x300 hello
../../cc65/bin/cl65 --start-addr 0x300 --mapfile minimal.map -vm -t c1p minimal.c
../../cc65/bin/c1p65 -S 0x300 minimal

After these steps you should have a "hello.c1p" file in c1ptest/src.

Best regards
Stephan

[MK14HAK]

Thanks for the walk through Stephan, I'll try that on another PC.
Meantime I have sorted my c1p.lib file now 750Kb. Just one error when I link now.

https://www.dropbox.com/s/ody16n7owe1z9 ... p.jpg?dl=0

https://www.dropbox.com/s/nc41c09dyj5ke ... I.bmp?dl=0

osilod in WinOSI tools is another easy bin to OSI load format converter.

C1P has inverted keyboard compared to C2/C4 which also have 64*32 video,colour, Acia @ $FC00

Mike

[stm]

https://www.dropbox.com/s/ody16n7owe1z9 ... p.jpg?dl=0
https://www.dropbox.com/s/nc41c09dyj5ke ... I.bmp?dl=0

So according to the screen shots the hello world program works on a real C1P and inside the WinOSI emulator as well, cool!

I will change the object converter to use CR instead of LF as line terminator. Hopefully the object files will still load into the WinOSI and C1Pjs emulators.

I decided to leave my own object converter in place as long as a merge into the main cc65 repository is not on the horizon. This is one dependency less to get started in the meantime.

Best regards
Stephan

[stm]

The c1p target of the cc65 compiler is now in a state where it is usable to create meaningful programs that write to the screen and read from the keyboard of the Challenger 1P.

8 kB RAM are pretty tight, and depending on what library functions are used the programs can quickly be too big. So having a RAM expansion definitely helps

How do the bigger OSI machines differ architecturally from the Challenger 1P? I'm asking because I'd like to generalize the implementation so it can be used ideally with all the OSI machines.

I have now established contact with the cc65 maintainer, and he is positive about adding the c1p target to the main cc65 repository.

[stm]

"osic1p" target has landed in the main cc65 repository

It was high time that the OSI machines get a decent C compiler...

I just posted a message to the cc65 mailing list that my contributions for adding a new target for the OSI C1P have been accepted into the main cc65 repository on GitHub. I'm quoting my message here:

I am glad to announce that Oliver has accepted my contribution for adding a target for the Ohio Scientific (OSI) Challenger 1P machine to cc65. Thank you, Oliver!

The new target is called "osic1p". The name was chosen to allow for additional targets with the "osi" prefix for other OSI machines later.

OSI-specific topics are covered in the osi.html web page:

http://cc65.github.io/doc/osi.html

An OSI-specific section was added to "cc65 Compiler Intro" web page:

http://cc65.github.io/doc/intro.html#ss6.6

This is work in progress. Currently there is no support for stdio functions, and the conio implementation lacks a kbhit() implementation. Other limitations that I'm not yet aware of may apply.

I have a small GitHub repository where I maintain some sample programs for the osic1p target. It is also a good source for seeing how to set up a Makefile for the target:

https://github.com/smuehlst/c1pctest

The main test environment for executables is the 32-kB-RAM machine of Jeff Parson's C1Pjs emulator:

http://www.pcjs.org/devices/c1p/machine/32kb/

I also have reports that the executables run successfully in the WinOSI emulator:

http://osi.marks-lab.com/

And of course I have run executables on my real 8 kB RAM Challenger 1P at home, albeit only small ones...

I hope to complete the implementation of the cc65 runtime library over time. Of course any comments and contributions are welcome.

Best regards
Stephan

[stm]

A quick update on the progress of cc65 for the Challenger 1P since my last post. Several changes made it into the main cc65 repository (https://github.com/cc65/cc65) on GitHub.

• The conio library (http://cc65.github.io/doc/funcref.html#ss2.14) learned scrolling and got a kbhit implementation (http://cc65.github.io/doc/funcref.html#kbhit). The conio library is now functionally complete. Thanks to Jeff Tranter for the initial implementation of the scrolling feature.
• A new hybrid object file format (http://cc65.github.io/doc/osi.html#s3) that includes a boot loader was implemented. The object file format consists of a small boot loader that is loaded and executed via the 65V PROM monitor. Once the boot loader is executed, it loads the rest of the program directly in binary format, which makes programs smaller and loading much faster. Thanks to Greg King for the implementation of the hybrid object file format.
• The Python script (https://github.com/smuehlst/c1pctest/bl ... ode_bin.py) for creating Kansas City Standard WAV files from executables for uploading over the cassette port was modified to encode binary files, and the inclusion of unnecessary NULL characters was removed. Together with the new boot loader this drastically speeds up loading of compiled C programs over the cassette port. The time for loading the compiled Hello World program (https://github.com/smuehlst/c1pctest/bl ... rc/hello.c) over the cassette port went down from approx. 24 minutes to approx. 2 minutes.
• A bug concerning the initialization of the stack pointer was fixed. Thanks to Greg King for spotting this.
• Support for different screen layouts (http://cc65.github.io/doc/osi.html#s8) was added. Apart from the default 24x24 mode for the Challenger 1P there's support for the 32x28 mode of the Briel Superboard ///.

Best regards
Stephan