Originally posted by NickFitz
View Post
Excellent, apart from the final sentence! It is indeed correct that it should have just been adding the immediate value 100, rather than looping 100 times adding the immediate value 1... but the add-with-carry (hence the mnemonic ADC) of value zero to the high-order byte is correct, to accommodate the case where the low-order byte value overflows from below-or-equal-to 0xFF to above-or-equal-to 0x00 (I'm speaking of the general case here, not the "add 1" situation we see in this example) and the carry from the low-order byte needs to be added to the high-order byte.
PDP8/e (YMMV, especially if you've always used microprocessor-based machines)
Excellent again! Except that he does need to do the ADC of zero to the high-order byte, as explained above.
You are correct to assume that the score was held as a 16 bit (two byte) value, and that this would mean that scores above 65,535 would roll over to zero + (score - 65,536). However - a constraint that I didn't mention - this was not a problem in this particular game, as (like most games of the era) the score was internally held as a two byte value, but the display of the score had a couple of extra zeroes, that remained constant, on the end. Thus, when adding 100 to the score, it appeared to the player as if their score had increased by 10,000 - smoke and mirrors, but psychologically powerful
The gameplay was such that no (internal) score as high as 65,536 could ever be achieved, so this was not an issue.
BTW, some early arcade and home computer games were subject to spectacular and/or interesting bugs when internal values overflowed the 255 or 65,535 boundaries because the programmers had underestimated the lengths people would go to in playing these things, but that wasn't the case with this one - it wasn't primarily a point-scoring game, the points in question were only relevant to a round (or level) of the game, and could never reach 65,536.
Given this, we can take the facts that:
a) The 6502 is actually capable of adding 100 to a byte;
b) Therefore, we don't need a loop;
c) Nonetheless, the state of the Carry flag is indeterminate when this subroutine is called;
to achieve:
FTW 
FWIW, the reason we determined very soon that something dodgy was going on with his code was that there was a terrible flicker of the display (it was a pseudo-FPP-driving game) whenever one got the 100-point (== 10, 000 point) bonus - that lovely little loop of his used up nearly half a frame on the C64's 1MHz processor, called from a code block within which interrupts were disabled, which of course played merry hell with the timings
Top marks to you both, say I
PDP8/e (YMMV, especially if you've always used microprocessor-based machines)Excellent again! Except that he does need to do the ADC of zero to the high-order byte, as explained above.
You are correct to assume that the score was held as a 16 bit (two byte) value, and that this would mean that scores above 65,535 would roll over to zero + (score - 65,536). However - a constraint that I didn't mention - this was not a problem in this particular game, as (like most games of the era) the score was internally held as a two byte value, but the display of the score had a couple of extra zeroes, that remained constant, on the end. Thus, when adding 100 to the score, it appeared to the player as if their score had increased by 10,000 - smoke and mirrors, but psychologically powerful
The gameplay was such that no (internal) score as high as 65,536 could ever be achieved, so this was not an issue.BTW, some early arcade and home computer games were subject to spectacular and/or interesting bugs when internal values overflowed the 255 or 65,535 boundaries because the programmers had underestimated the lengths people would go to in playing these things, but that wasn't the case with this one - it wasn't primarily a point-scoring game, the points in question were only relevant to a round (or level) of the game, and could never reach 65,536.
Given this, we can take the facts that:
a) The 6502 is actually capable of adding 100 to a byte;
b) Therefore, we don't need a loop;
c) Nonetheless, the state of the Carry flag is indeterminate when this subroutine is called;
to achieve:
Code:
.add100points CLC LDA scorelo ADC #100 STA scorelo LDA scorehi ADC #0 STA scorehi RTS
FWIW, the reason we determined very soon that something dodgy was going on with his code was that there was a terrible flicker of the display (it was a pseudo-FPP-driving game) whenever one got the 100-point (== 10, 000 point) bonus - that lovely little loop of his used up nearly half a frame on the C64's 1MHz processor, called from a code block within which interrupts were disabled, which of course played merry hell with the timings
Top marks to you both, say I
is a far superior processor to the 6502!
Leave a comment: