Jump to content
  • entries
    106
  • comments
    796
  • views
    141,006

Reindeer Rescue bug found!


Guest

1,175 views

AND, OF COURSE, it was my own buggy code all along. :roll:I have to run pretty quick, so I'll fill in the details later, but basically I committed the classic boneheaded ASM mistake: I forgot a '#' in front of a constant:

    lda GameFlags
   ora PLAYERCONTROL_BIT|SCROLLPF_BIT
   sta GameFlags

Can't believe it. :|

 

Well, mystery solved anyway.Will post fixed binary and source later.

 

EDIT: Fixed source and binary attached. RR20060301.zip

 

And a big thanks to Eckhard to sending me his modified version of z26 (that forced undefined bits high), seeing the problem in an emulator made it possible for me to track the problem down through the z26 log files, where I saw that the reason for the weird behavior was due to the game flags somehow becoming corrupted. It was a bit tedious, but it wasn't hard, ultimately, to track down exactly where they became corrupted; it was code that looked like this:

   lda bf
  ora CXP1FB
  sta bf

Well, this will help me to be humble, anyway.

8 Comments


Recommended Comments

If I were designing an assembly language, I'd insist upon using a # for immediate constant and brackets for memory references, rather that using just the # (like the 6502) or just the brackets (like the Z80).

 

If I were designing a higher-level language, I'd keep C's equality-test operator and Pascal's assignment operator.

 

Increasing the "distance" between different commands would increase the likelihood of typos getting caught.

Link to comment

Amazing how we come up with these elaborate explanations as to what's happening, when all along it was just that same old "forgetting the #" thing.

 

Occam's Razor at work!

 

Though I think I was right when I said it had to do with the EPROM affecting the data bus

Link to comment
Uihjah :D  :)

 

Remember? That was one of the the first things I told ya! :D

I know; I feel like an absolute moron. :cool:

 

The problem was I was so rushed to finish it. Oh well.

 

I'm not sure if Al has made all the copies of RR yet or not; if he hasn't made the ones that are still to be sent I imagine he'll use the fixed version.

 

Which, by the way, I will now attach to the original post.

Link to comment
Amazing how we come up with these elaborate explanations as to what's happening, when all along it was just that same old "forgetting the #" thing.

 

Occam's Razor at work!

 

Though I think I was right when I said it had to do with the EPROM affecting the data bus

The really crazy thing is that some of those things fixed it! I never touched the problem code. That's what I don't figure. The fact that changing the code that checked P0-to-PF collisions apparently fixed the problem really, *really* threw me off track.

Link to comment
So I wonder if I'll get the fixed version of Raindeer Rescue whenever Adventure II is finished?

Yes, as thankfully I haven't built all of those yet. Although I did program a ton of EPROMs which I'll now have to erase and reprogram. Not completely necessary, since the bug does not exhibit itself with these particular EPROMs, but I'd rather not take a chance since the bug has been identified (and I just realized I still haven't tested it out on real hardware--will have to do that this weekend).

 

..Al

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...