FULL_cpc.cdt about cross-lib HOT 22 CLOSED

Thanks a lot for reporting the issue!
Do you know of any scriptable tool that I can use to put the game into a CDT?
Ideally I need a tool that I can automatically call from my Makefile.

I cannot reproduce the crash.
I have just tested with WinApe 2.0 Beta 2 with CPC464 settings and the game works fine.
Can you reproduce the crash on an emulator? Which one and and which settings do you use?

If your issue is confirmed than I suspect some of the graphics libs.
I am relying on some libs, which are no longer maintained.
These libs might be using some 6128'specific code.
I will need to figure out, what exactly breaks it and how to implement graphics in a different way.
I may take a lot of time.
For the moment I can just rename the to make it explicitly for 6128 only, if the issue is confirmed.

from cross-lib.

Do you know of any scriptable tool that I can use to put the game into a CDT?

Hmm, do you mean DSK?

I have just tested with WinApe 2.0 Beta 2 with CPC464 settings and the game works fine.
Can you reproduce the crash on an emulator? Which one and and which settings do you use?

Sounds like you're in CPC Plus mode, I tested this and that did work with your game, though the later CPC Plus models (464 and 6128) had BASIC 1.1 in them, so are compatable with the earlier 6128 in that regard.
I'm using WinApe 2.0 Alpha 18, though I'm using the original 464 (BASIC 1.0), so in the General Tab, the Plus Features are disabled and in the Memory Tab the Cartridge is disabled. In the ROM slot area, Lower reads OS464, Upper 1 for BASIC1-0.

If the problem turns out to be what I mentioned earlier (an issue with the address lines), the Firmware Manual documents those address lines and what they are between a 464/6128, though it becomes troublesome when Plus models come into it because a 464 Plus suddenly becomes the same as the 6128! Which was why I brought up the need to have code to detect which CPC is being used.

from cross-lib.

Hi!

Sorry! I meant how to create a disk from a raw binary, which is what the compiler can produce.

I have finally managed to see the issue.
I still don't know what causes it. I am not writing the low level code. I rely on some libs.
One lib for the PSG routines and one for the tile graphics.

from cross-lib.

@OutBush, the problem is ONLY reproducible with WinAPE but it does not show up at all on JavaCPC.
We need someone to test it on the real hardware... Could you please help us on this?

It could be a real issue or just WinAPE doing the wrong thing.
Under JavaCPC I use:
Lower ROM: OS464
System: CPC 464
BASIC 1-0

from cross-lib.

I wish I could test on a real 464 :( Perhaps someone of the CPCWiki Forum could help?

Sadly again I don't have JavaCPC to be able to see. I also failed to mentioned that I had 128Kb of RAM and AMSDOS in Upper 7 on my 464 in WInape when the problem occurred. Perhaps one of those is the problem, though it seemed to be more of a Incompatability issue when everything started working with the 6128 & BASIC 1-1 ROM. If it's not much trouble could you post the Libraries here, if their huge you can delete afterwards, I will have got an email with it in there.

Unfortunately I don't have a lot of insight on the compiler you're using, so again unfortunately I can't advise how to compile to disk, perhaps -? on the command line can suggest that?

from cross-lib.

@OutBush, if the game works under JavaCPC with the plain 464, I am not sure the issue really exists.

Could you please install JavaCPC and test it with the same settings that caused the crash?

JavaCPC is just a Java application and installation is very simple.

from cross-lib.

I can confirm the problem with Mame/Mess.
The issue comes from the compiler Z88dk and not my own code.
I have reported the issue to Z88dk.
I will flag the game as cpc6128-only.
@OutBush, I will close this issue in the next days because it is not in my code.
@OutBush I have verified my code by removing any hardware dependent portion.
I will try alternative compilers (CPCTelera) if possible.
My hope is to have Z88dk implement a CPC target that works with all models.

from cross-lib.

Maybe a different compilation parameter can fix the issue that seems to be related to the stack location.

from cross-lib.

@OutBush, the issue is probably solved now! :-)
Could you please test it with different configurations?

from cross-lib.

Problem solved! Thanks @OutBush for reporting the issue!

from cross-lib.

Happy to know this is solved.

I have reported the issue to Z88dk.

