C64 Bible Trivia Game - error in music routine

[RobertB]

Hi, everybody,

 

Lenard Roach, our newsletter editor, is working on this multiple-choice, BASIC game that he copied from a magazine.  The game runs fine, except for one point.  When you give a correct answer, the game is supposed to play music and then give you a flashing screen.  However, when you give a second correct answer, instead of playing the music, the game crashes with an OUT OF DATA error at line 3830.  When we look at the line, we can't see the mistake.  I think something is wrong somewhere between lines 3800 and 4000.  The music routine is set up as DATA statements.  Can anybody help us with the BASIC so that the program doesn't crash at the second correct answer?  The game is attached to this message.

 

Sincerely,

Robert Bernardo

Fresno Commodore User Group - http://www.dickestel.com/fcug.htm

Southern California Commodore & Amiga Network - http://www.portcommodore.com/sccan

June 25-26 Commodore Los Angeles Super Show 2022 - http://www.portcommodore.com/class

Bible Trivia Game.d64

[+OLD CS1]

Just a quick thought before having a look, are you RESTOREing back to the start of DATA before playing music the subsequent times?

 

Edit:  Yeah, that is what you are missing.  As an example, I added

3825 RESTORE

And if I answer question 1 correctly, then question 2, the music works and does not crash, even with subsequent questions.

 

There does seem to be a good bit of redundancy and inefficiency in the program. Obviously it will run as-is, but there is a lot of optimization which could be done.

[carlsson]

21 hours ago, OLD CS1 said:

There does seem to be a good bit of redundancy and inefficiency in the program.

The same was true for the other religious program Robert posted before. I suppose those were made by enlightened enthusiasts with limited programming skills. As long as the program works and does what you expect from it, I suppose it is of minor concern but in a more competitive environment outside of the church, the software would need a good overhaul to last longer.

 

As a bonus, you can use POKE 65,low:POKE 66,high to RESTORE data statements to a given address. You could use a machine code monitor and look up the line link pointers to know which values to use, as long as you don't change anything on those lines so they move around. Some BASIC extensions had a custom version of RESTORE which takes a line number like some other BASIC dialects supported.

[RobertB]

Thanks, guys!  Yeah, even though I'm not a programmer, as a layperson I did notice that a lot of the code seemed inefficient.  And we can always compile it with Blitz 64 or Basic 64. 

 

Sincerely,

Robert Bernardo

Fresno Commodore User Group - http://www.dickestel.com/fcug.htm

Southern California Commodore & Amiga Network - http://www.portcommodore.com/sccan

June 25-26 Commodore Los Angeles Super Show 2022 - http://www.portcommodore.com/class

 

P.S. By the way, the other Bible programs were improved with the previous suggestions and then Blitzed.  They run fine now.

[bjonte]

As a bonus, you can use POKE 65,low:POKE 66,high to RESTORE data statements to a given address.

Wow! I didn’t know about this trick. Should it point to the next value or just after the previous or is this a line pointer?

[+OLD CS1]

5 hours ago, RobertB said:

Thanks, guys!  Yeah, even though I'm not a programmer, as a layperson I did notice that a lot of the code seemed inefficient.  And we can always compile it with Blitz 64 or Basic 64. 

The inefficiencies I see are about taking up memory space than speed.  Performance seems fine for what is being developed as a text quiz game.  But, if what is trying to be done will fit in the 38k memory, then the redundancies and inefficiencies are academic. Godspeed!

[carlsson]

13 hours ago, bjonte said:

Wow! I didn’t know about this trick. Should it point to the next value or just after the previous or is this a line pointer?

It was many years ago I used it, so without experimenting I can't say but I think it is a pointer to the next DATA value, which might equal a line pointer + 1 byte for the DATA keyword.

 

On a standard C64:

PRINT PEEK(65)+PEEK(66)*256 = 2048

 

10 DATA 10,20,30,40

READ A

PRINT PEEK(65)+PEEK(66)*256 = 2057 (equals the first comma)

READ A

PRINT PEEK(65)+PEEK(66)*256 = 2060

READ A

PRINT PEEK(65)+PEEK(66)*256 = 2063

READ A

PRINT PEEK(65)+PEEK(66)*256 = 2066

READ A

?OUT OF DATA ERROR

PRINT PEEK(65)+PEEK(66)*256 = 2066

 

If we add a second line, it will begin at $0813 = 2067:

20 DATA 50,60,70,80

 

The first two bytes are the link to the next line, followed by two bytes for the line number. Then follows the DATA keyword at $0817, a space and then our value. When we READ, the pointer will advance to 2075, which equals the position for the first comma.

 

If we POKE 65,23:POKE 66,8 ($0817) which equals the position of the DATA keyword, we will read 50 and the pointer again advances to 2075.

 

From this we learn that BASIC READ knows how to skip past the line pointer and line number and look for the DATA keyword to determine the next data to read. We also know that if we manually adjust the pointer at 65/66, we can choose to have it point to the last DATA value on the line before, or the DATA keyword on the line where we want RESTORE to point to. Yes, it is a bit of hand work but it can be made to work if we know our addresses.