WC Baseball crash screen

[tacrec]

Haven't seen this one before...

[+Lathe26]

I've always wondered what the WC Baseball crash screen looked like.

[m-crew]

Da Vincillivision Code

[Eric7100]

I'm pretty sure that's the amount of money that Cmart has.

[JohnPCAE]

Interesting that it's in hexadecimal. Code for a bitmap image?

[mr_me]

I think one of the programmers at Mattel was trying to troubleshoot problems in this game. I think code was added to dump the register contents (cpu or stic?) when this crash happens.

[+BBWW]

Who put my password in WC Baseball.

[m-crew]

When it crashes for me it was just a solid green screen..

[decle]

Interesting. The first 32 characters look like they might be a CP1610 CPU register dump:

10a0 - R0 - ?
1217 - R1 - ?
5737 - R2 - address
0007 - R3 - ?
5c28 - R4 - index register address
5f5d - R5 - index register address
031d - R6 - stack pointer
5437 - R7 - PC address

From there things are less clear, it could be STIC or PSG register dumps, or perhaps more likely RAM. There is enough screen space to display a further 52 16-bit numbers, or 104 8-bit numbers.

A quick scout around the code at $5437 is not immediately enlightening, at least not to me.

 

Edit: It occurs to me that if this is the version of WC Baseball being used for the league, DZ-Jay's changes may mean that my looking at the disassembly of the standard version is probably not terribly helpful.

Edited June 9, 2017 by decle

[+Lathe26]

Did the baseball league go on strike?

[bikeguychicago]

Is the the result of the 'sophisticated' game play?

[atarifan88]

That's not a crash screen! THOSE ARE LAUNCH CODES FOR LAUNCHING THE MISSILES!!!

 

 

The only way to win is not to play! How about a nice game of chess?

 

Edited June 9, 2017 by atarifan88

[BassGuitari]

I've always wondered what the WC Baseball crash screen looked like.

I didn't even know there was one!

[+Rick Reynolds]

Not to toot our own horn, but we Intellivisionaries talked a bit about the crash screen in ep7 and posted a screenshot of the crash screen in the show notes for ep8: http://intellivisionaries.com/episode-8-sea-battle/

[decle]

Haven't seen this one before...crash.gif

 

 

Not to toot our own horn, but we Intellivisionaries talked a bit about the crash screen in ep7 and posted a screenshot of the crash screen in the show notes for ep8: http://intellivisionaries.com/episode-8-sea-battle/

 

Hi all,

 

I was rather intrigued by the fact that the two crash screens submitted by Rick and tacrec are identical. So, with JoeZ's help I have been looking into the World Championship Baseball crashes a bit more. To do this we have focused on the computer vs computer games played at difficulty level 3, like those used in the Intellivision Baseball League.

 

It looks as though, providing the controller is not touched during play, there might "only" be 65,535 distinct computer vs computer games at a particular speed and difficulty setting. Furthermore, with a bit of jzIntv footling, it is possible to set things up to play any one of these games. It is also possible to work out at the end whether the game crashed, and what the final score was if it didn't. Finally, if jzIntv plays games at its fastest possible speed each lasts less than 5 seconds. Therefore, it is possible to play every single game at a given speed and difficultly level in less than 2 computer days. This compares to more than 2.5 years of continuous play at normal speed.

 

Well, we have played all 65,535 computer games at skill level 3 and the fastest speed

 

So, what did we discover?

• WCB is very timing sensitive. Small differences between versions of jzIntv result in very different outcomes, both in terms of crashes and game scores. As a consequence, everything reported here is only applicable to the game being played on the latest, greatest, 20170708 version of jzIntv. It does not necessarily reflect what would be found on a real Intellivision.
• As expected crashes are relatively rare, only 5.7% or about one game in 18 ends in a crash.
• There are 3 different ways in which the game can end prematurely, only one of which will result in a debug screen being visible to the typical user.
  • The program can just crash mid game as the processor goes off into the weeds. If this occurs on a real Intellivision the screen will probably just go blank.
  • An error condition can be detected and the debug screen displayed. Somewhere around 2.5% of all games (one game in 40) will end this way on jzIntv.
  • The debug screen can be displayed and then the game hard crashes. Again, if this occurs on real hardware it will probably result in a black screen.

