Jump to content
IGNORED

Rom Variants Auto Racing etc.


Recommended Posts

Oh, oh, oh. Hang on, let me go and get my ROM variation cap...

 

s-l500.jpg

 

...wow I haven't had a chance to put this on in ages, OK...

 

1978 - colour label, made in Hong Kong, cart has "Insert to", triangle screws, chip is 1982 week 13 (8213)

1979 - colour label, made in Hong Kong, cart has "Insert to", Phillips screws, chips (yes, there are two, despite this being a 4K game) are shrouded in an RF shield, and therefore, I cannot tell the date.

 

I would suggest that the perversely the 1978 copyright date is the newer cartridge (at least for me).

Link to comment
Share on other sites

Is that c1978 cartridge with a GI chip inside. If it is it would mean that in 8206 GI made a c1979 P&BJ rom and then seven weeks later in 8213 made a c1978 P&BJ rom. Mattel also sourced roms for other manufacturers e.g. ami, toshiba. It could be that the first P&BJ cartridges in 1979 had c1979 roms and the c1978 roms showed up later by mistake.

 

Edit: Is that c1978 8213 rom a single 4k chip? If it is than the mistake might have happened when GI switched from to 2 x 2k roms to a single rom chip. My c1979 cartridge has two chips; one is 8206 and the other is 8205.

Edited by mr_me
Link to comment
Share on other sites

My own 1978 and 1979 ROM images come from cartridges I dumped myself, ca. 1979. I don't know, however, what box variant or any other details. When I made those dumps, many came from my dad's original collection. We had gotten the Intellivision before Astrosmash came out, so Poker was still the pack-in game.

 

Some fun timeline details from PapaIntellivision:

 

1979, preparing to launch:

post-14113-0-16767000-1547145117_thumb.png

 

1978, preparing for CES:

post-14113-0-34751800-1547145155_thumb.png

post-14113-0-35634600-1547145186_thumb.png

  • Like 7
Link to comment
Share on other sites

Oh, oh, oh. Hang on, let me go and get my ROM variation cap...

 

s-l500.jpg

 

...wow I haven't had a chance to put this on in ages, OK...

 

1978 - colour label, made in Hong Kong, cart has "Insert to", triangle screws, chip is 1982 week 13 (8213)

1979 - colour label, made in Hong Kong, cart has "Insert to", Phillips screws, chips (yes, there are two, despite this being a 4K game) are shrouded in an RF shield, and therefore, I cannot tell the date.

 

I would suggest that the perversely the 1978 copyright date is the newer cartridge (at least for me).

 

Hey, don't knock colorful propeller beanies. I've got this one (and yes, that's me):

post-14113-0-63544800-1547145391_thumb.jpg

 

Anyway: All of the earliest 4K games were on two 2K chips. The fact you have a 1978 variant with a 4K chip suggests someone screwed up when they cost-reduced from 2 x 2K to 1 x 4K.

 

It wouldn't surprise me. In the quest to find an 8K Lock'n'Chase in the wild, I'm pretty sure I've found boards with 8K ROMs (likely 2 x 4K) holding the 6K program image.

Edited by intvnut
  • Like 5
Link to comment
Share on other sites

My own 1978 and 1979 ROM images come from cartridges I dumped myself, ca. 1979. I don't know, however, what box variant or any other details. When I made those dumps, many came from my dad's original collection. We had gotten the Intellivision before Astrosmash came out, so Poker was still the pack-in game.

 

Some fun timeline details from PapaIntellivision:

 

1979, preparing to launch:

Mattel_Electronics_Cartridge_Status.png

 

 

"Puppet Theatre" the game? That's a new one on me. If someone found a prototype ROM, that would be awesome. However, I would be fearful of a Rev homebrew.
  • Like 1
Link to comment
Share on other sites

My own 1978 and 1979 ROM images come from cartridges I dumped myself, ca. 1979. I don't know, however, what box variant or any other details. When I made those dumps, many came from my dad's original collection. We had gotten the Intellivision before Astrosmash came out, so Poker was still the pack-in game.

 

...

I think Poker & BJ was the pack-in right up until the Intellivision II came out in 1983.
Link to comment
Share on other sites

  • 1 year later...
On 1/8/2019 at 11:39 PM, intvnut said:

 

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.

 

necro-necro-bump?

Anyway,  I'll bet the 78 version works consistently in the US @60Hz but when they tried it on 50Hz it was failing.  I'll also bet that was fun to find :(  unless someone was in the right frame of mind... and knew were to start.

 

Just a thought...  Been re-reading stuff based off the recent Auto Racing debates.    I need to dig out some white label versions and try them...

I think I only tried finding the mini-basketball in them.  Otherwise, I have all my BLUE /Sports Network carts out and about.  Just like them better :)

 

Link to comment
Share on other sites

9 hours ago, 1980gamer said:

Anyway,  I'll bet the 78 version works consistently in the US @60Hz but when they tried it on 50Hz it was failing.

Seems unlikely to me.

 

The US 60Hz version has a slower CPU than the PAL 50Hz version.  (895kHz vs. 1MHz.)  Also, the scanlines are longer on PAL (64µs) vs. NTSC (63.6µs).  The time allotted for the CPU to halt is around one scanline, which is 57 cycles on NTSC, or 64 on PAL.  So, a PAL machine has about 7 more CPU cycles to halt the machine than NTSC does.

 

Link to comment
Share on other sites

Man you know TOO much about these systems!

I was thinking along the lines of 480 scan lines vs 525 already tacking longer to draw.  OR would that give it more execution time?  I am so confused!  LOL ;)

 

