Unable to compile working program to Amstrad
Unable to compile working program to Amstrad
Hi, there!
I'm, using z88dk. I have a program created, Bares, for the ZX Spectrum, using cross-platform libraries only:
http://github.com/baltasarq/bares/
So, I can create a .TAP for the Speccy and it works.
Unfortunately, I cannot do the same for the CPC. I change "+zx" by "+cpc" and it always ends with the same error "ORG has been redefined"... Any clue?
==
>zcc +cpc -O3 -SO3 -create-app -clib=ansi -lndos bares.c cmds.c objs.c locs.c player.c -o bares
z80asm -a -m -Mo -Lc:/z88dk//lib/clibs -Ic:/z88dk//lib -obares -icpcansi_clib -indos -iz80_crt0 C:\Users\Baltasar\AppData\Local\Temp\s748_5.opt C:\Users\Baltasar\AppData\Local\Temp\s748_.o C:\Users\Baltasar\AppData\Local\Temp\s748_1.o C:\Users\Baltasar\AppData\Local\Temp\s748_2.o C:\Users\Baltasar\AppData\Local\Temp\s748_3.o C:\Users\Baltasar\AppData\Local\Temp\s748_4.o
Error at file 'c:/z88dk//lib/cpc_crt0.asm' line 54: ORG redefined
1 errors occurred during assembly
Key to filenames:
C:\Users\Baltasar\AppData\Local\Temp\s748_.o = bares.c
C:\Users\Baltasar\AppData\Local\Temp\s748_1.o = cmds.c
C:\Users\Baltasar\AppData\Local\Temp\s748_2.o = objs.c
C:\Users\Baltasar\AppData\Local\Temp\s748_3.o = locs.c
C:\Users\Baltasar\AppData\Local\Temp\s748_4.o = player.c
Error at file 'c:/z88dk//lib/cpc_crt0.asm' line 54: ORG redefined
^ ---- org myzorg
==
Cheers,
-- Baltasar
I'm, using z88dk. I have a program created, Bares, for the ZX Spectrum, using cross-platform libraries only:
http://github.com/baltasarq/bares/
So, I can create a .TAP for the Speccy and it works.
Unfortunately, I cannot do the same for the CPC. I change "+zx" by "+cpc" and it always ends with the same error "ORG has been redefined"... Any clue?
==
>zcc +cpc -O3 -SO3 -create-app -clib=ansi -lndos bares.c cmds.c objs.c locs.c player.c -o bares
z80asm -a -m -Mo -Lc:/z88dk//lib/clibs -Ic:/z88dk//lib -obares -icpcansi_clib -indos -iz80_crt0 C:\Users\Baltasar\AppData\Local\Temp\s748_5.opt C:\Users\Baltasar\AppData\Local\Temp\s748_.o C:\Users\Baltasar\AppData\Local\Temp\s748_1.o C:\Users\Baltasar\AppData\Local\Temp\s748_2.o C:\Users\Baltasar\AppData\Local\Temp\s748_3.o C:\Users\Baltasar\AppData\Local\Temp\s748_4.o
Error at file 'c:/z88dk//lib/cpc_crt0.asm' line 54: ORG redefined
1 errors occurred during assembly
Key to filenames:
C:\Users\Baltasar\AppData\Local\Temp\s748_.o = bares.c
C:\Users\Baltasar\AppData\Local\Temp\s748_1.o = cmds.c
C:\Users\Baltasar\AppData\Local\Temp\s748_2.o = objs.c
C:\Users\Baltasar\AppData\Local\Temp\s748_3.o = locs.c
C:\Users\Baltasar\AppData\Local\Temp\s748_4.o = player.c
Error at file 'c:/z88dk//lib/cpc_crt0.asm' line 54: ORG redefined
^ ---- org myzorg
==
Cheers,
-- Baltasar
Tape files are usually much more convenient for emulators hence there's no disc writing tool. Having said that, the default app make output for a CPC is a file with the AMSDOS header prepended.
I think I used this: http://www.moria.de/~michael/cpmtools/ when I last did work on the CPC port - it uses libdsk which supports the CPC disc format.
I think I used this: http://www.moria.de/~michael/cpmtools/ when I last did work on the CPC port - it uses libdsk which supports the CPC disc format.
Okay, I've been able to locate the sources of xti, so I created a disk with my compiled program (bares.dsk) inside. So far, so good. Then, I insert it in the virtual drive of CPCBox, and online CPC emulator. I can do a "cat", and my program is there:
bares .cpc 23k
Then I type:
memory &5fff
ok... and then:
load "bares.cpc", &6000
And here I get the error "bad command" (?) (It does not matter if I include the parameter &6000 or not).
What am I doing wrong?
bares .cpc 23k
Then I type:
memory &5fff
ok... and then:
load "bares.cpc", &6000
And here I get the error "bad command" (?) (It does not matter if I include the parameter &6000 or not).
What am I doing wrong?
I gather you are following the steps at:
http://www.z88dk.org/wiki/doku.php?id=p ... amstradcpc
What if you try "cat" followed by 'run "bares.cpc'
http://www.cpcwiki.eu/index.php/A_guide ... s_computer
http://www.z88dk.org/wiki/doku.php?id=p ... amstradcpc
What if you try "cat" followed by 'run "bares.cpc'
http://www.cpcwiki.eu/index.php/A_guide ... s_computer
appmake could probably use some updating for the cpc since it doesn't seem to be producing file types that the emulators are using anymore.
Anyway this is what I did:
zcc +cpc -vn -clib=ansi -lndos -create-app test.c -o test
There are two output files:
test.cpc
made by appmake which should have an amsdos header and should be plantable in a disk image. I haven't tried it yet.
test
raw binary output
You can take that raw binary and make a wav file using appmake:
appmake +cpc -b test --org 24576 --exec 24576 --audio
The output will be "test.wav"
I ran this in WinAPE by doing this:
FILE->tape->insert tape image
choose test.wav
type this into the cpc:
|tape
run"
then in the emulator start the tape
FILE->tape->press play
The program should load and auto start. When it exits, the cpc resets and the screen is cleared.
Wav format is of course slow. It would be better if it were cdt or tzx for loading speed and I'm sure there are tools out there to do this.
The error you got with unable to enter the load or run" command sounds like you didn't tell the cpc to use disk, which can be done with a "cat" before the load or run. For the same reason "|tape" has to be entered before loading from tape above
Anyway this is what I did:
zcc +cpc -vn -clib=ansi -lndos -create-app test.c -o test
There are two output files:
test.cpc
made by appmake which should have an amsdos header and should be plantable in a disk image. I haven't tried it yet.
test
raw binary output
You can take that raw binary and make a wav file using appmake:
appmake +cpc -b test --org 24576 --exec 24576 --audio
The output will be "test.wav"
I ran this in WinAPE by doing this:
FILE->tape->insert tape image
choose test.wav
type this into the cpc:
|tape
run"
then in the emulator start the tape
FILE->tape->press play
The program should load and auto start. When it exits, the cpc resets and the screen is cleared.
Wav format is of course slow. It would be better if it were cdt or tzx for loading speed and I'm sure there are tools out there to do this.
The error you got with unable to enter the load or run" command sounds like you didn't tell the cpc to use disk, which can be done with a "cat" before the load or run. For the same reason "|tape" has to be entered before loading from tape above
For making a disk, I was successful with cpcdiskxp but this is a windows only program.
http://www.cpcwiki.eu/index.php/File:CP ... v2.5.1.zip
After compiling as usual with the -create-app option, the output "hw.cpc" is generated which is the binary with an amsdos header. This what has to be added to the disk.
Start cpcdiskxp, click on the "disk editor" button. Select "new". It asks for a disk format - just accept the default and press ok. On the right, press "add files" and select "hw.cpc" from the file dialog. Next save the disk. Choose a filename for the disk with dsk extension. Exit from the program.
In winape, I chose FILE->drive A->insert disk image
choose the disk image you just made
On the cpc, type:
cat
run"hw.cpc (or "test.cpc I seem to have mixed in a few names here)
The program runs and will clear the screen on exit.
http://www.cpcwiki.eu/index.php/File:CP ... v2.5.1.zip
After compiling as usual with the -create-app option, the output "hw.cpc" is generated which is the binary with an amsdos header. This what has to be added to the disk.
Start cpcdiskxp, click on the "disk editor" button. Select "new". It asks for a disk format - just accept the default and press ok. On the right, press "add files" and select "hw.cpc" from the file dialog. Next save the disk. Choose a filename for the disk with dsk extension. Exit from the program.
In winape, I chose FILE->drive A->insert disk image
choose the disk image you just made
On the cpc, type:
cat
run"hw.cpc (or "test.cpc I seem to have mixed in a few names here)
The program runs and will clear the screen on exit.
No luck.
The problem is not creating the dsk file, I can do that with both xti and cpcdiskxp.
And yes, I follow your steps in order to create a disk with the bares.cpc file inside.
load "bares.cpc"
But the program does not load. It reads "problem loading error".
The command line for creating the CPC executable success, without errors:
zcc +cpc -O3 -SO3 -create-app -lm -clib=ansi -lndos bares.c cmds.c objs.c locs.c player.c -o bares
Any clue?
The problem is not creating the dsk file, I can do that with both xti and cpcdiskxp.
And yes, I follow your steps in order to create a disk with the bares.cpc file inside.
load "bares.cpc"
But the program does not load. It reads "problem loading error".
The command line for creating the CPC executable success, without errors:
zcc +cpc -O3 -SO3 -create-app -lm -clib=ansi -lndos bares.c cmds.c objs.c locs.c player.c -o bares
Any clue?
I was successful using load with the disk image I created.
cat
memory &5fff (to allow binary to load at address 0x6000)
load"test.cpc
reports ok in the emulator.
Other than that, maybe post a link to the .cpc file you created to see if we can get it to run?
cat
memory &5fff (to allow binary to load at address 0x6000)
load"test.cpc
reports ok in the emulator.
I don't think there is anything in the compile line that is going to prevent the cpc from loading a binary image. You could try eliminating the switches you're not using. "-lm" is for float math so if you don't use floats, just drop it. "-SO3" is an optimization setting for sdcc and since you're using sccz80 you can drop that.zcc +cpc -O3 -SO3 -create-app -lm -clib=ansi -lndos bares.c cmds.c objs.c locs.c player.c -o bares
Other than that, maybe post a link to the .cpc file you created to see if we can get it to run?
The program is compiling to 22691 bytes and by default starts at address 24576 so it runs until address 47267 = 0xb8a3.
I think you've run out of memory! This page ( http://www.cpcwiki.eu/index.php/Source_Codes ) states that "Memory range for programs is &0040-&a700..." which is exceeded here.
So I tried to compile your program for a lower start address 0x400 = 1024 and try again:
zcc +cpc -O3 -create-app -lm -clib=ansi -lndos -zorg=1024 bares.c cmds.c objs.c locs.c player.c -o bares
This one reports memory full if I try to load it (maybe don't drop it all the way down to address 1024) but it seems to run if I "run" instead. Unfortunately it crashes right away.
I think you've run out of memory! This page ( http://www.cpcwiki.eu/index.php/Source_Codes ) states that "Memory range for programs is &0040-&a700..." which is exceeded here.
So I tried to compile your program for a lower start address 0x400 = 1024 and try again:
zcc +cpc -O3 -create-app -lm -clib=ansi -lndos -zorg=1024 bares.c cmds.c objs.c locs.c player.c -o bares
This one reports memory full if I try to load it (maybe don't drop it all the way down to address 1024) but it seems to run if I "run" instead. Unfortunately it crashes right away.
No it just means you have to drop the org address lower.
I'm referring to some basic information here:
http://www.cpcwiki.eu/index.php/Source_ ... eral_Notes
http://www.z88dk.org/wiki/doku.php?id=p ... amstradcpc
Because the cpc target is using the firmware you have to operate under its restrictions. Unfortunately the last time I looked there didn't seem to be people who knew or information written down that explained a program's obligations when using firmware. Most programs written for the cpc today turn off the firmware and do everything themselves so that they can use most of the ram.
The points from the above links I noted are:
* Memory range for programs is &0040-&a700
* Lower rom (containing OS) can be paged into memory between &0000-&3fff
* If you produce code under $1200 and needs to get loaded then run from BASIC, the ?memory? command is required;
* Extra registers (BC', AF', HL', DE' are reserved by the firmware). Avoid if you are using firmware functions
I don't know if the lower rom being paged in means you can't have data delivered to the firmware from that address range in ram and I am not sure if there are any firmware functions called by z88dk that would pass strings or blocks of data (maybe not) so that that would be an issue. Nevertheless to avoid problems, maybe a start address of 0x4000 makes sense. I have no idea if the default org of 0x6000 used by z88dk is special in cpc circles like 32768 is for the zx but it seems to me the default should rather be 0x4000.
0xa700 - 0x4000 = 26368 bytes for your program which is sufficient.
The other thing I am looking at is "firmware reserves AF',BC',DE',HL'". Most of the classic c library will stay away from those registers but there are some notable exceptions: long integer math and non-native floating point. What it means that firmware reserves those registers is unclear to me: does the firmware expect their values to persist across calls? If that's the case, the z88dk code is not doing the right thing. I am reluctant to fix anything until it's known there is a problem, like your program will not run. Stefano is the original author of the port (I think) and he's taking some time off for the moment.
I'm referring to some basic information here:
http://www.cpcwiki.eu/index.php/Source_ ... eral_Notes
http://www.z88dk.org/wiki/doku.php?id=p ... amstradcpc
Because the cpc target is using the firmware you have to operate under its restrictions. Unfortunately the last time I looked there didn't seem to be people who knew or information written down that explained a program's obligations when using firmware. Most programs written for the cpc today turn off the firmware and do everything themselves so that they can use most of the ram.
The points from the above links I noted are:
* Memory range for programs is &0040-&a700
* Lower rom (containing OS) can be paged into memory between &0000-&3fff
* If you produce code under $1200 and needs to get loaded then run from BASIC, the ?memory? command is required;
* Extra registers (BC', AF', HL', DE' are reserved by the firmware). Avoid if you are using firmware functions
I don't know if the lower rom being paged in means you can't have data delivered to the firmware from that address range in ram and I am not sure if there are any firmware functions called by z88dk that would pass strings or blocks of data (maybe not) so that that would be an issue. Nevertheless to avoid problems, maybe a start address of 0x4000 makes sense. I have no idea if the default org of 0x6000 used by z88dk is special in cpc circles like 32768 is for the zx but it seems to me the default should rather be 0x4000.
0xa700 - 0x4000 = 26368 bytes for your program which is sufficient.
The other thing I am looking at is "firmware reserves AF',BC',DE',HL'". Most of the classic c library will stay away from those registers but there are some notable exceptions: long integer math and non-native floating point. What it means that firmware reserves those registers is unclear to me: does the firmware expect their values to persist across calls? If that's the case, the z88dk code is not doing the right thing. I am reluctant to fix anything until it's known there is a problem, like your program will not run. Stefano is the original author of the port (I think) and he's taking some time off for the moment.
Alvin, I've tried to compile with -zorg=1024 and even with -zorg=640, with no luck:
zcc +cpc -zorg=1024 -O3 -SO3 -create-app -lm -clib=ansi -lndos bares.c cmds.c objs.c locs.c player.c -o bares
I mean, the program compiles and I can put into a diskette, but as soon as you type "run "bares.cpc", then it hangs with some dotted colored lines.
I was so naive to think that it would be as easy to change +zx to +cpc...
Anything else I can try?
zcc +cpc -zorg=1024 -O3 -SO3 -create-app -lm -clib=ansi -lndos bares.c cmds.c objs.c locs.c player.c -o bares
I mean, the program compiles and I can put into a diskette, but as soon as you type "run "bares.cpc", then it hangs with some dotted colored lines.
I was so naive to think that it would be as easy to change +zx to +cpc...
Anything else I can try?
I got a step closer to getting to work by compiling with this:
zcc +cpc -O3 -create-app -lm -clib=ansi -subtype=noint -lndos -zorg=1024 bares.c cmds.c objs.c locs.c player.c -o bares
This chooses subtype noint which ensures the firmware interrupts don't run. What I see now is the prompt but no description text is printing. So the problems seem to be down to the crt and firmware calling routine not saving the AF', BC', DE', HL' registers. I will try to come up with a proper solution in the next couple of days.
zcc +cpc -O3 -create-app -lm -clib=ansi -subtype=noint -lndos -zorg=1024 bares.c cmds.c objs.c locs.c player.c -o bares
This chooses subtype noint which ensures the firmware interrupts don't run. What I see now is the prompt but no description text is printing. So the problems seem to be down to the crt and firmware calling routine not saving the AF', BC', DE', HL' registers. I will try to come up with a proper solution in the next couple of days.
In the May 14 build I have committed some changes that I think solves the firmware AF',BC',DE',HL' problem. Unfortunately I left an error in the crt that won't be fixed until May 15. If you grab the May 14 build you can fix the error yourself.
z88dk/lib/cpc_crt0.asm
Line 305 should be "ld (__fw_exx_set_active__),a" instead of "ld (__fw_exx_set_active__),1"
If you make that change and compile with:
zcc +cpc -O3 -create-app -lm -clib=ansi -lndos -zorg=16384 bares.c cmds.c objs.c locs.c player.c -o bares
I get somethng that is running but I can't see the descriptive text, just the prompts and a few messages. I think the text is printing but is it possible it's printing in BLUE on BLUE background?
z88dk/lib/cpc_crt0.asm
Line 305 should be "ld (__fw_exx_set_active__),a" instead of "ld (__fw_exx_set_active__),1"
If you make that change and compile with:
zcc +cpc -O3 -create-app -lm -clib=ansi -lndos -zorg=16384 bares.c cmds.c objs.c locs.c player.c -o bares
I get somethng that is running but I can't see the descriptive text, just the prompts and a few messages. I think the text is printing but is it possible it's printing in BLUE on BLUE background?
It is possible the text being displayed in blue blackground and indeed the text color is blue. But it does not make sense to have a blue blackground, since the colors selected where white background. You can see the appearance of the application here:
http://baltasarq.github.io/Bares/
Now that I think about it, I did not have to set the background color (it is white by default in the speccy). Maybe I'd have to do add a specific change of background color to the code just for amstrad. I'll mess with all you told me, and see whether I can make it to work.
Many thanks, BTW.
Baltasar
http://baltasarq.github.io/Bares/
Now that I think about it, I did not have to set the background color (it is white by default in the speccy). Maybe I'd have to do add a specific change of background color to the code just for amstrad. I'll mess with all you told me, and see whether I can make it to work.
Many thanks, BTW.
Baltasar
I found some technical info on the cpc and the May 16 will have the finalized change to the cpc crt. Among the changes are the default org has moved to 0x1200 so you will be able to compile without a zorg on the compile line.
I compile your program and it ran successfully, except for the blue on blue printing. I changed the text colour to red and everything was visible. Don't forget on the cpc there are only four colours available in mode 1 and I'm not sure if it's even possible to print with a different background colour in different lines. It looks like changing the background colour changes the entire screen's background colour so there may not be a mapping for setting the background colour to white using conio. The cpc is new to me so I can't say for sure but I will look into it in time to see if there is some problem with conio for the cpc. Maybe a cpc user or expert will chime in so we can know if this is a bug or not.
I compile your program and it ran successfully, except for the blue on blue printing. I changed the text colour to red and everything was visible. Don't forget on the cpc there are only four colours available in mode 1 and I'm not sure if it's even possible to print with a different background colour in different lines. It looks like changing the background colour changes the entire screen's background colour so there may not be a mapping for setting the background colour to white using conio. The cpc is new to me so I can't say for sure but I will look into it in time to see if there is some problem with conio for the cpc. Maybe a cpc user or expert will chime in so we can know if this is a bug or not.