intvnut Posted September 17, 2015 Share Posted September 17, 2015 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. Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted September 17, 2015 Share Posted September 17, 2015 Cool. Thanks. Now i might play it some. Never knew how to play one player so i just assumed it was 2 player only Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted September 17, 2015 Share Posted September 17, 2015 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
intvnut Posted September 17, 2015 Share Posted September 17, 2015 at least there is a "workaround" And you can "quote" me on it. 1 Quote Link to comment Share on other sites More sharing options...
+intvsteve Posted September 17, 2015 Share Posted September 17, 2015 ... 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. 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted September 17, 2015 Share Posted September 17, 2015 I can't remember anymore, but is there any advantage to bin+cfg? Seems like it's almost universally a hassle for people. Quote Link to comment Share on other sites More sharing options...
intvnut Posted September 17, 2015 Share Posted September 17, 2015 (edited) I can't remember anymore, but is there any advantage to bin+cfg? Seems like it's almost universally a hassle for people. Available from official sources (Intellivision Lives! and Intellivision Rocks!) Support for paged ROMs Support for patches via 'pokes' (such as I posted in this thread) 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.) Simpler / more hackable. Only useful to bitfiddlers like myself, though. Edited September 18, 2015 by intvnut Quote Link to comment Share on other sites More sharing options...
+Lathe26 Posted September 18, 2015 Share Posted September 18, 2015 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. Quote Link to comment Share on other sites More sharing options...
intvnut Posted September 19, 2015 Share Posted September 19, 2015 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
+Lathe26 Posted September 19, 2015 Share Posted September 19, 2015 I had to stare at the code but it actually... started... making... sense. That code is so gangsta that it killed Tupac Shakur. 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted September 19, 2015 Share Posted September 19, 2015 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted September 19, 2015 Share Posted September 19, 2015 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
1980gamer Posted September 19, 2015 Share Posted September 19, 2015 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. ) Quote Link to comment Share on other sites More sharing options...
mr_me Posted October 12, 2015 Share Posted October 12, 2015 (edited) 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 8 Quote Link to comment Share on other sites More sharing options...
First Spear Posted January 20, 2017 Share Posted January 20, 2017 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 -------------------------------------------------- Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 9, 2019 Share Posted January 9, 2019 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. 6 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 10, 2019 Share Posted January 10, 2019 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. Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 10, 2019 Share Posted January 10, 2019 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 10, 2019 Share Posted January 10, 2019 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. Quote Link to comment Share on other sites More sharing options...
mr_me Posted January 10, 2019 Share Posted January 10, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+intellivotion Posted January 10, 2019 Share Posted January 10, 2019 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 Quote Link to comment Share on other sites More sharing options...
+intellivotion Posted January 10, 2019 Share Posted January 10, 2019 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 Quote Link to comment Share on other sites More sharing options...
mr_me Posted January 10, 2019 Share Posted January 10, 2019 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. Quote Link to comment Share on other sites More sharing options...
+intellivotion Posted January 10, 2019 Share Posted January 10, 2019 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 Quote Link to comment Share on other sites More sharing options...
mr_me Posted January 10, 2019 Share Posted January 10, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.