Starting coding for Amstrad

[ronaldo]

@kilon: Well, you are right when you say that something that builds on Linux does not have to easily build on MacOs too. They are different, of course, but should be easier than building on Windows, at least.

Even using Windows, I would recommend using cpc-dev-tool-chain + Cygwin. With cpc-dev-tool-chain, creating a new proyect and building DSKs and CDTs is as easy as running "make dsk" or "make cdt". You do not have to care about setting up your tools: the framework does for you. And no, you do not have to mess up with makefiles: everything comes ready out-of-the-box. It even includes cpcrslib library for graphics and sound. It is an all-in-one .

However, that is only my advice. If you prefer other set-up, I will be glad to know your reasons and point of view to learn from you .

[kilon]

@kilon: Well, you are right when you say that something that builds on Linux does not have to easily build on MacOs too. They are different, of course, but should be easier than building on Windows, at least.

Even using Windows, I would recommend using cpc-dev-tool-chain + Cygwin. With cpc-dev-tool-chain, creating a new proyect and building DSKs and CDTs is as easy as running "make dsk" or "make cdt". You do not have to care about setting up your tools: the framework does for you. And no, you do not have to mess up with makefiles: everything comes ready out-of-the-box. It even includes cpcrslib library for graphics and sound. It is an all-in-one .

However, that is only my advice. If you prefer other set-up, I will be glad to know your reasons and point of view to learn from you .

Ok then its time for me to sit down my ass and learn how to build on MacOS . I will do both that you recommended. Install Cygwin on windows and also speak with the cpc-tools author to get it build in MacOS. Learning to build afterall will help me in many more ways than just developing for CPC. I have to say I am really impressed with the level and amount of tools developed for CPC, though one would argue its not just for CPC but for the entire z80 range , but still quite impressive.

Also if I can contribute to make MacOS development  a tiny bit easier for other devs it would be great.

Don't worry I really trust your opinions and advices and have zero issues doing the hard work and learning. No pain no gain

[AMSDOS]

CPC Basic 3 - as the name suggests can take a Locomotive BASIC program and convert it into Assembly, Z88DK or Binary, though isn't 100% Locomotive BASIC compatible, the big drawback would be lack of Floating Numbers.

Actually my advise there is pretty flawed as the website link in the CPC BASIC 3 thread reveals. So Z88DK should be ccz80 and Floating Numbers are allowed, though function through RSXes, unsure if it's the Negative Numbers that aren't allowed, unimportant I guess cause it's all on the website.

[kilon]

Actually my advise there is pretty flawed as the website link in the CPC BASIC 3 thread reveals. So Z88DK should be ccz80 and Floating Numbers are allowed, though function through RSXes, unsure if it's the Negative Numbers that aren't allowed, unimportant I guess cause it's all on the website.

So I have forked sdc-dev-tools and opened an issue so the author is informed about my intention to help him build for macos

CPC BASIC seems from what I read from the website not to support negative numbers. It also not compatible with Locomotive Basic, there are several things that are not same or changed from what I read from the website.

But I will still take a look at it because its written on .NET so its should in theory work on MacOS via MONO. Also the idea of taking Basic code and turning it to Assembly is a good idea for learning Assembly.

I see we share a common love for Turbo Pascal, you write CPC code I have used DELPHI for several years as my main development tool

[trabitboy]

What it means "to be able to curse them" ?

