Benefits of high profile programming: C coding for CPC with decoupling in mind

[cpcitor]

Hello,

This is long, so to make a long story short: we can program and cooperate more easily and quickly after learning and practicing some patterns. We can also have our cross-development productions run as native PC apps which makes their development easier and quicker.

What context is this for ?

• C-based projects with cross-development. That means code that has a non-trivial algorithmic part. Demos with nothing but cycle-accurate CRTC effects are off-topic.
• Programmers that can (or want to learn to) program for their native computer.
• Programmers that are familiar (or want to invest themselves) with best practices and tools, especially those standard in open-source ecosystem.

Introduction: fragmented development ecosystem and lost opportunities.

There are a few topic regarding C development. Easiest way to find them in these forums are looking for keywords SDCC and z88dk.

Yet C development for CPC can be done with varying tools and methods, with no emerged standard (various assemblers, conventions, transfer tools). As a result, most people working on a C project make up their own development setup.

While some share it, for example Octoate's News - SDCC Code::Blocks template v1.2 , it's often tied to a particular development environment: operating system, IDE, tools and it gets broken with time (e.g. SDCC2Pasmo no longer available SDCC Code::Blocks template v1.2 | The Amstrad CPC news portal ).

This is understandable: it's much easier to build a project on a specific environment than to recreate a project logic.

At the end of the day, people using Windows, Linux and Mac OS can't easily cooperate on a project.  Getting started on any project is very costly, unless you happen to use exactly the same environment as the original author.  Productions for our beloved platform are not as good as they could be.

Introduction: fragmented execution environments and lost time and convenience.

When properly coding in C (or any higher level language), most of the source is not actually dependent on environment details. A sort algorithm does not depend on CPU details or the way the OS handle memory.

Yet a quick-and-dirty approach yields code that can only run on the target or emulator, with all their time-consuming constraints. That's a nice start for a proof-of-concept but a handicap after.

At each source code line level, speed and memory pressure make useful to specify register widths in code instead of saying "int" everywhere, but that's no real reason to stay in the dirt.

Now what good news ?

You can write code that will run in emulator but also in native environment with all debugging comfort. Well, that's comfort if you are comfortable with a programming environment for that other platform.

Concretely, that means writing a game that will run on the CPC, but also as a native application (with different, native, graphics, and probably some remains of a CPC-like look-and-feel).

How ?

The key is following some programming patterns that not only make things possible but allow to write and maintain code more easily.

• Learn to, and actually do write well-structured code. It's a must, or all this topic is above your head and will only cause headache, just don't read further.
• Write not optimal but correct code first, optimize only what's needed after. Details in Premature Optimization .
• Create a directory tree dedicated to algorithm code. That's all code that can be written without any reference to platform details or compiler.
• There will be code that can only be expressed in term of each particular platform. For that, create a "platform" directory with a subtree for each target platform. You will have at least two platforms: your native computer environment (probably through simplifying interfaces like SDL), and your target (read: CPC). Same for resources: a CPC graphics will be stored in CPC format, while a native graphics may be PNG.
• To provide the expected benefits, all this actually needs to be compiled. Long-lived embedded projects fully separate not only platform-independent vs. platform-specific code, but also pure code vs. pure build tools/configuration. Concretely that means another directory with a subtree per build/compiler environment (SDCC vs. z88dk, or even Makefile vs. CMake).

That's an overall goal.

If you are anxious about performance while reading above, think twice. Even for the intensive applications I'm thinking of (flat-shading 3D) you really only need to optimize functions at the very bottom of loops. After that, if cost of calling some small inner functions remains a proven problem, a good compiler can inline calls and if really needed you can do a little ifdef magic to help (not too much, though ;-).

Towards this goal, I've looked at a few existing projects that I've documented on the wiki Programming:Cross Development - CPCWiki .

As none of them seemed to follow that path, I've started a while ago an embryo that does.