Here are the numbers:

• Total Games: 65,535
• Games successfully played to completion: 61,802
• Games that show the debug screen: 1,638
• Games that crash without showing the debug screen: 40
• Games the show the debug screen and then crash: 2,055

For those interested in the debug screen itself, it would seem that it is a dump of the System RAM content from address $2f0 upward. The reason that the first bit looks to be a register dump is that this region of memory starts with the program stack. So, we are probably seeing the register state that was pushed onto the stack at a previous VBLANK interrupt. The screen is drawn when the CPU stack grows too large. There are only 26 distinct patterns of data seen on the 1,638 debug screens. The most common screen is this one, which is seen at the end of 632 games.

 

 

If you want to see this behaviour for yourself you can use the following jzIntv script files with your vanilla copy of WCB. The script files are used as follows:

jzintv.exe -z1 -r2 -d –script=path\to\commandScript.txt path\to\yourWcBaseballRom.bin

I recommend replacing -r2 with -r0 when watching long games, to make things go as quickly as possible. These scripts have been tested against the new 20170708 stable version of jzIntv. Because of the sensitivity to timing, they almost certainly will not give the same results with other versions and obviously there is no way to use them on real hardware. Here are script files that show:

• The most common debug screen: debug.txt
• A hard crash with no debug screen: crash.txt
• A hard crash with a debug screen: debugCrash.txt

We can also get some “interesting” information about the games that finish without crashing. For example:

• The average game has 9.8 innings, but the longest completed games last 23 innings: 23innings.txt
• The Home team wins 31,935 games and their biggest margin of victory is 10 runs: 0-10.txt
• The average Home team score is 1.71 runs, and their biggest score is 11 runs: 1-11.txt
• The Visitors win 29,867 games and their biggest margin of victory is 9 runs: 10-1.txt
• The average Visitor score is 1.68 runs, and their biggest score is 12 runs: 12-8-1.txt
• The highest scoring games are 12-8 victories for the Visitors: 12-8-2.txt

So, there is a small bias toward the Home team winning. Comparing these numbers with the current Intellivision Baseball League season of 52 games we see that the games lasted an average of 9.6 innings. The Home team have won 35 of the games with an average score of 1.69 runs with the Visitors winning the remaining 17 games scoring an average of 1.44 runs. Therefore, the Home teams have been doing rather better than expected this season. Again, it should be noted that two different versions of jzIntv will have been used by tacrec and myself, and this will have a potentially significant bearing on the results.

 

For the curious, here is a plot of the scores of all the games and their frequency:

 

 

And the full set of results:

 

results.txt

 

It is possible to play any of these games if you search for and replace the text GAME_NUMBER with the hex value of the game number you want in the following jzIntv script:

 

template.txt

 