coming from a high level languages background, the 2 biggest culture shock were:
- preserving registers on method calls ( scope doesn't exist on hardware level, pushing poping or storing in memory if speed is not an issue )
- instead of using collections and arrays, reading a memory area as a list using HL and IX


If you come back to winape at some point I can cook some smallish examples, let me know 

[kilon]

coming from a high level languages background, the 2 biggest culture shock were:
- preserving registers on method calls ( scope doesn't exist on hardware level, pushing poping or storing in memory if speed is not an issue )
- instead of using collections and arrays, reading a memory area as a list using HL and IX


If you come back to winape at some point I can cook some smallish examples, let me know 

I have worked with Assembly back in my DOS days, of course back then things were way simpler than are for x86_64 architecture nowdays. I did some very simple apps, the usual suspect of text ouput and I learned from this book



Beautifully simple and well written book even for those with no experience with coding.

So I have some basic idea that is fading away because the last time I touched Assembly was back in 1996.

Winape is still inside my mac, I have no issues using it. I also just found out about JavaCPC that runs on MacOSX and it also like WinApe contain a debugger/(dis)Assembler. So I dont think I have any problems following your examples.

If anything it appears I have too many options.

[trabitboy]

Small example on iterating on level data ( map data ),
well commented ( I think ), written for a beginning friend last spring.
assembles in winape, call &4000

edit:
fw txt example, operations you will need for your text adventure, demonstrated .

[kilon]

Small example on iterating on level data ( map data ),
well commented ( I think ), written for a beginning friend last spring.
assembles in winape, call &4000

edit:
fw txt example, operations you will need for your text adventure, demonstrated .

lol I was typing questions and one by one the more I read the code they disappeared.

Only question remaining is what is in &BB5A ? I assume some sort of firmware/BIOS function

[trabitboy]

yes there are firmware functions available if you don't disable the system

CONOUT EQU &BB5A  ; outputs char at current row, col
TXT_CLR_WDW EQU &BB6C ; clears screen
TXT_SET_ROW EQU &BB72
TXT_SET_COL EQU &BB6F


there is a ref online, if you search "cpc firmware", but having them in the correct order in an example is nice

[kilon]

yes there are firmware functions available if you don't disable the system

CONOUT EQU &BB5A  ; outputs char at current row, col
TXT_CLR_WDW EQU &BB6C ; clears screen
TXT_SET_ROW EQU &BB72
TXT_SET_COL EQU &BB6F


there is a ref online, if you search "cpc firmware", but having them in the correct order in an example is nice

wow this is way easier than I expected. 

Obviously I am far from an expert but kinda amazed I can read assembly in just a few days 

Thank you very much for those examples. Is it possible to put that code inside the WinApe debugger and turn it into a dsk image ? (I am away from my mac and winape at the moment )

[trabitboy]

last example for today, with HL and IX to pretend we have a list like in a "high level" language
( this is getting addictive    )


DISCLAIMER: I'm a noob and this is simple , not optimized

[trabitboy]

Thank you very much for those examples. Is it possible to put that code inside the WinApe debugger and turn it into a dsk image ? (I am away from my mac and winape at the moment )

I don't think is useful, keep them as .asm
The assembler of winape is on the windows side , once assembled the program is put in the emulator's memory .


I have a screen cast demonstrating basic winape dev and debugging for total beginners, but sadly it is not anonymised and I don't know when I will have a pc capable of screencast AND with a showable desktop

[kilon]

I don't think is useful, keep them as .asm
The assembler of winape is on the windows side , once assembled the program is put in the emulator's memory .


I have a screen cast demonstrating basic winape dev and debugging for total beginners, but sadly it is not anonymised and I don't know when I will have a pc capable of screencast AND with a showable desktop

Roger will do.

Your new example is very helpful too. I think in a month or so will be ready to start my game. I will spend this month doing small tests like the ones you provided and of course continue reading documentation.

I dont understand what you mean by anonymised screencasts. I do mine using macos quicktime and upload them to youtube, its as easy as pressing a button. But you already helped me a lot

[trabitboy]

I dont understand what you mean by anonymised screencasts. I do mine using macos quicktime and upload them to youtube, its as easy as pressing a button. But you already helped me a lot

#ahem# only my work pc is powerful enough/ has screencast software installed, but there is company info on the desktop bg which I can't remove


one tip:
if you don't want to lose steam,
you should specify a very simple game idea, and realise it, start coding;
at first in text ; if you don't have a focus it might get tiring pretty fast


what about this text adventure idea of yours ?
why not at first implement the logic to display different rooms based on key/joystick presses  ?
it is simple enough and quite motivating

[kilon]

#ahem# only my work pc is powerful enough/ has screencast software installed, but there is company info on the desktop bg which I can't remove


one tip:
if you don't want to lose steam,
you should specify a very simple game idea, and realise it, start coding;
at first in text ; if you don't have a focus it might get tiring pretty fast


what about this text adventure idea of yours ?
why not at first implement the logic to display different rooms based on key/joystick presses  ?
it is simple enough and quite motivating

Actually I love learning about the Z80 , Assembly and CPC inner workings. I can't just jump start coding a game without some basic understanding.

As I said, I have already an idea for a very basic game with graphics. I would like to try a top down adventure board game. One map, one screen , simple commands.

something like this



card based and turn based. Then I could expand future version to more maps, more type of monsters , more player stats etc

[trabitboy]

that is a big map for cpc screen resolution

[arnoldemu]

Actually I love learning about the Z80 , Assembly and CPC inner workings. I can't just jump start coding a game without some basic understanding.

As I said, I have already an idea for a very basic game with graphics. I would like to try a top down adventure board game. One map, one screen , simple commands.

something like this


card based and turn based. Then I could expand future version to more maps, more type of monsters , more player stats etc

good plan

[kilon]

that is a big map for cpc screen resolution

I am technomage , son of Hephaestus himself . All I have to do is use my coding elemental magic of scroll up , down, left and right  

We dont want the hero to kill all monster with one sweep because they are crammed in small space. The Monster Rights Association may take me to the court for mistreating monsters

[AMSDOS]

I see we share a common love for Turbo Pascal, you write CPC code I have used DELPHI for several years as my main development tool

Now and again I'll use it, though because I'm using the Firmware most of the time, I'm using Hisoft Pascal 4T instead.

[kilon]

Now and again I'll use it, though because I'm using the Firmware most of the time, I'm using Hisoft Pascal 4T instead.

Ah nice, then I will add it to my lists of potential languages. For now I will take the route most cpc developers take of using SDCC to combine C with Assembly. Looks like the easiest route for me.

[Shining]

So if you've any question using this way feel free to ask coz the game I currently write uses exactly this method. But be aware that you cannot compare sdcc with "normal" c-development. I had many problems with it in the past.
Yesterday for example I spend a long time to get my game back running again and the problem was completely sdcc related (because my code had gotten too big).

[kilon]

So if you've any question using this way feel free to ask coz the game I currently write uses exactly this method. But be aware that you cannot compare sdcc with "normal" c-development. I had many problems with it in the past.
Yesterday for example I spend a long time to get my game back running again and the problem was completely sdcc related (because my code had gotten too big).

yes I am aware that there are limits to what you can do with C for CPC , but don't know exactly what those limits are. But I don't care about advanced C features, just simple stuff like arrays, pointers etc. Writting the code in pure Z80 assembly is also an option but why waste my time like this . In any case my focus right now is learning Z80 assembly and will very soon start coding in it.

I really dont care about producing the fastest code, or learning deep internals of CPC and its optimisations. I want to learn fast and start creating my game keeping things as simple as possible.

[AMSDOS]

Ah nice, then I will add it to my lists of potential languages. For now I will take the route most cpc developers take of using SDCC to combine C with Assembly. Looks like the easiest route for me.

Indeed the more serious developer will use SDCC or other PC Program to compile something which looks more like a Commercial Quality Game.
A PC Based compiler should also allow you more memory for your program, early versions of TP & HP throw in an entire Library of routines that your program may or may not use, using up around 6-8Kb due to the nature of Compiled languages. I believe Borland were able to address this when Turbo Pascal went from a CP/M/PC-DOS/MS-DOS based Compiled Language to a DOS only and introduced a series of Unit Files (e.g. CRT, GRAPH, MSDOS) that could select which portion to use for your program, hence smaller generated (EXE) files.


Selecting an Amstrad Programming Language also involves which platform, some languages have versions for both platforms (CP/M & Basic), so can produce code for both environments, though things like TP strictly write programs for CP/M. CP/M is available in different versions for the Amstrad too, which would make your program more complicated should it need to be able to run in all versions. CP/M people don't generally like to see System Specific stuff being written, but I reckon the Amstrad PCW range of computers which were strictly a CP/M Based might of broke those rules and have heaps of System Specific stuff available for it.


Unsure if a ROM based Compiler Program has any advantages over a Tape/Disc based loaded into memory one. BCPL is available as Disk or ROM, I recently looked at this language which generates fairly smaller code, though being a Systems Based Language, it doesn't require any Floating Decimal Based Numbers, though Arnor has put a set of Programs written in BCPL that shows it doesn't have to be limited to systems programming.

[kilon]

Indeed the more serious developer will use SDCC or other PC Program to compile something which looks more like a Commercial Quality Game.
A PC Based compiler should also allow you more memory for your program, early versions of TP & HP throw in an entire Library of routines that your program may or may not use, using up around 6-8Kb due to the nature of Compiled languages. I believe Borland were able to address this when Turbo Pascal went from a CP/M/PC-DOS/MS-DOS based Compiled Language to a DOS only and introduced a series of Unit Files (e.g. CRT, GRAPH, MSDOS) that could select which portion to use for your program, hence smaller generated (EXE) files.


Selecting an Amstrad Programming Language also involves which platform, some languages have versions for both platforms (CP/M & Basic), so can produce code for both environments, though things like TP strictly write programs for CP/M. CP/M is available in different versions for the Amstrad too, which would make your program more complicated should it need to be able to run in all versions. CP/M people don't generally like to see System Specific stuff being written, but I reckon the Amstrad PCW range of computers which were strictly a CP/M Based might of broke those rules and have heaps of System Specific stuff available for it.


Unsure if a ROM based Compiler Program has any advantages over a Tape/Disc based loaded into memory one. BCPL is available as Disk or ROM, I recently looked at this language which generates fairly smaller code, though being a Systems Based Language, it doesn't require any Floating Decimal Based Numbers, though Arnor has put a set of Programs written in BCPL that shows it doesn't have to be limited to systems programming.

Commercial quality games is definitely NOT my goal. This will be my very first game ever. Most likely it will suck in many different ways. At least I hope it will suck in a good fun way and not a complete waste of time for me and the people who will play it . 

So I would like to use whatever makes my life easier and runs out of the box for my users without any needs for additional software or setup. My target is CPC 6128 with color monitor and I will work only with emulators. I prefer coding using emacs.  I prefer also using something that is well tested by many people and so far SDCC seems by far the best candidate.

[AMSDOS]

Commercial quality games is definitely NOT my goal. This will be my very first game ever. Most likely it will suck in many different ways. At least I hope it will suck in a good fun way and not a complete waste of time for me and the people who will play it .

That's perfectly fine, I was only draw a comparison between Language and end result.   

So I would like to use whatever makes my life easier and runs out of the box for my users without any needs for additional software or setup. My target is CPC 6128 with color monitor and I will work only with emulators. I prefer coding using emacs.  I prefer also using something that is well tested by many people and so far SDCC seems by far the best candidate.

Well if you do produce something, there will be people testing it out on Real Hardware. We've had issues in the past where something has been produced that works fine on all the Emulators but crashes on the Real Hardware.