New 2600 Music

[New 2600 Music]

...and lack of 4 joystick ports.

[7800/7800 ProSystem]

I'm afraid the slotted joystick port has nothing to do with board revsion. It was more to do with whatever happened to be the cheapest (slotted or non-slotted) 9 pin connector when Atari bought them.

I doubt they were a commodity item. The slotted ports were specifically for the 2800 controllers, which have small bumps on them that let them lock into the slotted ports.

[Missile Command -- 2600 vs. 8-bit?]

the 8-bit version seems to be a really poor port of the VCS'...with graphics that are inferiorto that of the 2600's.

I want some of what this guy is smoking.

[7800/7800 ProSystem]

This is interesting... there is a way to recognize the last cr version, apart open it?

It doesn't have the holes in the joystick ports sleeves.

[7800/7800 ProSystem]

There are actually 3 major variations on the 7800. The rare original production run with expansion port, a second run with slotted joystick ports (identical to the ports on the 2800/Sears Arcade II), and a third component-reduced version, which is the one with all the compatibility problems.

[New 2600 Music]

You mean like this one?

[CX22 vs CX80 trak balls]

Is it set to trackball mode?

[Which games should they NEVER have tried to do on the 2600?]

That would have been a ground-up rewrite, not an "enhancement".

[More Sequels We Can Do Without]

It's official, I'm going to Hell--

 

[New 2600 Music]

The 6507 can already drive digital audio through it. That's about as hard as you can squeeze any sound chip.

[Koronis Rift]

There were definitely maps. Once you get the mapping module, this becomes apparent. One of the highest levels I got to, the layout was a huge spiral maze.

[It's fake screenshot time]

Nonsense, there was a discussion about how a 2600-Robotron homebrew might be possible (though limited) by using playfield gfx for "Grunts"...so I would think that keeping track of just a few platforms would be easier than doing that.

Only because you don't really know what you're talking about. The Robotron proposal (which *I* came up with) was for an ELEVEN-line kernel, not a single-line kernel. Plus, it treated the playfield as a pure RAM-based bitmap with all updating logic outside the kernel, not a RAM/ROM hybrid with logic embedded in the kernel itself.

 

Have done any programming on any Atari, ever?

[New 2600 Music]

if you can do that with the 2600, i bet you sythesize an entire orchestra with a 7800.

The 7800 has exactly the same sound chip as the 2600.

[Which games should they NEVER have tried to do on the 2600?]

But then again, Sears also released the 2600 version of Steeplechase, a port of the old Atari arcade game...oh wait, let me guess, Atari probably made that one also!   Maybe they had a really close relationship or something...

That's the understatement of the year.

 

http://www.pong-story.com/atpong2.htm

[GameCube game by Jeff Minter]

Zylon;

 

Have you ever played a Minter game?

Have you?

[Which games should they NEVER have tried to do on the 2600?]

Atari DID make it. Sears only published it.

 

And I think it's pretty fun. A straight port of the old mainframe Star Trek game. For the era it came out, I think a text-based game on the 2600 was considered more cool than lame.

[It's fake screenshot time]

So it could be done as pictured with as few as 2 bytes RAM assuming the elevator columns are moving in sync.  If the elevators are out of sync it would take more like 3 or 4 bytes of RAM, but it seems doable to me.

Sounds like this would consume far more CPU cycles than are available in a single-line, non-mirrored playfield kernel.

[It's fake screenshot time]

The elevators would be best implemented using playfield graphics.

Only if you have most of the 2600's RAM to spare.

[Which games should they NEVER have tried to do on the 2600?]

Eh, kind of hard to write code to DISprove that something's possible.

[Which games should they NEVER have tried to do on the 2600?]

Only because the same approach wasn't carried all the way through (since it's not needed in Stargate).

See, joeybastard? This is just what I'm talking about.

[Which games should they NEVER have tried to do on the 2600?]

Hmm, the author of that review isn't even aware that the 2600 version exists!

[Which games should they NEVER have tried to do on the 2600?]

Yes, I have played Stargate. Note how far apart the peaks-valleys are. They're arranged so that there are never more than two sprites (missiles, ball, whatever) required on a single scan line. This approach is entirely inadequate for a game like Scramble.

[Koronis Rift]

Ah, sacrificed many evenings to Koronis Rift. In retrospect, the only thing it really had going for it was the spectacular graphics and terrain interaction. The way your speed and viewpoint varied as you drove around Koronis (and the shifting engine sounds) was just perfect.

 

Looking back, the actual gameplay sucked hard. You spend all of your time either driving around, or spinning in circles trying to blast the UFOs that hassle you. Success apparently requires figuring out what the modules do via trial-and-error, but in a game where "error" means death by one or two UFO shots, followed by about two minutes to start over, experimentation isn't really encouraged. It's like if someone tried to combine Doom and Mastermind. Just doesn't work.

 

The "Ballblazer" module was pretty cool though.

[Orc Attack For Sale]

Orc Attack is a great little gem of a game. Spent hours playing it in my wasted youth. It's amazing how much variety they packed into it as you progress through the levels.

 

FIREBOMB!

 

[Which games should they NEVER have tried to do on the 2600?]

Meh, it's an aquired disinclination due to getting into way too many technical discussions where the other side just didn't "get it".

 

In this case, the not-getting seems to be that Nukey isn't realizing that, while sprites are unlimited vertically, they are extremely limited horizontally. A 2600 playfield can represent 20 peak-valley transitions in a single line. That would require 40 sprites to smooth out the scrolling of each side of each pixel.