Hey guys , you miss a sticky for getting started.
I got my Amstrad CPC 6128 as first computer in 1988 and I coded Basic on it. Decades later I have passed through most popular languages to settle in with Python and Pharo as my favorite languages.
However I always found Assembly fun to code in back in my DOS days. Things were so simpler back then. So I am wondering how I can code Assembly using Arnold (I killed my CPC long time ago to motivate my father to get me a new computer :D ) .
I would not mind also coding in C.
So any pointers ?
I only care doing super simple stuff, I was thinking a text game with some graphics. I make 3d graphics with Blender so I can make a few images.
Have you browsed the wiki instead of just the Forum: CPCWiki - THE Amstrad CPC encyclopedia! (http://www.cpcwiki.eu/index.php/Main_Page)
Bryce.
Doh
Guilty as charged ;D . No idea why it did not cross my mind to look at the wiki.Thank you .
These 2 threads below are C related and maybe of interest to you:
"Programming in C on the CPC (http://www.cpcwiki.eu/forum/programming/programming-in-c-on-the-cpc/)" - has load of Links in it
"cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC. (http://www.cpcwiki.eu/forum/programming/cpc-dev-tool-chain-a-portable-toolchain-for-casm-development-targetting-cpc/)" - may have something in it of use.
I rely more on the available Language Compilers the CPC had with the exception of CPC BASIC 3 or Winape Assembler that I occasionally use. Using the newer languages which function on PCs would allow you to generate more optimised code over the old CPC compilers which rely on a whole library of routines (ones that you use & may not necessarily use), to allow your program to function.
CPC Basic 3 - as the name suggests can take a Locomotive BASIC program and convert it into Assembly, Z88DK (http://www.cpcwiki.eu/index.php/Z88DK) or Binary, though isn't 100% Locomotive BASIC compatible, the big drawback would be lack of Floating Numbers.
Quote from: AMSDOS on 09:38, 09 March 15
These 2 threads below are C related and maybe of interest to you:
"Programming in C on the CPC (http://www.cpcwiki.eu/forum/programming/programming-in-c-on-the-cpc/)" - has load of Links in it
"cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC. (http://www.cpcwiki.eu/forum/programming/cpc-dev-tool-chain-a-portable-toolchain-for-casm-development-targetting-cpc/)" - may have something in it of use.
I rely more on the available Language Compilers the CPC had with the exception of CPC BASIC 3 or Winape Assembler that I occasionally use. Using the newer languages which function on PCs would allow you to generate more optimised code over the old CPC compilers which rely on a whole library of routines (ones that you use & may not necessarily use), to allow your program to function.
CPC Basic 3 - as the name suggests can take a Locomotive BASIC program and convert it into Assembly, Z88DK (http://www.cpcwiki.eu/index.php/Z88DK) or Binary, though isn't 100% Locomotive BASIC compatible, the big drawback would be lack of Floating Numbers.
thank you I have started to read the links , a lot of info, very useful :)
Quote from: kilon on 08:45, 09 March 15
(I killed my CPC long time ago to motivate my father to get me a new computer :D ) .
What? :o
Quote from: TFM on 20:52, 09 March 15
What? :o
Call me Kilon The CPC Slayer.
Yeah sadly its a true story that may cause some heart attacks in this forum.
I always had a love and hate relationship with my CPC. The truth was that I never wanted it as a computer , my eye was always set on Amiga . I really hated its Green color monitor. Amiga 500 at time (december 1988) was a ton better in term of graphics.
But I also loved CPC because it was a computer and it was quite fun , I loved the games and had good times coding in Basic. So in no way I did not enjoy using my CPC.
4 years after I got CPC , I went to a private school for coding and I was learning many languages , Basic, dbase and clipper. But my eyes were now set on pcs and their impressive hardware. I could not use any of the software other people were using or code in the languages they did and I was fed up with CPC and its green monitor , so I killed it :D .
I was left without a computer for 1-2 years and then my father got me a new one. A 486Dx2 at 60 mhz, 10 times faster than CPC and at last I had a beautiful color monitor and even got a soundblaster audio card. I was in heaven :D Learned C and even did Assembly with DOS.
Of course I felt bad for killing it by using an incompatible power adaptor, but to this day I have no regrets. My father would most likely have left me with CPC for several years, if not a decade, he was always afraid I would not follow his profession and instead become a coder. So he was trying to frustrate as much as possible to give up coding and computers altogether. Kept nagging him several years after I killed CPC for a new PC and he never even told me to fix CPC instead.
Obviously if I could I would have avoid it, but I have no regrets. CPC had to die for the greater good. I also made it look like an accident for my plan to work.
By the way I am studying Z80 now following the link in CPCWiki . The good news is that I am already a bit familiar with Assembly because I coded for DOS. I always wanted to learn CPC assembly but I was scared 8 year old at the time when even Basic looked too hard :D . So this is a way to fulfill a childhood dream ;)
I have not figured out how to compile Z80 for Arnold yet.
Hello,
I went back and learnt "unoptimized" z80 assembly on the cpc one and a half year ago,
I found the information I needed in the wiki, but scattered in a lot of different places,
I still had a lot of searching / structuring to do.
Most importantly, what helped me as a c/java programmer was the tuto from ti calc:
Z80 Documentation - ticalc.org (http://www.ticalc.org/pub/text/z80/)
assembly in 28 days.
I found winape very useful and I encourage you to use it, if you want a proper hello world I can find back simple sources .
I'm a "real noob" but I am at the level where I can write an unoptimized graphic game,
I might be more accessible to ask questions to .
With the permission from the others,
I might be able to do a tutorial from 0 on winpae, as a new wiki section,
to give back something .
Do I need special rights to create a page/ amend the programming section ?
Or is a sticky thread better ?
#edit#
small helloworld for winape with lots of comments,
open winape,
f3 to open assembler
open file
f9 to assemble
back to cpc
type
call &4000
return
I went back active last year and scince I'm coding c/c++/c# in my professional job, I use a mixture of C and ASM on CPC.
I'm completely using SDCC C-compiler and the included assembler. This ASM code is not 100% compatible to the other cpc-assembler solutions (the syntax is quite different and some illegal opcodes are not supported).
If you are interested in this way, then, besides the wiki, take a look at AMSTRAD CPC PROGRAMMING TUTORIALS (http://www.cpcmania.com/Docs/Programming/Programming.htm)
Quote from: trabitboy on 09:51, 10 March 15
Most importantly, what helped me as a c/java programmer was the tuto from ti calc:
Z80 Documentation - ticalc.org (http://www.ticalc.org/pub/text/z80/)
yeap thats a very good tutorial.
QuoteI found winape very useful and I encourage you to use it, if you want a proper hello world I can find back simple sources .
I am using Arnold because I am a MacOSX user. But I have a VM with windows installed, I can give winape a try.
QuoteI'm a "real noob" but I am at the level where I can write an unoptimized graphic game,
I might be more accessible to ask questions to .
Noob or no noob, if you can answer my questions then mission accomplished ;)
QuoteWith the permission from the others,
I might be able to do a tutorial from 0 on winpae, as a new wiki section,
to give back something .
I find hard to believe that anyone would object to that, certainly not me :)
thanks you also for the example.
QuoteI'm completely using SDCC C-compiler and the included assembler. This ASM code is not 100% compatible to the other cpc-assembler solutions (the syntax is quite different and some illegal opcodes are not supported).
From what I read the use of C is very limited because of the limitation of the hardware. So I would prefer to write code in Assembly, plus its an excuse for me to learn Aseembly even more. Call me freak but always loved coding in Assembly. Always felt dirty but in a good way 8)
I love your link, great info.
I think I am on the right road, its now more of question of reading the documentation and writting the code. From the link I think z88dk is probably the best choice for me as a Mac developer. Thanks
Winape is really cool to get started because you start it, hit f3,and start writing ; also it has built in breakpoint capability
Honestly... while waiting 1-2 years for a PC I would have easily made the money by picking up a spare time job. Actually that was the way I financed my computers back the day.
And explaining the old man that a PC may be needed for work would most likely have stimulated him for financial aid.
Willingly destructing a CPC gives bad karma for a long time. Only way out is to fix lot's of them.
Quote from: TFM on 17:06, 10 March 15
Honestly... while waiting 1-2 years for a PC I would have easily made the money by picking up a spare time job. Actually that was the way I financed my computers back the day.
And explaining the old man that a PC may be needed for work would most likely have stimulated him for financial aid.
Willingly destructing a CPC gives bad karma for a long time. Only way out is to fix lot's of them.
I got the CPC at the age of 9 , I killed it at the age of 12 . 14 years old I got the pc. Underage work (under the age of 15) is illegal in my country and even if did decide to work ilegally I still would have made peanuts compared to the cost of a pc at the time, since the salaries in Greece are very low even for adults without qualifications.
I was also a crazy kid at the time (diagnosed with hyperactive syndrome), nobody would want to hire me , with not the best capacity of self control. My teachers suffered more than enough :D
Also at the time I loved to brake things , test them , take them to their extremes. I am also still , not a collector guy. If something is not used then it has to go. At best I would have sold CPC but for very little since PC were all the rage at the time. I also dont believe in Karma . I rarely do things I regret, this is definetly not one of them. So sorry if this shocks you but for me my Amstrad never truly died. It gave me my great love for coding which is something I am very grateful for and it taught me how fun computers can be. It would have died for me if I kept it and got bored of everything computer wise and finally gave up or became another regular user using it mostly for facebook. The hardware is gone, but memories will stay with me forever :)
And now I can also contribute back to Amstrad by producing new code for it ;)
Who knows maybe one day you may forgive me :D
Oh, well... Welcome in the forum. Glad to see you somehow back to the CPC. :)
Quote from: TFM on 20:07, 10 March 15
Oh, well... Welcome in the forum. Glad to see you somehow back to the CPC. :)
Thank you TFM. I am also impessed with your OS , though I did not have the chance to try it yet. I will try it soon. I was a bit on a dilemma whether I should code in Amstrad emulator or Amiga emulator. But I really like the community here. Besides Amstrad looks 100x cooler in color monitor than in green screen so I now I have the opportunity to experience Amstrad in much more fun way than I did with my own back then.
I would not mind to own also the real hardware but I dont have the space. With your help I am reading the Z80 tutorial and its actually quite easy :) Most certainly I wont be making any very good games any time soon but I can certainly code something interesting.
Graphical game can come pretty fast you need:
- to store your data in structures and be able to curse them
- blit to the odd ram layout
- get keyboard input
if you do something single screen, and step by step in a first iteration,
it can come pretty fast.
Coding for any computer is a great learning experience.
Do not worry if your first game is not perfect, because each time a game is made and completed you gain a better toolset, you understand the system better so can do it better next time.
Quote from: trabitboy on 14:08, 11 March 15
Graphical game can come pretty fast you need:
- to store your data in structures and be able to curse them
- blit to the odd ram layout
- get keyboard input
if you do something single screen, and step by step in a first iteration,
it can come pretty fast.
Unfortunatly the one thing that really annoys me so far is that it forces me to use windoom and I seriously dont like windoom. So far following the tutorial on cpcmania for sdcc hello world , it needs hex2bin which is a windoom app and something to generate a dsk file , again a windoom app.
Are there any alternatives for macos ?
Concerning the game, thats is not so much a problem. I am not that serious in coding something big for CPC, my return to CPC has to do more with a itch I had to revive my memory about Assembly. The game as you said will be super small, one screen, probably a board game of some sort/ adventure.
What it means "to be able to curse them" ?
"Coding for any computer is a great learning experience."
I am not new to coding, I regularly code in python and pharo , which are my favorite languages. I am already working on a very big project for creating a visual programming language for Blender the open source 3d application. But I wanted to take a brake and try something very different ;)
Quote from: kilon on 14:58, 11 March 15
Unfortunatly the one thing that really annoys me so far is that it forces me to use windoom and I seriously dont like windoom. So far following the tutorial on cpcmania for sdcc hello world , it needs hex2bin which is a windoom app and something to generate a dsk file , again a windoom app.
Is there source for it?
Quote
Are there any alternatives for macos ?
try cpcxfs. It's command-line based.
http://www.cpctech.org.uk/download/cpcxfs.zip (http://www.cpctech.org.uk/download/cpcxfs.zip)
I haven't tried compiling it for mac, but it builds for linux.
If I have time I'll build it for mac and update the sources.
make -f makefile.lnx
cpcxfs -nd test.dsk
cpcxfs test.dsk -p file.bin
"Coding for any computer is a great learning experience."
I am not new to coding, I regularly code in python and pharo , which are my favorite languages. I am already working on a very big project for creating a visual programming language for Blender the open source 3d application. But I wanted to take a brake and try something very different
[/quote]
Nice.
You may find that coding for CPC has some challenges because of the limited memory size and display compared to much more powerful systems.
Quote from: kilon on 12:28, 11 March 15
Thank you TFM. I am also impessed with your OS , though I did not have the chance to try it yet. I will try it soon. I was a bit on a dilemma whether I should code in Amstrad emulator or Amiga emulator. But I really like the community here. Besides Amstrad looks 100x cooler in color monitor than in green screen so I now I have the opportunity to experience Amstrad in much more fun way than I did with my own back then.
I would not mind to own also the real hardware but I dont have the space. With your help I am reading the Z80 tutorial and its actually quite easy :) Most certainly I wont be making any very good games any time soon but I can certainly code something interesting.
Cool! That's the right attitude :-) Being creative is much fun :-)
Well, if you code with Emulators and need somebody to test on real hardware then you find enough help here! And I can help of course too.
Thank's for your compliment, FutureOS of course runs on emulators too. If you need it with special ROM numbers for the emu, just PM me.
You're right about the Color monitor, that's a whole other world. For coding I use the GT still though.
Amiga is fun too I guess, never had one, but saw the machine couple of times at friends place. Since that time we try to be better than amiga ;)
Quote from: arnoldemu on 15:05, 11 March 15
Is there source for it?
try cpcxfs. It's command-line based.
http://www.cpctech.org.uk/download/cpcxfs.zip (http://www.cpctech.org.uk/download/cpcxfs.zip)
I haven't tried compiling it for mac, but it builds for linux.
If I have time I'll build it for mac and update the sources.
make -f makefile.lnx
cpcxfs -nd test.dsk
cpcxfs test.dsk -p file.bin
"Coding for any computer is a great learning experience."
I am not new to coding, I regularly code in python and pharo , which are my favorite languages. I am already working on a very big project for creating a visual programming language for Blender the open source 3d application. But I wanted to take a brake and try something very different
Nice.
You may find that coding for CPC has some challenges because of the limited memory size and display compared to much more powerful systems.
it gives me an error unix.c:15:10: fatal error: 'malloc.h' file not found
hex2bin is open source but looks too tied to windoom , no mention of any unix.
Its not the end of the world I can use windoom. But yeah macos builds are ideal.
QuoteWell, if you code with Emulators and need somebody to test on real hardware then you find enough help here! And I can help of course too.
Thank's for your compliment, FutureOS of course runs on emulators too. If you need it with special ROM numbers for the emu, just PM me.
You're right about the Color monitor, that's a whole other world. For coding I use the GT still though.
I tried FutureOS online version, first Java complained about security issues , I added your website to the security exceptions then it loaded but everything was crawling, I could not move the cursor around. The disk slots cliking on them did nothing. Will give it also a try with Arnold.
I can use hex2bin in Linux compiling it. Try it.
Perhaps cpc-dev-tool-chain works on Mac:
https://github.com/cpcitor/cpc-dev-tool-chain/blob/master/README.md
Try it
hex2bin and cpcxfs do work flawlessly either on Linux or on Windows/Cygwin. I have never tryied in MacOS, but shouldn't be so hard to adapt, given that they compile and work on Linux.
As @jrodriguezv (http://www.cpcwiki.eu/forum/index.php?action=profile;u=699) suggests, you may try cpc-dev-tool-chain (http://github.com/cpcitor/cpc-dev-tool-chain) on MacOS. I have been using it on various Linux flavours and on Windows/Cygwin and the latest version works like a charm.
If you find problems using it on MacOS, I suggest reporting them to @cpcitor (http://www.cpcwiki.eu/forum/index.php?action=profile;u=531): he's willing to improve any problem like this to make cpc-dev-tool-chain work on every platform. If you finally use windows, here you are a video for easily setting it up with cygwin (https://www.youtube.com/watch?v=FQ4ToK9ry5U).
cpc-dev-tool-chain includes (automating compilations and install steps):
- Hex2bin
- cpcxfs
- iDSK
- 2cdt
- playtzx
- sdcc
- z88dk
- cpcrslib
- cfwi
Quote from: kilon on 17:32, 11 March 15
hex2bin is open source but looks too tied to windoom , no mention of any unix.
No need of hex2bin on unix, use objcopy (or sdobjcopy with sdcc)
Here are the rules I use in my makefiles (windows/linux):
objcopy = sdobjcopy
%.bin : %.ihx
${objcopy} -Iihex -Obinary $< $@
Why you people believe something that build for Linux will build for MacOS when the two operating systems are so diffirent ? Massively different I would say. Its not that simple. I have seen loads of people suffer to get linux builds to work on MacOS.
So no hex2bin does not build on macos. I also don't know how to mess with makefiles and customise builds. Though it seems sooner or later I will have to learn.
cpc-dev-tool-chain fails to build too.
If I use windows then I have no need for cpc-dev-tools since windoom is already covered.
sdobjcopy seems to work.
Thank you all for trying to help me out, really appreciate it.
@kilon (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1303): 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 :) .
Quote from: ronaldo on 23:12, 11 March 15
@kilon (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1303): 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 ;)
Quote from: AMSDOS on 09:38, 09 March 15
CPC Basic 3 - as the name suggests can take a Locomotive BASIC program and convert it into Assembly, Z88DK (http://www.cpcwiki.eu/index.php/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 (http://www.cpcwiki.eu/index.php/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 (http://www.cpcbasic.tk/).
Quote from: AMSDOS on 09:01, 12 March 15
Actually my advise there is pretty flawed as the website link in the CPC BASIC 3 thread reveals. So Z88DK should be ccz80 (http://www.cpcwiki.eu/index.php/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 (http://www.cpcbasic.tk/).
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 :)
Quote from: kilon on 14:58, 11 March 15
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 :D
Quote from: trabitboy on 10:25, 12 March 15
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 :D
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
(http://ecx.images-amazon.com/images/I/51VltHvdjbL._SL500_.jpg)
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.
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 .
Quote from: trabitboy on 11:00, 12 March 15
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
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
Quote from: trabitboy on 11:37, 12 March 15
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. :o
Obviously I am far from an expert but kinda amazed I can read assembly in just a few days 8)
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 )
last example for today, with HL and IX to pretend we have a list like in a "high level" language
( this is getting addictive 8) )
DISCLAIMER: I'm a noob and this is simple , not optimized
Quote from: kilon on 11:46, 12 March 15
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 :)
Quote from: trabitboy on 12:05, 12 March 15
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 :)
Quote from: kilon on 12:41, 12 March 15
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
Quote from: trabitboy on 12:51, 12 March 15
#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
(http://cf.geekdo-images.com/images/pic1196589_md.jpg)
card based and turn based. Then I could expand future version to more maps, more type of monsters , more player stats etc
that is a big map for cpc screen resolution :)
Quote from: kilon on 13:38, 12 March 15
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
Quote from: trabitboy on 15:00, 12 March 15
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 :D
Quote from: kilon on 10:07, 12 March 15I 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.
Quote from: AMSDOS on 08:41, 13 March 15
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.
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).
Quote from: Shining on 10:57, 13 March 15
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.
Quote from: kilon on 10:30, 13 March 15
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.
Quote from: AMSDOS on 12:45, 13 March 15
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.
Quote from: kilon on 13:46, 13 March 15
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. :D
QuoteSo 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. :D
Quote from: AMSDOS on 23:47, 13 March 15
That's perfectly fine, I was only draw a comparison between Language and end result. :D
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. :D
And this why I think Emulators rock :D
But then I never worry when my code crashes to oblivion, I am terrified when it does not. I know there is a nasty big bug like predator is in stealth mode waiting patiently to get me. But then this where you good people come in to the rescue to be used as cannon fodder .
So here we go with first coding question.
I have seen a couple of example of how z80 can exchange data with C via direct access of memory , in case of C with the use of a pointer and function memset(). Is this the only way I can pass data from C to assembly ? I am using SDCC.
It can be a bit confusing finding this info in the SDCC documentation, as it's written from an 8051 standpoint and not entirely obvious how other processors work. As C code gets transformed into assembly as part of the compile process, the fundamental answer to your question is 'do it the way the compiled code does it'.
This comes down to a few different techniques.
All in-scope variables have labels that are accessible as asm labels. You'll see this in the inline asm in Section 3.13; pointers to the C variables 'head' and 'tail' are available to the asm as '_head' and '_tail' - the C name prefixed with an underscore. All asm labels (including function labels) follow this convention.
Next is the calling convention: the compiler has a standard way of storing C function parameters in memory before calling a function. Section 3.14 in the SDCC docs describe it's calling convention; the first parameter always goes into registers (it lists the 8051 registers here; the z80 equivalents are in section 4.3, basically DEHL depending on how long the param is) and the remaining parameters either get permanently allocated memory with a specific label for each parameter: _functionname_PARM_x (for a non reentrant function) or are pushed onto a stack frame pointed to by IX (when marked re-entrant). The whole non-re-entrant mess is due to 8051 limitations; the stack-auto option will compile all functions as re-entrant by default.
Quote from: kilon on 08:48, 15 March 15
So here we go with first coding question.
I have seen a couple of example of how z80 can exchange data with C via direct access of memory , in case of C with the use of a pointer and function memset(). Is this the only way I can pass data from C to assembly ? I am using SDCC.
The parameters are passed on to the stack, and my preferred method is to read them by pointing HL to the appropriate place in the stack (reading from HL is a lot quicker than reading from IX). Here is an example from some code I wrote to load a file using the firmware:
__asm
ld hl,#5
add hl,sp
ld d,(hl)
dec hl
ld e,(hl) ; DE = address to load file to
dec hl
ld a,(hl)
dec hl
ld l,(hl)
ld h,a ; HL = address of filename string
; ...Or you can of course read the registers in the opposite direction if you need to, like this piece of code I wrote to read ink colours from a table:
__asm
ld hl,#2
add hl,sp
ld a,(hl)
inc hl
ld h,(hl)
ld l,a ; HL = start address of table containing ink data
; ...
Thank you both, I am reading the recommended chapters from the SDCC manual
Nich may I ask you why you do
ld hl,#5
?
peirum what makes re-entrant and non re-entrant function in the case of Z80 ?
If I understand both of you recommend to read the parameters from the stack. But how I know where each parameters starts and ends ?
Quote from: kilon on 21:35, 15 March 15
Nich may I ask you why you do
ld hl,#5
That's the number of bytes taken up by the parameters on the stack; after adding the stack pointer (which points to the bottom end of the parameter block) HL will point to the top end of the parameter block.Nich, you're using SP instead of IX there; does SDCC actually point SP at the right place or are you manually copying IX into it earlier?Quote
pelrun* what makes re-entrant and non re-entrant function in the case of Z80 ?
SDCC treats all functions as non-reentrant by default (which is not standard C behaviour). Either add '__reentrant' to every function definition (annoying), or add --stack-auto to your sdcc command line to change the default to re-entrant instead.
Quote
If I understand both of you recommend to read the parameters from the stack. But how I know where each parameters starts and ends ?
You wrote the parameter list in the function definition; it's just that crammed together in order - you need to know how many bytes each parameter is (char=1, int=2, long=4 etc).
Quote from: kilon on 08:48, 15 March 15
I have seen a couple of example of how z80 can exchange data with C via direct access of memory , in case of C with the use of a pointer and function memset(). Is this the only way I can pass data from C to assembly ? I am using SDCC.
As others have pointed out, you have to look for calling conventions to better understand how parameters are passed to C functions (there are different ways). By default, SDCC uses the stack, with a policy called "caller saves". This means 2 things: Stack is used to pass parameters to functions and, also, the caller is responsible for saving the values of the registers, as callee will most likely alter them.
To understand how parameters are passed, it is better to see a couple of code examples:
;src/main.c:59: case _4x8: cpct_drawSprite4x8_aligned(sprite, video_mem); break;
00104$:
push de
push bc
call _cpct_drawSprite4x8_aligned
pop af
pop af
Here we are calling a function which draws an sprite, and needs 2 parameters: a pointer to the sprite and another pointer to the video memory location where to paint the sprite. Both parameters are 16-bits, so they are stored in registers de=video_memory, bc=sprite. The compiler pushes these two values to the stack in reverse order (from right to left, video_mem first, sprite second). Doing it this way, is easier for the function to recover them, as they will be in direct order with respect to the top of the stack, as you see in the next piece of code:
;; GET Parameters from the stack (Push+Pop is faster than referencing with IX)
pop af ;; [10] AF = Return Address
pop hl ;; [10] HL = Source address (Sprite)
pop de ;; [10] DE = Destination address (Video Memory)
push de ;; [11] Leave the stack as it was
push hl ;; [11]
push af ;; [11]
It is important to note that a third 16-bit value is also pushed to the stack by the CALL instruction: it pushes the return address, which points to the next code instruction that should be executed when the function is finished (when a RET is performed). It is also important to note that we have to be careful when messing up the stack. When a RET is executed, stack should be in the same state that it was when function was called (at least, SP should point to the same address and it should contain the return address). Otherwise, horrible evils of side effects will come and eat us, poor human programmers :D .
This is a different example:
;src/main.c:81: printAllScreen(sprites[i], spr_widths[i], functions[i]);
push af
inc sp
push bc
inc sp
push de
call _printAllScreen
pop af
pop af
The main difference here is that functions[ i ] and spr_widths[ i ] are 8-bit, whereas sprites[ i ] is 16-bit. So, the compiler uses a combination of push af + inc sp which effectively inserts A register into the stack (it writes AF but incrementing SP makes the stack point to A, and leave F just out of the top of the stack). The same happens with push bc + inc sp: B is inserted at the top of the stack. At the end, there are 6 bytes at the top of the stack: Return address (2bytes), sprites[ i ] (2bytes), spr_widths[ i ] (1byte), functions[ i ](1byte). Then, with only 3 pops, like in the previous example, you may get the 6 values out of it.
I hope this example is useful for you to understand how it all works :) .
Quote from: pelrun on 04:58, 16 March 15
Nich, you're using SP instead of IX there; does SDCC actually point SP at the right place or are you manually copying IX into it earlier?
Yes, SP automatically points to the right location, so there's no need to do anything with IX.
Quote from: Nich on 20:12, 16 March 15
Yes, SP automatically points to the right location, so there's no need to do anything with IX.
SP = Stack Pointer, this is the register the CPU uses to point to the top of the stack, not IX. IX means Index Register and is designed to point at the start of tables or vectors to be able to easily access all of their members.
SDCC most of the time (and depending on the configuration you use for compiling) synchronizes IX with SP, but I would advice against assuming that it works this way allways. It is better to use more standard ways of accessing the stack (and, moreover, they are faster than using IX)
wow you guys are amazing, you spent all this time explaining things to me and with detailed examples. Can't thank you enough . Sometimes I code because I enjoy coding sometimes because I enjoy the community, you people seem to have both here :)
I think now with your help I understand how the interaction between C and Assembly works. Thank you . These are my first steps I am sure more will follow.
Quote from: ronaldo on 22:18, 16 March 15
SDCC most of the time (and depending on the configuration you use for compiling) synchronizes IX with SP, but I would advice against assuming that it works this way allways. It is better to use more standard ways of accessing the stack (and, moreover, they are faster than using IX)
I'm working from the manual, which isn't great for architectures other than 8051 (it only mentions IX.) Haven't had a chance to poke it and see what the actual behaviour was.
I only remember banging my head when I was trying to Integrate my Small-C code into Assembly.
RSXes would be easier surely? I was able to Integrate Easi-Sprite Driver with CPC BASIC 3 that got me an extremely fast result when the Assembly was compiled, though CPC BASIC 3 can also produce ccz80 code as a workaround?
Quote from: AMSDOS on 09:13, 17 March 15
I was able to Integrate Easi-Sprite Driver with CPC BASIC 3 that got me an extremely fast result
I would be interested in seeing this. I have been playing around with easi-sprite driver thinking of making a very simple game, but the ability to compile it would be very cool! Do you mind sharing?
Quote from: Morri on 17:55, 17 March 15
I would be interested in seeing this. I have been playing around with easi-sprite driver thinking of making a very simple game, but the ability to compile it would be very cool! Do you mind sharing?
It should be this post (http://www.cpcwiki.eu/forum/programming/moving-graphical-images-down-the-screen/msg68879/#msg68879) along with all my other Ramblings. :D Here's a direct link (http://www.cpcwiki.eu/forum/programming/moving-graphical-images-down-the-screen/?action=dlattach;attach=10517) to that attached file if you prefer.