e.g., z88dk/libsrc/_DEVELOPMENT/EXAMPLES/zxn/sprites/mixed-sw-hw/main.c
It seems that the compiler can't find zxn includes. How to specify path to them?
This example works for me using the compile line example given in the main.c - have you set up your ZCCCFG as shown on https://github.com/z88dk/z88dk/wiki/installation ?
Yes that is probably the problem. But there is another problem with that compile line in that the zx next now treats the sna format as a legacy format so when loading an sna, the computer is set up as a 48k or 128k spectrum with all of the next hardware switched off.
So to get a program that will run on the next, the output format can be changed to nex, which is the format used for programs that take over the machine. This can be done by changing the subtype from sna to nex:
zcc +zxn -v -startup=1 -clib=sdcc_iy -SO3 --max-allocs-per-node200000 main.c graphics.asm.m4 interrupt.asm -o main -pragma-include:zpragma.inc -subtype=nex -Cz"--clean" -create-app
The examples were written more than a year ago -- this was when I started to be involved in the zx next hardware and I had to choose one or the other to work on as my time has been very limited the past year. But I will be returning to it soon to update the zxn target. Amongst the things we've learned is that it's not really a good idea to name hardware registers as that makes it harder to use documentation that documents by number. In the example program, almost everything is named.
Edit: I ran the example on a real machine. A change in how sprite transparency is handled has the hardware sprites of this program surrounded by magenta instead of transparent. A bug in the program has some hardware sprites being generated just outside the screen area so they are being rapidly reversed in direction at the bottom, flicking in and out of visibility. But otherwise it is still working.
I was going to open a pull request for that @aralbrec ;-)
$ echo $PATH
......:/home/pasha/ZXNext/z88dk/bin
$ echo $ZCCCFG
/home/pasha/ZXNext/z88dk/lib/config
test.c:
#include
int main()
{
return 0;
}
$ zcc +zxn test.c
Error at file 'test.c' line 207: syntax error
.... and many more errors
I downloaded the latest build for windows and that also runs fine. Unfortunately I can't check the linux package until tonight.
Do you mind trying:
which zcc
to verify the right zcc is running? If you installed z88dk previously, that older version may be earlier in your path. Also, there are other projects that use a decade-old version of zcc in their installs that may also be earlier in the path.
Other than that, the next step would be to see those errors.
Can you:
zcc +zxn -v test.c > foo.txt
and report the result either download link or cut & paste here? You may have to redirect stderr to a file too.
which zcc
this told me that I have zcc in /usr/local/bin
It seems that I installed it for some reason, when started playing with zcc.
After removing all z88dk files from /usr/local I'm still get that error messages.
stdout.txt
stderr.txt
Here are also the temporaries:
tmpXXiStVNo.asm.txt
tmpXXiStVNo.err.txt
tmpXXiStVNo.i.txt
tmpXXiStVNo.i2.txt
tmpXXiStVNo.op1.txt
tmpXXiStVNo.opt.txt
It's failing at the assembler stage, so comparing your .asm.txt with one that I'm generating shows that instead of GLOBAL [label] your file as !extern - this is the reason why the compilation is failing.
!extern is internally generated by sdcc for global definitions file - as far as I know it shouldn't actually reach an output file.
I've tried on a Mac and Linux - both x86_64 to reproduce this and I can't. What's your host architecture: I may be able to spin up an environment and check it out.
Can you run zcc +zxn test.c -O0 -a -v and share the generated ".s" file? - This is the file generated by sdcc with minimal processing so it would be good to see what it's actually generating.
I'm running it on Ubuntu 18.04/64
I built everything from the source code without downloading the package.
Here is the generated *.s:
test.c.s.txt
It almost looks as if something's gone wrong with your build of zsdcc.
Could your patching have been off? Any hunks not take where they should have?
What happens if you do this?
phillip@SilverQuad:~$ zsdcc -v
ZSDCC IS A MODIFICATION OF SDCC FOR Z88DK
Build: 4.0.0 #11556 (Linux) Mar 14 2020
sdcc website:
https://sourceforge.net/projects/sdcc/
patch details:
https://github.com/z88dk/z88dk/blob/master/src/zsdcc/sdcc-z88dk.patch
published under GNU General Public License (GPL)
phillip@SilverQuad:~$
Right, there is no information about patching there.
Trying to patch it:
patch -p0 < sdcc-z88dk.patch
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
|Index: src/SDCCasm.c
|===================================================================
|--- src/SDCCasm.c (revision 11556)
File to patch:
Ok, I should read "copy “sdcc-z88dk.patch” from z88dk/src/zsdcc into the sdcc-code/sdcc directory"
Thank you!
That was my fault, because I thought that sdcc patching will be performed automatically.
Most helpful comment
Yes that is probably the problem. But there is another problem with that compile line in that the zx next now treats the sna format as a legacy format so when loading an sna, the computer is set up as a 48k or 128k spectrum with all of the next hardware switched off.
So to get a program that will run on the next, the output format can be changed to nex, which is the format used for programs that take over the machine. This can be done by changing the subtype from sna to nex:
The examples were written more than a year ago -- this was when I started to be involved in the zx next hardware and I had to choose one or the other to work on as my time has been very limited the past year. But I will be returning to it soon to update the zxn target. Amongst the things we've learned is that it's not really a good idea to name hardware registers as that makes it harder to use documentation that documents by number. In the example program, almost everything is named.
Edit: I ran the example on a real machine. A change in how sprite transparency is handled has the hardware sprites of this program surrounded by magenta instead of transparent. A bug in the program has some hardware sprites being generated just outside the screen area so they are being rapidly reversed in direction at the bottom, flicking in and out of visibility. But otherwise it is still working.