So far, it requires a minimal Linux-like environment (git, make, native gcc), fetches automatically the required dependencies and compiles a "hello world" source into a DSK that actually works.  It uses z88dk because something went wrong with SDCC at the time I tried. It uses iDSK though cpcfs might be a better choice.

It does not have all benefits aimed above, but already:

• Fully automated build: get source, trigger build, get ready-to-use image. No manual step.
• Not tied to any graphical environment, which basically means that any flexible enough development environment should be able to work with it. First implemented interface is the ubiquitous command-line :-) (that should include, for Windows users, cygwin/msys).
• Open to improvement. Other outputs (snapshot, etc), other compilers, SDL platform, etc.

I just updated the environment today after observing that CVS version of z88dk was broken for weeks. It now fetches the tested z88dk 1.10.1.

Details on cpcitor/cpc-dev-tool-chain · GitHub

In a shell, do

Code Select Expand

git clone git@github.com:cpcitor/cpc-dev-tool-chain.git
cd cpc-dev-tool-chain
make
And you have the DSK in hello_world_using_z88dk/a.dsk

Feedback/like welcome.

[AMSDOS]

I'm not quite sure what you're implying here, is someone breaking the laws of C Coding?

[MaV]

I'm not quite sure what you're implying here, is someone breaking the laws of C Coding?

I think he's trying to establish a complete development package (toolchain?) that everybody can agree upon. The goal seems to be to standardise the way we do things in order to exchange sources/data etc much more easily.
At the moment everybody has his own approach to develop on the CPC.

[andycadley]

• I can't see the point of trying to support "your native platform". Any library of use on the PC is liable to be massively overbloated for the CPC and most useful libraries for the CPC aren't going to be PC friendly. Is anybody really desperate to create software that needs to run on both?
• 
  Anything that requires Windows users to install Cygwin is basically dead in the water. It's a complete mess and utterly unusable. Expecting the majority to install tools to fudge their OS to work like another one is not the way to standardise a toolset.

[cpcitor]

Sharing methods is like saying "building a road benefits everyone". No "rule of C" is broken here.

[cpcitor]

Hello,

Thank you for clarifying what the approach is not.

I can't see the point of trying to support "your native platform". Any library of use on the PC is liable to be massively overbloated for the CPC and most useful libraries for the CPC aren't going to be PC friendly. Is anybody really desperate to create software that needs to run on both?

You're right. It's not about running on the CPC some software written for modern computers. Neither running on a PC an existing platform-dedicated library written for the CPC.

The point is clearer when you think a program in a structured way. It's much clearer to people used to write portable code and those who write both "normal" and embedded code for a living.

The validity "of writing for small and running also for big" pretty much depends on the program being written. As written, "Demos with nothing but cycle-accurate CRTC effects are off-topic.". There would be no point.

I'm aiming at navigating in a 3D maze real-time on a CPC, and if possible full-screen.

Writing all in assembly would be crazy.

Such a project requires an algorithm written in a C-level language, for example C ;-).

Debugging such C code on a CPC would be a nightmare. But good code is well structured so it's easy to port. With a lightweight SDL-based wrapper it can be run/debugged very quickly on the modern platform.

Do on each platform what's best on that platform.That's the point and it's only as thick as the amount of real logic in the program being written.

Having a portable/structured software mindset allows to achieve much more than seem possible with a raw mindset.

Anything that requires Windows users to install Cygwin is basically dead in the water. It's a complete mess and utterly unusable. Expecting the majority to install tools to fudge their OS to work like another one is

Again, you're right. The majority has nothing to do with developer tools.

Yes, the full Cygwin collection is an ugly and slow hack to just to have open-source tools work on Windows. Yet it can install, update and share an environment and project evolution at will much faster than doing it by hand every time (the latter meaning in practice doing it once and never again, so much for sharing).

not the way to standardise a toolset.

