-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
glitches on Apple II #10
Comments
@oliverschmidt could you give me some advices? |
No good idea :-( Just some random ideas:
|
I can confirm that the issue does indeed now happen. With optsize as decsribed and with optspeed, when drawing the board and it gets to the garbled pieces, the game will crash. I can't look into it right now to make sure this is the issue but I when I look at a version that I previously built, and that does work, it is 24976 bytes. The version I built with a newer compiler (cl65 V2.19 - Git 1093d16 - mabe a month or two ago?) generated an executable of 25961 bytes. I thus suspect a compiler change. When I have time, I will investigate further (I always kept the previous compiler and just with the last time I updated I didn't - now I sure wish I had ;) |
|
From Oliver's list:
src/cc65/coptstop.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ But this doesn't make sense to me because I started with head today as bad and as good I used:
So bad is today and good was Apr 19, 2023 but bisect says first bad commit was 2021? This was my first time using bisect. I suppose that the 2021 commits didn't get merged till after Apr 2023? I don't know how to look to see and my first attempts at finding the asnwers in Google didn't work out - and now I am out of time.
|
Pieces are broken since PR 2240 OK disks I tested are here. |
I built them on Intel Mac.
|
Can you please check if #12 makes a difference? |
still problem build with cc65 HEAD 2024/01/09 at 7:02
build with cc65 8e6c0c14 2023/10/26 at 20:06
cc65's differences between 8e6c0c14 (makes OK build) and a8d00bfa (makes error build) |
my build also works fine! 😄 thank you !! |
Thank you @iss000 - that does indeed fex the problem. I opted for the line: inv = blackWhite ^ !((piece & PIECE_WHITE) != 0); simply because I would never think to use !! |
It's an order of precedence issue. The orifinal code makes inv == 128 and the new code makes it == 1 if piece = 0 and PIECE_WHITE == 128. AT least, I think that's what's going on. Empirically tested I can say that inv == 128 and not 1 in the old vs new code. |
Thanks for the feedback. Sorry for not being precise enough: I'm wondering why it is that way. |
Just for the record: my favorites actually are: |
Just for the record:
The latter implies that there's no need to change the source code of the program above in any way for the Apple II. |
That's the reason why it worked before.
Even if the current cc65 behavior is covered by the standard it might still be that the cc65 team isn't aware of the change in behavior and considers it desirable to revert to the former behavior. I personally even assume that they see it this way. My suggestion would be therefore to further reduce your program to the bare minimum showing the difference to GCC and open a cc65 issue (incl. the info which commit changed the behavior). |
Hi, |
@colinleroy Thanks for taking care of that! It's actually a nice show case for the usefulness of actually communicating with the cc65 team 😃 |
And that |
@colinleroy Thank you! I appreciate you sorting this. It still sat in my inbox as something I needed to do when I finished what I am busy doing :) |
I built it like this:
The text was updated successfully, but these errors were encountered: