Rom Variants Auto Racing etc.

[intvnut]

BTW, there's a minor "bug" with my patch. If you don't select a number of laps, but rather just hit 'enter' for that prompt, it'll set you to 0 laps. 0 laps means you'll "win" after your first crash / ahead / whatever.

[pimpmaul69]

Cool. Thanks. Now i might play it some. Never knew how to play one player so i just assumed it was 2 player only

[pimpmaul69]

BTW, there's a minor "bug" with my patch. If you don't select a number of laps, but rather just hit 'enter' for that prompt, it'll set you to 0 laps. 0 laps means you'll "win" after your first crash / ahead / whatever.

at least there is a "workaround" plus its kind of a fun bug Edited September 17, 2015 by pimpmaul69

[intvnut]

at least there is a "workaround"

 

And you can "quote" me on it.

[+intvsteve]

...

With the GUI, you'll be able to cut out some of the steps. If you have the ROM in 'bin' format, you can make a copy of the .bin, and put the patch .cfg next to it, and add that to your LTO Flash! cart. When it gets pulled in the patch will get applied.

Hmm... you actually just raised a test case that I need to inspect more closely. Specifically, the ROM list may be filtering very strictly on ROM CRC to keep down duplicate entries. I'll need to check to see if it's also accounting for .cfg differences when a .bin+.cfg pair is found. I honestly cannot remember - that code's been untouched for a long time.

[freewheel]

I can't remember anymore, but is there any advantage to bin+cfg? Seems like it's almost universally a hassle for people.

[intvnut]

I can't remember anymore, but is there any advantage to bin+cfg? Seems like it's almost universally a hassle for people.

 

1. Available from official sources (Intellivision Lives! and Intellivision Rocks!)
2. Support for paged ROMs
3. Support for patches via 'pokes' (such as I posted in this thread)
4. Support for configuration variables to control enabling/disabling various peripherals. Not used for much of anything yet, but will be. (I will be using this to control whether JLP features get enabled, and the recent IntyBASIC updates modulate these variables accordingly, for example. I need to get jzIntv on board with this too.)
5. Simpler / more hackable. Only useful to bitfiddlers like myself, though.

Edited September 18, 2015 by intvnut

[+Lathe26]

I think there is an extension feature of the ROM file format. Could that be used to add support for #2 and #4? Of course, emulators would need to be updated but that is already needed for #4 with cfg files anyways.

[intvnut]

Ok... something even weirder. The 'deeper grass' is in both versions. It just doesn't work nearly as well in the Directional/Intuitive version. It barely slows down the car, if at all, it seems.

 

What's odd is that how it's implemented in the Real Steering version is enough different that I wonder if Larry Zwick (or whomever did the upgrade) "over-corrected" when trying to make it work. There's no other good explanation for the differences that I can come up with right now.

 

I've seen enough other stretches of code, though, to suggest the Real Steering version is definitely the newer one, and the Intuitive/Directional version is almost w/out a doubt the older.

 

One weird example: This function appears in both versions. However, it's only called in the Directional/Intuitive version. In the Real Steering version, there is a much more clever (and faster, but oddly not smaller) sequence at the call site, causing this function to become dead code!

.

; Compute the MOB record base address given the player number in R1. 
; MOB 0..3 are player 0, MOB 4..7 are player 1
L_58B3:
        SLL     R1,     2                       ; 58B3   004D
        SLL     R1,     2                       ; 58B4   004D
        SLL     R1,     1                       ; 58B5   0049
        ADDI    #$031D, R1                      ; 58B6   02F9 031D
        MOVR    R1,     R4                      ; 58B8   008C
        MOVR    R5,     R7                      ; 58B9   00AF

.

In the Intuitive/Directional version, this function is called exactly once, here:

.

L_5813:
        MVI     G_0194, R1                      ; 5813   Read player number 
        JSR     R5,     L_58B3                  ; 5815   Convert to MOB ptr

.

In the Real Steering version, you instead see:

.