If you play both of the 8-12 Visitor win games above you may notice they look to be the same. In fact, they are two different games (#0052 and #0104), so what is happening? It would seem that although some games might start with different random number seeds, the way in which the random numbers are generated and used leads to them merging. By the end of the game they have the same seed value, having played the same game. Remember, it is unlikely that WCB will ever need a random number across the full range of 1 to 65,535. Instead it might need a number from 1-10, for example. According to Joe, the way in which the EXEC works is that in this case it will choose a number from 1-16 (16 being the smallest power of 2 greater than 10). If the number selected is between 11 and 16 the EXEC just throws it away and tries again until one is generated in the required range. This approach of skipping over some numbers will make the seeds used tend to a subset of values and the games to merge. This leads to a couple of questions.

 

Firstly, how many really distinct games are there in the set of 65,535 looked at? Unfortunately, I don’t know, the number of games in each merged set varies and just defining what constitutes an equivalent game is potentially problematic. We can say that there are at least 210 unique games, based on the final scores and number of innings.

 

Secondly, by seeing the results of merged games are we “missing” other possible game outcomes? Again, I’m not sure. If you look at the way in which the game scripts work, they inject the state of the Intellivision that I captured during the initialisation of a single, real game. Variations in this state might open up other results, for example the 1-5 Mutants win over the Snakes after 11 innings in the Intellivision Baseball League on 04/17 is not found in this data set. If differences in this initial state are important, identifying which bits WCB is sensitive to, and all the valid combinations of the sensitive portion is probably an enormous task. That said, using a couple of different captured states does not appear to change the results, so the fact that this game is missing could also be down to the different version of jzIntv used.

 

Some of you may be wondering what happened to the 65,536^th game. Well, game 0 is never selected or played by the EXEC. This is because, like all random number generators based on Linear Feedback Shift Registers (LFSR), the one in the Intellivision EXEC does not work with the seed value 0. If game 0 was selected, the random number generator would just churn out 0, and at level 3 this leads to a never-ending game:

 

level3Game0.txt

 

It is a good job this cannot happen without specifically setting it up. The same 0^th game at difficulty level 4 is rather more interesting:

 

level4Game0.txt

 

It still results in a never-ending game, with neither side able to score. However, some progress is able to be made, and if you are patient enough you will see that the programmers never intended a game to have more than 99 innings (minimising the jzIntv window speeds things up). Above this value punctuation characters are used for the left inning digit. This punctuation continues through to inning 128, after which the inning value resets to 1.

 

 

I think at is about it for this post. Of course, having used our more advanced debugging and computing resources to make the WCB bugs reproducible, the real objective is to try to understand why the crashes occur, and potentially fix them. But, that is for another day.

 

My sincere thanks to Joe for his insights and jzIntv help, without which this analysis would not have been possible. As always, all feedback is most welcome (and yes Rick, I know this is not a game. By the way, how is the RCA Studio II podcast coming? )

 

 

Cheers

 

decle

[Tempest]

Neat!

[tacrec]

Wow. Great and interesting breakdown. I didn't know a new version of jzintv existed, so I'll use that for the football league this fall.

 

The IBL has a real home field advantage! I never noticed that.

 

It only took 13 games to get 8 runs? It took me 3.5 years to get above 6!

Edited July 13, 2017 by tacrec

[+Lathe26]

Cool!

[mr_me]

So you can consistently reproduce the error; that's amazing. I'm not sure what's going on in the script; are you replacing random events with something specific? How does one number change generate an entire consistent game?

[intvnut]

So you can consistently reproduce the error; that's amazing. I'm not sure what's going on in the script; are you replacing random events with something specific? How does one number change generate an entire consistent game?

 

When pitting the computer against itself, the computer player's actions are driven entirely by the EXEC's random number generator. Also, I believe some aspects of the game itself are driven by the EXEC's random number generator, whether or not you have computer opponents.

 

"Random" is a misnomer. It's actually a pseudo-random number generator (PRNG), built from a linear feedback shift register (LFSR). LFSR based PRNGs always produce the same sequence of random bits. A 16-bit LFSR with a maximal period will go through 65,535 states before looping back to the beginning.

 

The current state of the LFSR is commonly referred to as the seed. You can get a different game by starting the seed at a different value. It will still go through the same overall sequence, but the sequence will start at a different point.

 

What decle's doing is pretty straightforward: He's setting the seed to a fixed value at the very start of the game. There are 65,535 unique starting values for the 16-bit seed that do anything useful, so that makes for 65,535 unique computer-v-computer games, assuming no other inputs to the process. (The all-0s value behaves very badly.) The "no other inputs" part is important, which is why he stresses not touching the controllers. A larger variety of games is possible if you consider every possible perturbation to the RNG sequence due to outside influences (e.g. us hairless apes banging on controllers).

 

Here is the exact code for the EXEC's LFSR PRNG. This could have been written much more efficiently, sadly. It's a Fibonacci realization of a 4-tap LFSR. A Galois realization (such as what RAND_FAST uses) would have been more efficient. This guy takes 97 cycles to compute one new random bit, while the RAND_FAST approach (which is just as strong mathematically) takes 12 to 19 cycles/bit.

.

X_RAND1:
        PSHR    R5                              ; 167D  
        MOVR    R0,     R5                      ; 167E  
        BEQ     L_17D4                          ; 167F  
 
        PSHR    R1                              ; 1681  
        PSHR    R2                              ; 1682  
        CLRR    R2                              ; 1683  
        MVI     G_035E, R0                      ; 1684   R0 = seed
 
L_1686: SLL     R0,     2                       ; 1686   R0 = seed << 2 
        SLL     R0,     2                       ; 1687   R0 = seed << 4 
        MOVR    R0,     R1                      ; 1688   R1 = seed << 4 
        XOR     G_035E, R0                      ; 1689   R0 = seed ^ (seed << 4)
        SWAP    R1,     1                       ; 168B   R1 = (seed << 12) | (seed >> 4)
        SLL     R1,     1                       ; 168C   R1 = (seed << 13) | ((seed >> 3) & ~1)
        XORR    R1,     R0                      ; 168D   R0 = seed ^ (seed << 4) ^ (seed << 13) ^ ((seed >> 3) & ~1)
        SLL     R1,     2                       ; 168E   R1 = (seed << 15) | ((seed >> 1) & ~7)
        XORR    R1,     R0                      ; 168F   R0 = seed ^ (seed << 4) ^ (seed << 13) ^ (seed << 15) ^ ((seed >> 3) & ~1) ^ ((seed >> 1) & ~7)
;... so far pretty impressive, right? Now the really depressing part:
        RLC     R0,     1                       ; 1690   C = ((seed >> 15) ^ (seed >> 11) ^ (seed >> 2) ^ (seed >> 0)) & 1
        MVI     G_035E, R0                      ; 1691   R0 = seed
        RLC     R0,     1                       ; 1693   R0 = (seed << 1) | (((seed >> 15) ^ (seed >> 11) ^ (seed >> 2) ^ (seed >> 0)) & 1)
        MVO     R0,     G_035E                  ; 1694   seed = (seed << 1) | (((seed >> 15) ^ (seed >> 11) ^ (seed >> 2) ^ (seed >> 0)) & 1)
;... yep, all that computation just to generate one stinking bit. 
        SETC                                    ; 1696 
        RLC     R2,     1                       ; 1697
        DECR    R5                              ; 1698 
        BNEQ    L_1686                          ; 1699

.

 

I imagine part of the reason the process is so timing sensitive is that the EXEC pumps the random number generator in its idle loop. A slight change in the amount of idle time will change the exact sequence of random numbers, and thus the evolution of the game.

 

The recently released jzIntv fixes a long-standing issue where the CPU reacted slightly differently to BUSRQ and INTRQ depending on whether you were single-stepping or running flat out. Also, different audio rate settings could affect the CPU's behavior here. I rewrote a big chunk of jzIntv's CPU <=> STIC interaction to clean that up.

 

In the process, I also made a few minor optimizations, so that '-r0' mode runs significantly faster, especially when combined with -a0. I also added a jzintv_batch build that has zero connection to SDL and runs fully headless. It runs even faster still with -r0 -a0. Given the magnitude of the change, it's always possible something else ended up slightly off. If you notice anything, please let me know.

 

Edited July 14, 2017 by intvnut

[Eric7100]

The code is the answer, and the answer is the code.