I'm trying to make a pure basic loader that works both cassette and disc, and DSK works fine but the CDT loads the loading screen "displaced" and I don't know why.
My idea is pure basic, load the palette, set the colours with INK, load the image into 0xc000, and finally load the game.
The loader is:
10 MODE 0:CLS
20 MEMORY &9FFF:LOAD"!pal":BORDER 0
30 FOR i=0 TO 15
40 v=PEEK(i+&A000):INK i, v, v
50 NEXT i
60 LOAD"!loading"
70 RUN"!game"
And the DSK created with idsk works as expected, but when I create a CDT with:
2cdt -n -r MYGAME loader.bas master.cdt
2cdt -F 2 -L 0xa000 -r PAL pal master.cdt
2cdt -F 2 -L 0xc000 -r LOADING loading master.cdt
For some reason the loading screen loads like this:
[attach=1,msg166325]
I'm attaching the resulting CDT (doesn't include the game).
Any ideas what I'm doing wrong? Thanks!
If the "loading" binary is definitely identical between the two versions, then maybe the loading address set in the CDT isn't right. What happens if you explicitly specify the load address with the following?
LOAD"!loading",&C000
Quote from: pelrun on 07:31, 24 October 18
If the "loading" binary is definitely identical between the two versions, then maybe the loading address set in the CDT isn't right. What happens if you explicitly specify the load address with the following?
LOAD"!loading",&C000
No change. I put it in the header because it makes the basic code s bit shorter.
I suspect that 2cd may be doing something funny, but I can't tell what is it. Unless I'm missing something obvious in the behaviour of load...
Hi reidrac, 2cdt has a little bug. The first 69 bytes cannot be 0s. I learnt that recently, although my result was no loading screen printed. But maybe you get another result, check that.
Quote from: cperezgrin on 07:52, 24 October 18
Hi reidrac, 2cdt has a little bug. The first 69 bytes cannot be 0s. I learnt that recently, although my result was no loading screen printed. But maybe you get another result, check that.
I'll look at this. I may be able to fix it :+1:
Quote from: cperezgrin on 07:52, 24 October 18
Hi reidrac, 2cdt has a little bug. The first 69 bytes cannot be 0s. I learnt that recently, although my result was no loading screen printed. But maybe you get another result, check that.
Thank you. I will fix that.
2cdt tries to be helpful and detect an amsdos header.
In this case, I think it detects there is a header when there is no header. I will make a better header detection :)
I can confirm it's definitely because 2CDT is trying to autodetect an AMSDOS header by calculating the checksum. Since the AMSDOS checksum is *actually* a trivial sum of the first 67 bytes, 69 zeroes is therefore a valid AMSDOS header and gets trimmed by 2cdt. Oops.
Quote from: arnoldemu on 09:18, 24 October 18
In this case, I think it detects there is a header when there is no header. I will make a better header detection :)
Well, that's a general problem. If the header is 0 then the checksum is 0. So a header is detected where no header is there. Had that problem with FutureOS before. Just check if the sum of all header bytes is zero, in this case define "it's not a header". :)
Quote from: cperezgrin on 07:52, 24 October 18
Hi reidrac, 2cdt has a little bug. The first 69 bytes cannot be 0s. I learnt that recently, although my result was no loading screen printed. But maybe you get another result, check that.
Yes, that's exactly what I was going to say. Some of my students had this issue with their basic-made loaders. In fact, their issue was worse, because their loaders sometimes displayed nothing, and other times simply failed. It seems that this problem was long time unspot because having 69 consecutive zeroes at the start is quite unusual, and seems to be easier to get it with test images like @reidrac (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1504) 's or the ones that used my students.
Quote from: arnoldemu on 09:18, 24 October 18
Thank you. I will fix that.
2cdt tries to be helpful and detect an amsdos header.
In this case, I think it detects there is a header when there is no header. I will make a better header detection :)
I think I have to apologize, @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) , I should have sent you a report when we found this issue. In fact, I think I should extend my apologizes to everyone, because this issue could have been fixed long ago if I had reported it to you. Sorry about that.
I never got this issue because I usually include the palette at the beginning of the image + compression. Oh, well.
@arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) what is the official URL for the tool? Thanks.
Yep, confirmed. That was the issue.
Thanks everybody for your help!
Quote from: reidrac on 15:58, 24 October 18
I never got this issue because I usually include the palette at the beginning of the image + compression. Oh, well.
@arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) what is the official URL for the tool? Thanks.
http://cpctech.cpc-live.com/download/2cdt.zip
I have also updated it.
I must apologise because in my other tools I have much better header detection and I failed to transfer that into 2cdt.
Quote from: arnoldemu on 19:05, 24 October 18
http://cpctech.cpc-live.com/download/2cdt.zip
I have also updated it.
I must apologise because in my other tools I have much better header detection and I failed to transfer that into 2cdt.
Thanks!
I may put my bits on a repo with all together to make it easier to use, kind of like cpctelera does, but I'd love to mention the official download in case anyone wants a newer version of the tool.
Also no need to apologize. This is software and it may have bugs. You gave us your tool as a gift, and I'm thankful for it!
OK, I put it all together in this repo:
https://github.com/reidrac/cpc-mastering
It focuses on Linux and it is mostly information (plus some convenient tools).
Nothing new I think, but getting this information together is not easy. It may be useful!