; R1 currently holds a pointer to the player record in 8-bit RAM.  
; Player records are 16 bytes.  The player's MOB data is 32 words in 16-bit RAM.
; This code converts the player record pointer to a MOB data pointer by doubling 
; it, and adding an offset, in an attempt to save codesize.
L_5806:
        SLL     R1,     1                       ; 5806   Multiply pointer to player data by 2
        SDBD                                    ; 5807  
        ADDI    #$0039, R1                      ; 5808   Add correction factor so R1 points to MOB data

.

What's doubly weird about this is that it should save codesize, but it doesn't. The assembler inserted an SDBD in there, probably because it couldn't prove (until link time) that the data in 8-bit RAM and the data in 16-bit RAM were close enough that it could omit the SDBD. (Having used many assemblers over the years, I'm waaaay too familiar with this class of phase-ordering problem.)

 

So... it's faster, but not smaller, and it resulted in dead code elsewhere. Given that the ROM just fits, this smells like a "find code to tweak anywhere you can find it, and tweak it until it fits" kind of maneuver, and this one just didn't happen to pan out. If he'd managed to get it right, he could've saved quite a bit more code space—8 decles total.

 

Oh, and the Real Steering version (but not the Intuitive/Directional version) has a real gangsta way to divide a number by two, rounding up:

.

        SARC    R0        	; 59CB   divide number in R0 by two
        ADCR    R7        	; 59CC   ... jumps into middle of next instr if carry is set!
        ADDI    #$0008, R3	; 59CD   If ADCR R7 taken, this ADDI becomes INCR R0, rounding up

.

In general, whoever wrote Auto Racing was very comfortable with using arithmetic involving the program counter. I see many ADDI/SUBI instructions directly modifying the program counter (as opposed to, say, a branch instruction), as well as many pointers-to-table generated with PC-relative computations. For the latter, I believe they had a standard macro for that.

 