Can you share the URL?

Information below is for general value.

I wish I could test on a real 464 :( Perhaps someone of the CPCWiki Forum could help?

I have a real 464 and a real 6128. I can test. I nearly always use CDT loading even on CPC6128 because 3-inch disc drive is near-unusable. Anyway, sending short programs via audio is more handy than fiddling with an old PC equipped with 3.5-inch drives, writing image, moving to CPC with 3.5-inch drive etc. Other people use SDcard-based floppy emulators.

I will try alternative compilers (CPCTelera) if possible.
Do you know of any scriptable tool that I can use to put the game into a CDT?

This might be an alternative: https://github.com/cpcitor/cpc-dev-tool-chain (disclosure: I wrote it and CPCTelera took inspiration from it -- and gave some credit).

It's AFAIK the most firmware-friendly C-level environment for the CPC (see coverage).

from cross-lib.

@cpcitor thanks for suggesting your tool! I will give it a try.
I would like to use 160x200 mode for my game.

Which URL do you need?

from cross-lib.

Which URL do you need?

You wrote:

The issue comes from the compiler Z88dk and not my own code.
I have reported the issue to Z88dk.

Is it that bug report: z88dk/z88dk#592 ?

If so, then:

(1) it looks like the bug is real and it's strange that JavaCPC does not reproduce the bug. Perhaps JavaCPC use a mixture of ROMs and thus emulates something that is not exactly a 464.

(2) Marking game "cpc 6128 only" feels wrong. In that case, it's a z88dk bug to be fixed.

from cross-lib.

@cpcitor nope, the problem is really fixed now by using a different compilation option that places the stack at the right place for all models.

@cpcitor, yes the corresponding bug in Z88DK is described in
z88dk/z88dk#592

from cross-lib.

Thanks for clarifying. I understood that your project now uses the option -pragma-define:REGISTER_SP=-1 which requests z88dk to not break the stack and not break compatibility model. IMHO that option should be default in z88dk. Anyway the issue here with cross-chase is indeed fixed.
Cheers!

from cross-lib.

Sorry for my late reply, glad the problem was sorted. Has a new version of Cross-Chase been posted on the site?

from cross-lib.

@OutBush, thanks for reporting the issue.

Could any of you @OutBush, @cpcitor please tell how I can put the binary into a disk image through a command line tool that does NOT require any human intervention?

from cross-lib.

From what I was reading, it looks like Z88DK doesn't actually create DSK images, but you can use the -create-app switch to produce a file which includes AMSDOS header, this results in a file with the ".cpc" being created. This is the file with the AMSDOS header. From there it should be easy enough to use Winape to Create a DSK, Format it (Data format) and use Edit Disk to Paste the file to. The ".cpc" extension just needs to be changed to ".bin".

from cross-lib.

@OutBush, I asked for the name of a tool to create disk images without human intervention. I cannot do this manually each time I rebuild. I need a command line tool that does this.

from cross-lib.

The only way you could have that is if Z88DK did that automatically, but from what I can tell, Z88DK doesn't do that. The alternative is to use CPCFS, which requires more even human intervention than my Winape approach.

from cross-lib.

@OutBush , it seems that CPCFS has a command line and non-interracting mode.
I don't know how to use it.

from cross-lib.

cpc-dev-tool-chain does that. If compiling the project completely, it performs all needed steps automatically, including fetching and compiling tools from the Internet. Actually, you can "make run" and the projects runs in an emulator moments later without any manual steps.

I believe you're wanting to integrate the dsk generation into your current build process. You will find hints about this on https://github.com/cpcitor/cpc-dev-tool-chain/blob/master/sdcc-project.Makefile#L221

Line 244 is the core of it. Once cpc-dev-tool-chain has figured out load address and execute address from build logs, it calls iDSK with parameters : -i filename -e runaddress -c loadaddress -t 1 (I don't remember the possible values for -t).

Alternatively, lines 259+ there's something based on cpcxfs which is somewhat similar. cpc-dev-tool-chain can also generate a binary with amsdos header.

Command line looks like: cpcxfs -f -nd output.dsk -b -p myfile.bin

I wrote those lines but forgot a lot since it's just been working for years without much need for maintenance.

Hope this helps!

from cross-lib.