Further qualifications and the BCS

[BrilloPad]

When I was writing games for a living we subcontracted some work to a bloke who claimed to be an ace C64 programmer.

See if you can spot the main problem with this fine bit of code he came up with:

.add100points
   LDX #100
.loop
   CLC
   LDA scorelo
   ADC #1
   STA scorelo
   LDA scorehi
   ADC #0
   STA scorehi
   DEX
   BNE loop
   RTS

No comments?

[NickFitz]

No comments?

It certainly left all of us speechless

[aussielong]

No comments?

I'll bite. Doesn't it do a loop of 100 "+1"s just to add 100 to scorelo? Why not just add 100, instead of adding 1, 100 times? Aswell as adding 0 to a number, 100 times!

[bogeyman]

When I was writing games for a living we subcontracted some work to a bloke who claimed to be an ace C64 programmer.

See if you can spot the main problem with this fine bit of code he came up with:

.add100points
   LDX #100
.loop
   CLC
   LDA scorelo
   ADC #1
   STA scorelo
   LDA scorehi
   ADC #0
   STA scorehi
   DEX
   BNE loop
   RTS

Ahhh

6502 assembler
Beans on toast for tea
Jumpers for goalposts

For the curious, this hotshot game dev adds 1 to 'scorelo' one hundred times, in a loop. Just to be fair, he adds zero to 'scorehi' while he's at it. Presumably he doesn't know that ADC (add with carry) will accept numbers greater than one, or that 'scorehi' won't feel neglected if you don't also give it some love by adding zero to it 100 times. Note how he carefully clears the carry flag (CLC) for every iteration of the loop.

Presumably the task was to allow for scores >= 255 with the 'lo' and 'hi' bytes representing low and high order bytes of a 16-bit integer. As it stands you'd see your score drop back alarmingly just when you thought you were getting somewhere - like on the Weakest Link when they don't 'bank'.

http://uk.youtube.com/watch?v=3NeRoSFZWbs

[aussielong]

Ahhh

6502 assembler
Beans on toast for tea
Jumpers for goalposts

http://uk.youtube.com/watch?v=3NeRoSFZWbs

I started out writing games on the ZX48 in the mid-80s in BASIC as a hobby. I used to dabble in Z80. I remember being amazed that you could draw in the Border on the Spectrum. Take up the whole screen instead of just the bit inside the border. Last game i played was in about 1990. Those two quid CodeMasters games. Some of them were great! Tape to Tape at my mates house. Get 10 on a C60 cassette! Yes, I did a lot of w*****g back then.

[bogeyman]

I started out writing games on the ZX48 in the mid-80s in BASIC as a hobby. I used to dabble in Z80. I remember being amazed that you could draw in the Border on the Spectrum. Take up the whole screen instead of just the bit inside the border. Last game i played was in about 1990. Those two quid CodeMasters games. Some of them were great! Tape to Tape at my mates house. Get 10 on a C60 cassette! Yes, I did a lot of w*****g back then.

Ferret? FERRRRRRETTTTTTT!

We have a transgressor!

Pardon my ignorance but what on earth is a ZX48?

Is that some very early, post WWII home computer that Clive Sinclair devised as a lad using left over valves and relays from Bletchley Park?

[aussielong]

Ferret? FERRRRRRETTTTTTT!

We have a transgressor!

Pardon my ignorance but what on earth is a ZX48?

Is that some very early, post WWII home computer that Clive Sinclair devised as a lad using left over valves and relays from Bletchley Park?

Eh? What's up? You can use that word on Countdown, so why not here?

ZX48K? If that is the correct name? The first Spectrum that was popular. Rubber keys. Joysticks made from two lollipop sticks and a rubber dart stuck to the keys.

[bogeyman]

Eh? What's up? You can use that word on Countdown, so why not here?

ZX48K? If that is the correct name? The first Spectrum that was popular. Rubber keys. Joysticks made from two lollipop sticks and a rubber dart stuck to the keys.

yer not wrong: http://uk.youtube.com/watch?v=7gBXPUSXGWs

[NickFitz]

I'll bite. Doesn't it do a loop of 100 "+1"s just to add 100 to scorelo? Why not just add 100, instead of adding 1, 100 times? Aswell as adding 0 to a number, 100 times!

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.

Ahhh
6502 assembler
Beans on toast for tea
Jumpers for goalposts

PDP8/e (YMMV, especially if you've always used microprocessor-based machines)

For the curious, this hotshot game dev adds 1 to 'scorelo' one hundred times, in a loop. Just to be fair, he adds zero to 'scorehi' while he's at it. Presumably he doesn't know that ADC (add with carry) will accept numbers greater than one, or that 'scorehi' won't feel neglected if you don't also give it some love by adding zero to it 100 times. Note how he carefully clears the carry flag (CLC) for every iteration of the loop.

Presumably the task was to allow for scores >= 255 with the 'lo' and 'hi' bytes representing low and high order bytes of a 16-bit integer. As it stands you'd see your score drop back alarmingly just when you thought you were getting somewhere - like on the Weakest Link when they don't 'bank'.

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:

.add100points
   CLC
   LDA scorelo
   ADC #100
   STA scorelo
   LDA scorehi
   ADC #0
   STA scorehi
   RTS

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

[Bob Dalek]

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:

.add100points
   CLC
   LDA scorelo
   ADC #100
   STA scorelo
   LDA scorehi
   ADC #0
   STA scorehi
   RTS

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

You have posted a 1986 GCSE Computing paper and I claim my free copy of "Revenge" by The Eurythmics.