For the former, I believe I saw somewhere (and in nearly 20 years of staring at Intellivision stuff, I couldn't tell you exactly where) that their linker had a limitation that prevented branches between different link modules. You could do jumps (which are 3 decles and 13 cycles), but not branches (which are 2 decles and 9 cycles). Unlike AS1600, their tools supported linking multiple assembly files after the fact, while AS1600 requires the entire program in one piece, stitched together with INCLUDEs. If that's the case, then the ADDI/SUBI on the program counter may have been a hack to get around that tooling limitation.

 

And I did see at least on case where a jump got optimized to and ADDI. In the Intuitive/Directional version:

.

        J       L_51C7                          ; 548B   0004 0350 01C7

.

The corresponding instruction in Real Steering:

.

        SUBI    #$02B5, R7      	; 547D   branch to $51CA (size optimized)

.

This saves one whole decle. Wild, eh?

Edited September 19, 2015 by intvnut

[+Lathe26]

I had to stare at the code but it actually... started... making... sense.

 

That code is so gangsta that it killed Tupac Shakur.

[intvnut]

I had to stare at the code but it actually... started... making... sense.

 

That code is so gangsta that it killed Tupac Shakur.

 

Here's what I don't get: Most folks would have settled for:

.

        SARC    R0     ; shift right, putting shifted away bit in carry
        ADCR    R0     ; add carry to R0, rounding up

.

Why all the extra complexity? I guess the code also needs to modify R3 to be correct, as the following code does do something with R3.

 

Here's a more complete snippet. It's dividing by 2, and depending on what happens, modifying R0 or R3... Rather fortunate that the opcode for INCR R0 is what he needed here. Like I said, gangsta!

.

	MVII    #$0003, R0	; 59C6   02B8 0003
		
	JSR     R5,     X_RAND1	; 59C8   0004 0114 027D
	SARC    R0      	; 59CB   divide number in R0 by two
	ADCR    R7      	; 59CC   ... jumps into middle of next instr!
	ADDI    #$0008, R3	; 59CD   If ADCR R7 taken, this becomes INCR R0, rounding up
L_59CF:		
	MVO     R0,     G_019B	; 59CF   0240 019B
L_59D1:		
	MOVR    R3,     R5	; 59D1   009D

Edited September 19, 2015 by intvnut

[intvnut]

I just figured out what that whole stretch of code is doing.

 

All Some of the trees are randomly generated. If a cell in the map says "This cell might have tree," there's a certain percentage chance that a tree actually appears in that cell when it gets displayed. Lap-to-lap, the trees will actually change, unless I'm sorely mistaken.

 

And, surprising nobody by this point, the algorithm is slightly different between the two versions.

 

EDIT: As I look more closely, I see now that only some of the trees are random, and many/most are fixed. I edited my statement above accordingly.

Edited September 19, 2015 by intvnut

[1980gamer]

Ah yes, random trees.

Some short cuts always work, some don't because a tree was "planted" or randomly generated that is.

 

I wonder if they did this.... thinking we would explore the global map?

 

I can also see leaving the "around the world" path open on course 1 for long duration testing of counters, time keeping etc.

 

That's what I would do ( and still do when working with old tools with no debugger etc. )

[mr_me]

I had written Dave Rolfe about Auto Racing a few weeks ago. I thought maybe I had the wrong email address and then I got a reply a couple of days ago.

--------------------------------------------

...As I recall, Larry Zwick programmed Auto Racing as one of our first summer hires in 1978. Larry took that game because he was a very enthusiastic driver; too enthusiastic, in fact, in that he wrecked his car, with me and two other APh staffers in it, driving dangerously in the rain coming home from a Tommy’s (downtown) run. We were all okay, but the car was totaled. That was when I was young and, you know, invulnerable. I’ve taken driving a lot more seriously since then. By the way, that wasn’t the only car Larry wrecked. In retrospect, maybe he was compulsively living on the edge because he’d survived a skin cancer that tends to kill people – and indeed, it came back and he died of it a few years later. So I guess we can’t go to the source to answer your question, at least not in this life. Very sad; Larry was a great guy, although there were moments when I wanted to throttle him.

 

I do remember discussions of the Auto Racing steering options, but the details are very vague at this point. I perused the thread you linked, but I’m trying to put it out of my mind right now and just think of what I can remember. I think Larry favored the vehicle-oriented steering rather than the screen-oriented steering; as one that loved driving, he wanted to see it properly simulated. And the change to screen-oriented steering was made at the insistence of others, and that Larry maintained the secret option to revert because that was his favorite. I *think* that’s the way it went down, but I would not stake my life on it; it’s quite possible that what I just said is exactly backwards.

 

I don’t know how many changes were made between the versions; only Larry could answer that. I do recall, at least during initial development, he had some difficulties with the car being impeded when it did not appear to have strayed onto the grass, but the program was reacting as if it had. Or something like that. Larry humorously said he had a problem with “crabgrass”, which he eventually managed to solve. I wouldn’t be surprised if, once he opened up the code, he massaged some subtle aspects of the obstacles. But I’m just guessing.

...

--------------------------------------------

Edited October 12, 2015 by mr_me

[First Spear]

https://web.archive.org/web/20001002094650/http://www.cse.buffalo.edu/~mjhayes/misc/Cheats.txt

--------------------------------------------------
 
 Mattel Intellevision games:
 
 Transcribed verbatim off an old photocopy,
 we called them "Copyright Kludges" back then.
 The date style marks this compilation as the work of
 Chris Hawley
 [Notation: hold down indicated keys during powerup.]
 
                 Kluge file for Games- Updated 8107.13
 
 ROULETTE:               left = 13       right = 123
 SKIING:                 left = 57       right = 57
 WORD FUN:               press  43210 during word rockets mode
 ARMOR BATTLE:           left = 3        right = 9
 HORSE RACING:           left = 69       right = 69
 BOXING:                 left = lower two action keys and wheel direction 7
 SPACE ARMADA:           left = 46    OR    clear-enter
                           right = lower two action keys
 AUTO RACE:              pres  169 on any keypad to get real steering
 STAR STRIKE:            left = 19    OR    37
 FRENCH CASSETTE:        left = 19       right = 80
                           during introduction (menu #0); then exit to
                           monitor (menu #6)
 DEMO CASSETTE:          type "dei" (lower case) during space battle
 
--------------------------------------------------

[intvnut]

I've seen an even more inexplicable change in Las Vegas Poker and Blackjack. Between the two versions of the ROM, a two instruction sequence changed to a different two instruction sequence that's exactly the same size, takes exactly the same number of cycles, and does exactly the same thing. WTF? That's not a running change... that's a running stay-the-same! Or something.

; Poker 1978:
       MVI     G_01C1, R0                      ; 59A8   0280 01C1
       TSTR    R0                              ; 59AA   0080

; Poker 1979:
       CLRR    R0                              ; 59A8   01C0
       XOR     G_01C1, R0                      ; 59A9   03C0 01C1

 

BTW, I finally solved the Poker 78 vs. 79 difference. There's a sequence of non-interruptible instructions just before this. The CP1610 becomes interruptible after the first interruptible instruction completes. The sequence in Poker 79 becomes interruptible 4 cycles earlier than the sequence in Poker 78.

 

This sequence is right on the edge of being able to trigger a display glitch.

 

Apologies for the necro-bump. I was reminded of this thread by the recent "worst racing game ever" article that floated by.

[+DZ-Jay]

 

BTW, I finally solved the Poker 78 vs. 79 difference. There's a sequence of non-interruptible instructions just before this. The CP1610 becomes interruptible after the first interruptible instruction completes. The sequence in Poker 79 becomes interruptible 4 cycles earlier than the sequence in Poker 78.

 

This sequence is right on the edge of being able to trigger a display glitch.

 

Apologies for the necro-bump. I was reminded of this thread by the recent "worst racing game ever" article that floated by.

 

I wonder if it was a simple macro change which then prompted the programmers to rebuild their object code. After that, a simple checksum would reveal a change, prompting for a running update to the next production batch.

 

-dZ.

[intvnut]

 

I wonder if it was a simple macro change which then prompted the programmers to rebuild their object code. After that, a simple checksum would reveal a change, prompting for a running update to the next production batch.

 

I doubt it was a macro change. This was a really fiddly change that seems rather specific to this sequence of code.

 

Poker 78:

.

        SWAP    R0,     1                       ; 59A3   0040
        MVO@    R0,     R5                      ; 59A4   0268
        MVO@    R0,     R5                      ; 59A5   0268
        MVO@    R0,     R5                      ; 59A6   0268
        MVO@    R0,     R5                      ; 59A7   0268
        MVI     G_01C1, R0                      ; 59A8   0280 01C1
        TSTR    R0                              ; 59AA   0080

.

Poker 79:

.

        SWAP    R0,     1                       ; 59A3   0040
        MVO@    R0,     R5                      ; 59A4   0268
        MVO@    R0,     R5                      ; 59A5   0268
        MVO@    R0,     R5                      ; 59A6   0268
        MVO@    R0,     R5                      ; 59A7   0268
        CLRR    R0                              ; 59A8   01C0
        XOR     G_01C1, R0                      ; 59A9   03C0 01C1

.

The interruptibility issue is due to the SWAP + four MVO@. The total non-interruptible time in the Poker 78 version is 8 + 4*9 + 10 = 54 cycles. The total non-interruptible time in the Poker 79 version is 8 + 4*9 + 6 = 50 cycles. One scanline is 57 cycles, so it's highly likely the first caused occasional screen-jump glitches while the second didn't.

 

i doubt the last two lines (the ones that changed) came from a macro that changed. Further support for this thesis comes from the fact that other MVI/TSTR pairs appear in Poker 79, despite this one MVI/TSTR getting replaced with CLRR/XOR. If it were a macro change, you'd expect all instances of the macro in the same source to reflect the change.

 

Also, FWIW, Poker 78 and Poker 79 report different copyright dates on their title screens, so it wasn't just a blind recompile.

Edited January 10, 2019 by intvnut

[+DZ-Jay]

 

I doubt it was a macro change. This was a really fiddly change that seems rather specific to this sequence of code.

 

Poker 78:

.

        SWAP    R0,     1                       ; 59A3   0040
        MVO@    R0,     R5                      ; 59A4   0268
        MVO@    R0,     R5                      ; 59A5   0268
        MVO@    R0,     R5                      ; 59A6   0268
        MVO@    R0,     R5                      ; 59A7   0268
        MVI     G_01C1, R0                      ; 59A8   0280 01C1
        TSTR    R0                              ; 59AA   0080

.

Poker 79:

.

        SWAP    R0,     1                       ; 59A3   0040
        MVO@    R0,     R5                      ; 59A4   0268
        MVO@    R0,     R5                      ; 59A5   0268
        MVO@    R0,     R5                      ; 59A6   0268
        MVO@    R0,     R5                      ; 59A7   0268
        CLRR    R0                              ; 59A8   01C0
        XOR     G_01C1, R0                      ; 59A9   03C0 01C1

.

The interruptibility issue is due to the SWAP + four MVO@. The total non-interruptible time in the Poker 78 version is 8 + 4*9 + 10 = 54 cycles. The total non-interruptible time in the Poker 79 version is 8 + 4*9 + 6 = 50 cycles. One scanline is 57 cycles, so it's highly likely the first caused occasional screen-jump glitches while the second didn't.

 

i doubt the last two lines (the ones that changed) came from a macro that changed. Further support for this thesis comes from the fact that other MVI/TSTR pairs appear in Poker 79, despite this one MVI/TSTR getting replaced with CLRR/XOR. If it were a macro change, you'd expect all instances of the macro in the same source to reflect the change.

 

Also, FWIW, Poker 78 and Poker 79 report different copyright dates on their title screens, so it wasn't just a blind recompile.

 

Gotcha, so it seems it was a deliberate and targeted change to address a perceived issue. That makes sense. It's very clever that they managed to solve the problem in situ, without changing the ROM size or having to patch in a branch or something. The pattern of CLRR/XORR is interesting, and it has the exact same effect as MVI/TSTR, even changing the same flags.

 

Cool discovery!

 

-dZ.

[mr_me]

Sounds like a rom hack rather than going back to the assembler.

 

If anyone has the 1978 Poker & BJ cartridge it might very well be a test market cartridge. Do the earliest boxes with the "for color tv viewing only" text out of place or the full colour instructions have the 1978 or 1979 cartridge?

Edited January 10, 2019 by mr_me

[+intellivotion]

I've just tested a LV P&J cartridge without "insert to this line", which certainly came in a box with the full color manual, and it says 1979

[+intellivotion]

I've also checked my files and at least one copy I have is surely a 1978 cartridge: cart made in Hong Kong, box made in Hong Kong for the US market (I can't say now whether it's G1 or previous version), monochrome manual.

 

The International, made in HK carts I tried are 1979, though. But I have a pile of LV P&B and didn't test all of them

[mr_me]

I would have thought that the earliest cartridges were made in usa, and that hong kong manufacturing started well after 1979 but who knows. Maybe they sent the wrong rom to hong kong.

[+intellivotion]

my guess is that the first carts released said 1979 and that the rom was changed later. According to intvfunhouse all the I.I. carts tested by Steve are 1978

[mr_me]

More than likely Mattel had some c1978 cartridge stock they held back because of the change. Intellivision Inc. aquired that stock in 1984, put new labels and shipped them. They did the same thing with auto racing.

 

Edit:

My poker&bj has a rom date of 8206 and it's copyright 1979 (made in hong kong with a g1 box). The rom chips have a date stamped on them. You can open the cartridge and see exactly when it was manufactured.

Edited January 10, 2019 by mr_me