9 replies to this topic

[Hornpipe2]

Got a question about the two Wizard ROMs I have. These are straight from Rom's Collection V2. The second one ( [a] version ) is the same as what AtariAge hosts, although on AtariAge it is an overdump.

There is a one-byte difference in these files, the second-to-last (byte 2047). It's some kind of lookup table, I think, and is $13 in the [a] version, but $00 in the base. I do not know what this controls.

Can anyone help me understand either a) which of these versions is 'more recent', or b) what the gameplay difference is between them? My instinct says that the $13 is the more recent value, because as a programmer I'd be more inclined to put 0 for a value in a table that I was unsure of rather than $13, but this is completely unscientific.

Attached Files

•  Wizard__1980___Atari__Chris_Crawford___Prototype_.bin   2K   106 downloads
•  Wizard__1980___Atari__Chris_Crawford___Prototype___a_.bin   2K   82 downloads

[Omegamatrix]

I too would like to know where the two versions came from. This might help you Hornpipe2:

http://www.atariage....s...t&p=1471526

[Hornpipe2]

Omegamatrix, on Thu Apr 17, 2008 5:22 PM, said:

I too would like to know where the two versions came from. This might help you Hornpipe2:

http://www.atariage....s...t&p=1471526

Interesting!

Like the Indy 500 dumps in that thread, we have a chance at figuring this one out. According to the disassembly the different byte is not (just) the BRK vector - something in the code is actually reading that data and using it. Perhaps someone more used to reading distella-generated ASM files could look into it and offer some insight.

[Omegamatrix]

Hornpipe2, on Thu Apr 17, 2008 4:02 PM, said:

According to the disassembly the different byte is not (just) the BRK vector - something in the code is actually reading that data and using it.

Did you make a disassembly of this? What part of the code is using the BRK vector?

[Hornpipe2]

Here's the disassembly of the [a] version, produced by DISTELLA.EXE -pafs WIZ.BIN > WIZ.S
Check out the very last line: LF7FE: .byte $13,$24
In the non-[a] version this is LF7FE: .byte $00, $24

It is referenced in line 286:
LDA LF7FE,X ;4
STA $CD ;3
(I believe X is holding the current frame - loaded from location $CE - which cycles 0-1-0-1 around line 282 LF1C3)

$CD is used before then in at least one place:
LF1AD: DEC $CD ;5
BEQ LF1C3 ;2

Judging by the presence of AUDC0 nearby I am guessing this has something to do with sound, but I have no real idea. Clearly this is not being used as a BRK vector though, because it isn't pointing anywhere useful.

Attached Files

•  wiz.zip   4.48K   62 downloads

Edited by Hornpipe2, Sat Apr 19, 2008 9:19 PM.

[Omegamatrix]

This is getting more interesting now. I'm just a dabbler in ASM so I really don't know either. I think it's adding the content of $F7FE with the current value of the X register and storing it at memory location $CD. If I'm reading it right that is $2413 with whatever is in X. What is the value of $CD used for then? I would take more of a crack at this but not to much time for a few weeks yet until exams are over. I did disassemble it a bit more adding the graphics if that helps you.


 WizardA.zip   6.02K   61 downloads

[Nukey Shay]

Omegamatrix, on Sat Apr 19, 2008 11:49 PM, said:

If I'm reading it right that is $2413 with whatever is in X.

No...$CE flipflops between a value of 0 and 1. This is loaded to the X register, and then used as a pointer for the table at $F7FE. So either the value of #$13 or #$24 is put into the accumulator, and stored to $CD. The other version of the game uses values #$00 and #$24. When the program reduces the ram location $CD (via DEC) and it counts down to zero, $CE is flipped (EOR #$01). So the values are used every -other- time.

Quote

What is the value of $CD used for then?

The "dirty" way of discovering what a ram location controls is to ignore it. Try altering the DEC/BEQ combo to be 4 NOP's (so that there is no branch) and run it, then alter the DEC/BEQ to be a BNE/BEQ (so that a branch always happens).

What you will find is that the background "thump" sound effect is constant with the latter. When using 4 NOP's, there is no sound effect at all. Because a DEC (decrease ram by 1) would only happen once per frame, the differing values would give you 2 delays for the sound effect (thump-thummmp, thump-thummmp). I guess the programmer noticed that loading a value of zero could possibly cause the DEC to wraparound (or it was a dropped byte when the rom was dumped). So the 2 values are a period of silence between the thumps heard when near the enemy.

In any case, it appears that the [a] bin is the correct version (to avoid a possible rollover error). No proof, but it seems logical.

Rom locations $F7EE to $F7FB are unused...so if it's desired to add an interrupt subroutine to the program, just move the 2-byte table there.

Edited by Nukey Shay, Sun Apr 20, 2008 4:33 AM.

[Nukey Shay]

Hornpipe2, on Sat Apr 19, 2008 8:18 PM, said:

Clearly this is not being used as a BRK vector though, because it isn't pointing anywhere useful.

...more exactly, no BRK's exist in the code

[mos6507]

If only a bad dump could explain why this game is so bad There is a reason why we omitted it in favor of Polo on the first Supercharger CD.

Edited by mos6507, Sun Apr 20, 2008 4:42 AM.

[Omegamatrix]

Nukey Shay, on Sun Apr 20, 2008 3:04 AM, said:

Omegamatrix, on Sat Apr 19, 2008 11:49 PM, said:

If I'm reading it right that is $2413 with whatever is in X.

No...$CE flipflops between a value of 0 and 1. This is loaded to the X register, and then used as a pointer for the table at $F7FE. So either the value of #$13 or #$24 is put into the accumulator, and stored to $CD. The other version of the game uses values #$00 and #$24. When the program reduces the ram location $CD (via DEC) and it counts down to zero, $CE is flipped (EOR #$01). So the values are used every -other- time.

Quote

What is the value of $CD used for then?

The "dirty" way of discovering what a ram location controls is to ignore it. Try altering the DEC/BEQ combo to be 4 NOP's (so that there is no branch) and run it, then alter the DEC/BEQ to be a BNE/BEQ (so that a branch always happens).

What you will find is that the background "thump" sound effect is constant with the latter. When using 4 NOP's, there is no sound effect at all. Because a DEC (decrease ram by 1) would only happen once per frame, the differing values would give you 2 delays for the sound effect (thump-thummmp, thump-thummmp). I guess the programmer noticed that loading a value of zero could possibly cause the DEC to wraparound (or it was a dropped byte when the rom was dumped). So the 2 values are a period of silence between the thumps heard when near the enemy.

In any case, it appears that the [a] bin is the correct version (to avoid a possible rollover error). No proof, but it seems logical.

Rom locations $F7EE to $F7FB are unused...so if it's desired to add an interrupt subroutine to the program, just move the 2-byte table there.

Now that makes sense, and you answered a couple of other questions I have, Nukey. Only one byte is ($24 or $13) is added with value of X in the accumulator. I can see how it cycles with EOR flipping 1, 0 ,1 ,0 too.


I like the dirty hack. I'm going to stick with the alternate version as the correct rom, and equate the original as a WIP, bad dump, or bugged version. Anyhow this is the good one then:

 Wizard__Prototype_.bin   2K   92 downloads