error: EQU: Value mismatch?

[Fort Apocalypse]

Could anyone help me figure this out? TIA!

---------- Capture Output ----------

> "C:\Atari2600\bB\2600bas.bat" C:\Atari2600\projects\ultindy500\ultindy500_0.1.bas

2600 Basic compilation complete.

DASM V2.20.07, Macro Assembler ©1988-2003

2600basic_variable_redefs.h (47): error: EQU: Value mismatch.

old value: $0090 new value: $00d7

2600basic_variable_redefs.h (49): error: EQU: Value mismatch.

old value: $0091 new value: $00d6

bytes of ROM space left

2600basic.h (34): error: EQU: Value mismatch.

old value: $00d7 new value: $0090

2600basic.h (35): error: EQU: Value mismatch.

old value: $00d6 new value: $0091

2600basic_variable_redefs.h (47): error: EQU: Value mismatch.

old value: $0090 new value: $00d7

2600basic_variable_redefs.h (49): error: EQU: Value mismatch.

old value: $0091 new value: $00d6

2367 bytes of ROM space left

2600basic.h (34): error: EQU: Value mismatch.

old value: $00d7 new value: $0090

2600basic.h (35): error: EQU: Value mismatch.

old value: $00d6 new value: $0091

2600basic_variable_redefs.h (47): error: EQU: Value mismatch.

old value: $0090 new value: $00d7

2600basic_variable_redefs.h (49): error: EQU: Value mismatch.

old value: $0091 new value: $00d6

2367 bytes of ROM space left

--- Unresolved Symbol List

 

Fatal assembly error: Source is not resolvable.

 

> Terminated with exit code 0.

 

I know that value mismatch usually means that I'm trying to set something with a value type it doesn't accept, but I can't see in the program where it is happening.

 

Program is (note- this is different than the other file I posted previously in diff topics with same name):

ultindy500_0.1.bas

Edited September 9, 2007 by Fort Apocalypse

[CurtisP]

To figure this out. I compiled the program, then opened the file 2600basic_variable_redefs.h and looked at lines 47 and 49 as listed in the output window. These lines are

  currentpaddle = b
 
 paddle = a

Looks like you tried to assign these variables in yoru program. However, they are already defined by bAtari Basic when the readpaddles kernel option is set, so you are actually attempting to redefine them, which the assembler doesn't like.

 

I took out the lines

  dim paddle=a
 dim currentpaddle=b

and it compiled succesfully.

[SeaGtGruff]

Could anyone help me figure this out? TIA!

This is caused by trying to define some equate names that have already been defined. Do you have your compile batch set up to generate an assembly listing? If not, what you can do is add "-l%1.lst" to the DASM command line (I posted a 2600IDE batch for atari2600land in the Zyx thread, if you want to see what I mean). Anyway, I looked at the assembly listing, searched for "error," and after skipping past the first two instances I found the culprit. You're trying to do this in your program:

 

   dim paddle=a
  dim currentpaddle=b

However, those names are already defined by batari Basic in one of the header files. If you take out those two lines and recompile, it will work.

 

I see you've switched to the standard kernel, since the multisprite kernel doesn't support the paddles. Since you're flickering between three frames, the flickering is kind of bad. I wonder if you could flicker between just two frames somehow, such as by changing the pitstop to use the missiles and ball, or just drawing it differently... maybe like shown below?

 

Michael

[CurtisP]

I see you've switched to the standard kernel, since the multisprite kernel doesn't support the paddles. Since you're flickering between three frames, the flickering is kind of bad. I wonder if you could flicker between just two frames somehow, such as by changing the pitstop to use the missiles and ball, or just drawing it differently... maybe like shown below?

 

I agree. Television is actually interlaced: two 60th second frames make up a single 30th second frame. The phosphors last about a 30th of a second, so there should be very little flicker on an actual 2600.

[SeaGtGruff]

I see you've switched to the standard kernel, since the multisprite kernel doesn't support the paddles. Since you're flickering between three frames, the flickering is kind of bad. I wonder if you could flicker between just two frames somehow, such as by changing the pitstop to use the missiles and ball, or just drawing it differently... maybe like shown below?

 

I agree. Television is actually interlaced: two 60th second frames make up a single 30th second frame. The phosphors last about a 30th of a second, so there should be very little flicker on an actual 2600.

I'll try it on a TV later with my Krokodile Kart. By the way, if you scroll the playfield up so the last row is partially visible, the track will look a little better. Try using this where you draw the playfield:

 

   playfield:
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  X..............................X
  X..............................X
  X..............................X
  X......X.....XXXXXX.....X......X
  X......XX..............XX......X
  X......XXXXXXXXXXXXXXXXXX......X
  X......XXXXXXXXXXXXXXXXXX......X
  X..............................X
  X..............................X
  X..............................X
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

  pfscroll upup : pfscroll upup
  return

Michael

[SeaGtGruff]

Also, if the right half of the track will always be a mirror image of the left half, then it might be possible to create a customized version of the standard kernel that doesn't draw an asymmetrical playfield, and maybe that uses a ROM playfield (like the multisprite kernel) instead of a RAM playfield. If that could be done, then you could get a higher vertical resolution for the playfield, and extend it all the way to the edges of the screen, which should let you draw an oval track.

 

Michael

[Fort Apocalypse]

Also, if the right half of the track will always be a mirror image of the left half, then it might be possible to create a customized version of the standard kernel that doesn't draw an asymmetrical playfield, and maybe that uses a ROM playfield (like the multisprite kernel) instead of a RAM playfield. If that could be done, then you could get a higher vertical resolution for the playfield, and extend it all the way to the edges of the screen, which should let you draw an oval track.

 

Michael

 

Man, that would be totally awesome! I think a symmetrical playfield would be totally fine, and getting a higher vertical resolution would be really great for for better looking turns and for an oval track! Let me know if you think you might have time to help with that or if you could give me some pointers to how it could be done. I wish I had your asm programming ability! (Unfortunately between college and years of raising children, my mind is even less of a steel trap than it used to be. Even before that it was just small mouse trap.)

 

And thanks for helping me figure out the paddle issue! (that was an artifact of me trying to get it to work with multisprite, which of course never would work!)

[Fort Apocalypse]

Do you mind checking this out on a real 2600 to see if it flickers? I switched to reuse missile 1 for the flag (both flagpole and flag) and dropped the pit since you set up a nice looking pit that I can just check x and y to determine if it is in the pit.

 

Here is the one with the latest changes (no more compile error):

ultindy500_0.1.basultindy500_0.1.bin

[SeaGtGruff]

Do you mind checking this out on a real 2600 to see if it flickers?

Sure thing, but it won't be tonight.

 

Michael

[Fort Apocalypse]

Do you mind checking this out on a real 2600 to see if it flickers?

Sure thing, but it won't be tonight.

 

Michael

 

No problem! It might make more sense to just wait until the game is closer to completion anyway. I'm sure that it could get more noticeable as I'm adding more logic to it.