Hmmm, I never had a PAL version, but did they still only display 480?

 

 

Link to comment
Share on other sites

3 hours ago, 1980gamer said:

Man you know TOO much about these systems!

Yeah, I've been at this awhile...

3 hours ago, 1980gamer said:

I was thinking along the lines of 480 scan lines vs 525 already tacking longer to draw.  OR would that give it more execution time?  I am so confused!  LOL ;)

 

Hmmm, I never had a PAL version, but did they still only display 480?

 

I believe both have the same size active field—192 scanlines plus an additional scanline at top and bottom borders.  Across two fields (one frame), that's 386 scanlines.   That's why the PAL units only displayed in the middle 80% of the screen, apparently.

 

The PAL units end up with more time to compute across the board, it turns out.

 

The particular glitch in question happens when the STIC can't get the information from RAM in a timely fashion.  The STIC gives the CPU approximately 1 scanline's heads up via ~BUSRQ: "I need to steal some cycles to fetch the next row of BACKTAB."  The CPU has to to respond with ~BUSAK before the STIC starts fetching the data.  If it doesn't, then the STIC can't actually fetch the data and will replay the previous row of BACKTAB.  That causes the screen to jump downward by a row of characters starting at that point.

 

This artifact can only happen 12 times per frame:  once for each row of characters.  There's an additional related artifact that can happen at the very top of the screen:  The STIC also uses a very short ~BUSRQ before the active display to kick the System RAM into "isolation mode."  If the CPU doesn't ~BUSAK that in a timely fashion, then the System RAM won't kick into isolation mode, and CPU writes could interfere with the first few scanlines of active display.  (Don't do this: it forces a buffer fight between the STIC and the System RAM.)

 

The point is, no matter whether you're on PAL or NTSC, the STIC only intrudes about a dozen times a frame to fetch characters, and you get this particular glitch when the CPU doesn't let the STIC intrude.  Otherwise, the STIC is pretty well isolated from the CPU and they don't bother each other.

 

The other main place the STIC bugs the CPU is the vertical retrace interrupt.  At the end of active display, the STIC fires an interrupt toward the CPU, so the CPU knows it can go reprogram STIC registers and update GRAM.  On NTSC, it has a very short time window to do this.  On PAL, because it only fills 80% of the display, it has a much more generous time window to access STIC registers and GRAM.  And, of course, NTSC gets interrupted 60 times a second, while PAL only gets interrupted 50.  So, PAL steals fewer cycles due to interrupts.

 

Now throw in the fact that the PAL systems run the CPU about 11% faster...  PAL systems have it easier all around!

 

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...
 
 
Now throw in the fact that the PAL systems run the CPU about 11% faster...  PAL systems have it easier all around!


Hmm... so then why do games on PAL run slower? (listen to something like Math Fun on NTSC compared to PAL). It’s immediately obvious with the sound effects, particularly the little tunes in that game. Related question - not having done any testing with this - are only games using the EXEC routines affected?






•Sent from my Intellivision keypad phone
Link to comment
Share on other sites

On 6/1/2020 at 9:28 PM, intvnut said:

Now throw in the fact that the PAL systems run the CPU about 11% faster...  PAL systems have it easier all around!

1 hour ago, nurmix said:

Hmm... so then why do games on PAL run slower? (listen to something like Math Fun on NTSC compared to PAL). It’s immediately obvious with the sound effects, particularly the little tunes in that game. Related question - not having done any testing with this - are only games using the EXEC routines affected?

Games that are timed based on the vertical retrace input run slower, unless they adjust for the different interrupt rate: 50 ticks/second vs. 60 ticks/second.  Games that are timed based on how fast the CPU runs will run faster, unless they add more delay loops on PAL. 

 

Most games derive their sense of time from the vertical retrace interrupt.  That's essentially all EXEC based games, but also most non-EXEC based games. Space Patrol slows down on PAL for this reason, for example.

 

Kroz didn't base its execution speed on retrace interrupts.  At least not entirely.  I added some very carefully calibrated delay loops to slow PAL gameplay down to match NTSC.  It was too fast otherwise, and that caused problems on some levels.

 

If you're careful to detect PAL and adjust your game's sense of time accordingly—either through adjusting for the different interrupt rate, or calibrating delays differently—they can run the same speed on both.

Edited by intvnut
  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...