I should make separate threads for the approach and for the toolchain, because the approach is about practices that are applicable whatever the toolchain, while the toolchain starts simple and can be used in various ways without any regard to the practices (for example, a full assembly project).

Regards,

[AMSDOS]

I think he's trying to establish a complete development package (toolchain?) that everybody can agree upon. The goal seems to be to standardise the way we do things in order to exchange sources/data etc much more easily.
At the moment everybody has his own approach to develop on the CPC.

Sounds like a good idea, though I'm still wondering what implementations of C will this be for, I'm guessing SDCC is out if PC incarnations are excluded, which just leaves the CPC based C Compilers. 

[Sykobee (Briggsy)]

Debugging such C code on a CPC would be a nightmare. But good code is well structured so it's easy to port. With a lightweight SDL-based wrapper it can be run/debugged very quickly on the modern platform.

For algorithms it's fine - although surely at some point you'll just implement the algorithm and debug on the PC, and then port into the CPC project. The porting will surely introduce bugs unless you are writing C on the PC as if you are writing C for the CPC - lots of pre-assigned memory buffers rather than malloc, etc.

But for graphical stuff - e.g., your 3D maze, you will need more than just SDL, you'll need a CRTC + Gate Array bit of code that renders the output of the algorithm (written in CPC format to a buffer simulating CPC memory) to the SDL canvas. This is a good portion of a CPC emulator's code! You might be better off integrating Pasmo, SDCC and other dev tools into WinApe, etc. "WinApeIDE", "ArnoldIDE"...

I presume that you'll wrap Z80 inline assembler in IFDEFs and provide a plain C implementation of the algorithmic intent for the PC side of things?

[cpcitor]

I think he's trying to establish a complete development package (toolchain?) that everybody can agree upon. The goal seems to be to standardise the way we do things in order to exchange sources/data etc much more easily.
At the moment everybody has his own approach to develop on the CPC.

Thank you for your summary. I probably talked about too many things and that's confusing for readers.
Don't imagine something too ambitious, though. Perhaps I'll try to reword in separated topics.

[cpcitor]

• Anything that requires Windows users to install Cygwin is basically dead in the water. It's a complete mess and utterly unusable. Expecting the majority to install tools to fudge their OS to work like another one is not the way to standardise a toolset.

Hi andycadley,

The reasons for the two threads I opened is because of a project that I wanted to submit for this year ROM competition but had no time for it up to now.

• Regarding this thread, I explain patterns that I think are valuable (for some projects including my current) because I try to give back to the community for what it has gathered.
• Regarding the toolchain, the primary motivation for writing it is for the same project. I believe there's value for everyone if I share these tools and patterns along the way. At the beginning there's little benefit but it might grow.

So I try follow the open-source pattern Release early, release often.

In this approach it's understandable that I made no effort about Windows and just used the tools (GNU environment including make, gcc, patch etc) that are convenient and traditional not only among professional embedded developers but many developers and projects. I just mentioned cygwin as a quick and dirty solution because I know it should work with Windows.

So for now it works cleanly on my primary development platform (Linux) and probably with the ugly cygwin hack on Windows (I'll know that for sure when someone tests).

Users can join and contribute (actually people writing in this thread and the other have already started contributing -- with their ideas and suggestions, not yet success/problem reports or code).

When a Windows developer contributes an easy way and automated way to install SDCC, iDSK, z88dk, there will be less reasons (ideally none) to suggest installing cygwin.

Cheers,

[Bryce]

I like your new Avatar CPCitor. On the one hand it's quite positive, but on the other hand it's seems rather negative[NB]Capacitor joke. Probably went over most peoples heads.[/NB]

Bryce.

[ssg]

I don't believe in "one workflow", or a single standard development process.


But I certainly think that there is a need for "extract and start building" kind of C environment targeted at CPC platform. ROMs, headers (cpc.h) in place, ready to start experimenting, right away. That's certainly a right step forward, good job!