Flashback 2 Reviews

[supercat]

Especially since they often occure. Probably they just "forgot" to implement them correctly in front of the background.

916364[/snapback]

 

The Atari 2600's horizontal sprite positioning circuitry is rather unusual; rather than having each sprite be triggered when it his a specified position (as is done on other systems like the C64) the 2600 instead uses circuitry whose behavior repeats every 160 pixel clocks that it receives. Normally when an object is 'just sitting there', it will receive 160 pixel clocks per line and thus its behavior will repeat every scan line. Doing an HMOVE causes two things to happen:

 

-1- Each object is fed from 0 to 15 extra pixel clocks

 

-2- The start of the scan line display is delayed by 8 clocks, causing the line to only have 152 clocks rather than 160.

 

Normally, when HMOVE is used with a motion value of zero, each object receives eight "extra" pixel clocks, which make up for the eight that it will get short-changed by the delayed scan line start. If the object receives 15 extra pixel clocks, it will move seven pixels left; if it receives none, it will move eight pixels right.

 

That the HMOVE "bar" will eat into all the sprites for the first eight pixels of the display is an unavoidable consequence of how the horizontal motion is handled (though my own design preference would be to have the sprites repeat every 168 pixels instead of 160, and have the default behavior of the motion circuitry kick the counters with eight extra pulses when no move was specified). The decision to make the bars black, however, wasn't necessary; they could just as well have been made transparent to the playfield/background color. I don't know why the TIA didn't do so, but the decision for the new chip to refrain from doing so is almost certainly a design decision to put aesthetics over 'accuracy'.

[Thomas Jentzsch]

The decision to make the bars black, however, wasn't necessary; they could just as well have been made transparent to the playfield/background color.  I don't know why the TIA didn't do so, but the decision for the new chip to refrain from doing so is almost certainly a design decision to put aesthetics over 'accuracy'.

Makes sense. But then, why did they make them black for the playfield and transparent for the background?

 

And since there are other compatibility problems with HMOVE involved, maybe the reason is completely different?

[+johnnywc]

Interesting that the HMOVE lines have been altered, possibly for asthetic reasons. Personally, I would have wanted them to stay in there - after all, isn't that what we expect from a 2600 game? Hmmm... I wonder if the "referees" are still visible in Championship Soccer (I bought that explaination hook-line-and-sinker back in the day... ) Anyone try this one out yet on a modded FB2?

 

Curt - can you comment on this? Is the HMOVE differences a bug or a feature of the FB2 design?

 

Thanks,

[128bytes]

I noticed last night that Missle Command seems different - there is a bar graph just above the bullet supply, which is not in the original game. Anyone else notice this, and why is it there?

[DEBRO]

I noticed last night that Missle Command seems different - there is a bar graph just above the bullet supply, which is not in the original game.  Anyone else notice this, and why is it there?

Yeah, that's been reported. I've been going through the MC source trying to replicate the behavior but I don't see how it could happen. That is unless the write to NUSIZ1 is doing something strange. Or maybe the GRP1 data is not getting cleared from drawing the cities. I've tried this too but still no success I'd really like to know why this is happening.

[Thomas Jentzsch]

Screenshots?

[DEBRO]

Screenshots?

If no one posts by tonight I'll see what I can come up with. I have to find my capture card though.

 

Atfer looking at this more now I'm wondering why the real VCS *doesn't* show this line. IIRC it appears right above the bullet supply so it happens on the scan line Rob is preparing to draw the bullets. Nothing is drawn on this scan line but Rob doesn't clear the GRP1 register. He only clears the GRP0 register. He also RESP1 at cycle 45. Wouldn't the player start drawing here?

[supercat]

Screenshots?

If no one posts by tonight I'll see what I can come up with. I have to find my capture card though.

 

Atfer looking at this more now I'm wondering why the real VCS *doesn't* show this line. IIRC it appears right above the bullet supply so it happens on the scan line Rob is preparing to draw the bullets. Nothing is drawn on this scan line but Rob doesn't clear the GRP1 register. He only clears the GRP0 register. He also RESP1 at cycle 45. Wouldn't the player start drawing here?

916903[/snapback]

 

Resetting a player or missile on a real 2600 will cause the copy "under the electron beam" not to be displayed. If NUSIZ is set for multiple copies, those other copies will be displayed in the expected places unless RESPx is hit again before they appear. Otherwise the sprite will not appear until it reaches the spot a line below the RESPx. Note that resetting the ball will cause it to appear immediately.

 

This is almost certainly the cause of Galaxian's problems: that game operates by setting NUSIZx to 1, then hitting RESPx multiple times in a scan line. The first "sprite copy" following a RESPx should not appear, but the second one should. Apparently on the FB2, both copies are appearing. Likewise I suspect that in Missile Command, RF was expecting that issuing a RESPx to the left of a sprite's last-displayed position would kill it for the current scan line without having to zero out GRPx. On a real 2600 it would, but apparently not on an FB2.

 

Note that this 'change', had it been made 28 years ago, would have been an improvement (being able to reset players directly to the current scan line would have made many things much nicer) but unfortunately, making the change now breaks a lot of software that codes around the old behavior. Worse, unlike the "HMOVE bar" behavior which is 99.44% cosmetic (some games use the HMOVE bar itself as a display item), the RESPx behavior can break things functionally.

[Curt Vendel]

The hmove change was a non-authorized cosmetic "fix" by some of the engineers over in our HK office as they thought they were "improving" the design.

 

It was not requested in the spec's or layout of the design, in fact everything was as it should have been in the initial ASIC run we did for the E3 demo units, someone decided that they should "improve" the design and it is now permanently part of 860K chips that were run, so don't expect a correction to this until the PAL units come out and a new NTSC run next year, sorry guys.

 

 

 

Curt

 

Interesting that the HMOVE lines have been altered, possibly for asthetic reasons.  Personally, I would have wanted them to stay in there - after all, isn't that what we expect from a 2600 game?  Hmmm...  I wonder if the "referees" are still visible in Championship Soccer (I bought that explaination hook-line-and-sinker back in the day... )  Anyone try this one out yet on a modded FB2?

 

Curt - can you comment on this?  Is the HMOVE differences a bug or a feature of the FB2 design?

 

Thanks,

916845[/snapback]

[Thomas Jentzsch]

Apparently on the FB2, both copies are appearing.

Yup, so there could be problems with other games using this trick too.

[jsoper]

The hmove change was a non-authorized cosmetic "fix" by some of the engineers over in our HK office as they thought they were "improving" the design.

917013[/snapback]

Not to be rude, but this sounds kinda suspicious to me. If two consumers can immeadiately find broken games after adding a cart connector (and I grabbed a handful of carts at random), it's not a subtle issue. I'd say the 40 rom gamelist had to be hand-selected for games that would work.

And also considering the Quadrun issue, there seems to be a "ship-it overwhelms QA" mentality going on.

But in fairness, that does make it seem more like a classic Atari product

Edited August 23, 2005 by jsoper

[Thomas Jentzsch]

The hmove change was a non-authorized cosmetic "fix" by some of the engineers over in our HK office as they thought they were "improving" the design.

Names? I am sure some people here would like to make a trip to HK now.

 

so don't xpect a correction to this until the PAL units come out and a new NTSC run next year, sorry guys.

No problem, sometimes being from a neglected PAL country can be positive.

[Thomas Jentzsch]

But in fairness, that does make it seem more like a classic Atari product

Yup!

 

"Banana software, matures at the customer!"

 

BTW: Been there, done that!

Edited August 23, 2005 by Thomas Jentzsch

[retrocon]

I think this pretty much closes the book on the idea that the recreation of hardware is somehow more accurate or better than software emulation. They both suffer from flaws and imperfections, no matter how much manpower is thrown at them.

 

A fast embedded microprocessor with a custom ported version of Z26 or Stella on rom would have probably been much more accurate, no?

[DEBRO]

so don't expect a correction to this until the PAL units come out and a new NTSC run next year, sorry guys.

It's nice to see Atari is planning on correcting this. IMO this is pretty cool.

 

So next year we'll have a perfect FB2 (with the sprite resetting fixed too ) that can be hacked with a cart port?

 

Thanks to the team at AA for finding and diagnosing these issues

[128bytes]

The hmove change was a non-authorized cosmetic "fix" by some of the engineers over in our HK office as they thought they were "improving" the design.

917013[/snapback]

Not to me rude, but this sounds kinda suspicious to me. If two consumers can immeadiately find broken games after adding a cart connector (and I grabbed a handful of carts at random), it's not a subtle issue. I'd say the 40 rom gamelist had to be hand-selected for games that would work.

And also considering the Quadrun issue, there seems to be a "ship-it overwhelms QA" mentality going on.

But in fairness, that does make it seem more like a classic Atari product

917027[/snapback]

 

Actually, the Missle Command HMOVE issue can be immediately seen without hacking, as Missle Command is part of the built-in 40 ROM gamelist.

 

The various versions of the 2600 (the Jr.), the 5200, and the 7800 all had minor hardware compatiblity (or even cartridge fitting compatibility!) issues due to hardware changes (one example: Robot Tank on the 7800) , and the FB2 isn't immune to them either. The HMOVE change, however, must have been really late, as it would have seemed to be caught by QA fairly quickly. I wonder if the HMOVE change, or other late "cosmetic" change to the hardware, is contributing to the shakiness exhibited in Asteroids Deluxe, Yars' Return, and (less likely due to the excessive number of scan lines coded) the GCC version of Millipede.

[tillenterprises]

Here's the solution for all these FB2 problems: Plug your 2600 in and play the real deal. I've been playing my FB2 over the last few weeks, and decided to put it away and plug in one of my 2600s, and ended up killing a few hours easily. There's just no true substitute for the real thing!

[scrummy]

Just to be fair I think we should all admit that members of atariage and or people who add a cartridge slot to the F2 are not really consumers in the same sense of the word as 99+% of the people who will eventually purchase this nifty little device.

 

The way I understand Curt is that he pressed the "go" button on an order for 860000 chips based on the fact that what he had approved was perfect. If someone at the factory then takes it upon thereselves to change things and then starts the process, then that really only leaves 2 choices.

 

1. Throw away the chips and blow your street date, which is a nice way to seriously piss off retailers.

 

or

 

2. Make a running change after the 860000 are used up and hope that the 1% of your market that ever notices the problem will understand.

 

BTW, If you don't think that option 2 was the right choice then you are most likely naive to the financial and business realities of the mass market.

 

 

 

I totally agree with the post earlier that this truly makes this a real Atari product.

Years from now it will be another treasured piece of Atari lore. ie. Here's my Flashback 2.0, uh I mean 2 and here's my Flashback 2 version B, and here's my Flashback 2 version C. It would sound crazy if it weren't so true.

 

 

PS,

 

Warner Communications is not the real ATARI!!!!

[128bytes]

Here's the solution for all these FB2 problems: Plug your 2600 in and play the real deal.    I've been playing my FB2 over the last few weeks, and decided to put it away and plug in one of my 2600s, and ended up killing a few hours easily.  There's just no true substitute for the real thing! 

917072[/snapback]

 

I can top that - I put my FB2 joysticks in my 7800, and I'm playing the real deal with better joysticks than I have used in years. I like these CX-40a's even better than original CX-40's - the fact that all my CX-40's are worn out in one way or another just makes it even sweeter. For many of us who own 2600's or 7800's, the FB2 is worth it for the new joysticks alone. And despite all the glitches, I'm still excited about the possibilites of hacking the FB2, and I still enjoy playing it as is. Yeah, the state of some of the games could give newbies the idea that many of the 2600 games were glitch and flicker filled, but there's more than enough goodness surrounding it (like River Raid!) to totally counteract it.

 

I hope it is popular enough to merit a second "FB2.1" run with all the bugs worked out.

[ZylonBane]

A fast embedded microprocessor with a custom ported version of Z26 or Stella on rom would have probably been much more accurate, no?

Authenticity of emulation if only part of the problem. The other major part is cost. It is far, far FAR more efficient to emulate any system at the hardware level than at the software level. Systems powerful enough to run cycle-perfect 2600 emulation software in realtime are many times more expensive than the $30 Flashback (which I'm sure costs a fraction of that to manufacture).

[retrocon]

A fast embedded microprocessor with a custom ported version of Z26 or Stella on rom would have probably been much more accurate, no?

Authenticity of emulation if only part of the problem. The other major part is cost. It is far, far FAR more efficient to emulate any system at the hardware level than at the software level. Systems powerful enough to run cycle-perfect 2600 emulation software in realtime are many times more expensive than the $30 Flashback (which I'm sure costs a fraction of that to manufacture).

917207[/snapback]

 

Well, maybe, but I'm pretty sure a low-end Arm could emulate the 2600 fullspeed and I'm sure they could be had for dirt-cheap per piece in that volume (900K). Still more expensive, but then there's no reason it has to be a $30 toy. Most would pay up to $50 or so without much thought. Just add a few more games (or maybe even a compact flash port).

[jsoper]

If someone at the factory then takes it upon thereselves to change things and then starts the process, then that really only leaves 2 choices.

 

1. Throw away the chips and blow your street date,  which is a nice way to seriously piss off retailers.

 

or

 

2. Make a running change after the 860000 are used up and hope that the 1% of your market that ever notices the problem will understand.

 

BTW, If you don't think that option 2 was the right choice then you are most likely naive to the financial and business realities of the mass market.

917087[/snapback]

And if someone thinks that sequence of events should have ever happened, I'd say they were naive about hardware designing and the need for some ISO certification. A design change requires a signoff loop, full archiving of the previous version, and a new test sample that is checked for defects before mass production. Software and firmware products (like fpga designs) have a little more room for slop.

[scrummy]

Jsop,

 

I hear you loud and clear, but sometimes the sky's not blue and the grass isn't green.

I doubt that anyone thinks it should have happened, but it looks like it did happen.

 

Sir, that's impossible.

\\\Agreed

 

It's against the law!

\\\and yet there it is.

 

We have a process!

\\\they ignored the process!

[supercat]

Well, maybe, but I'm pretty sure a low-end Arm could emulate the 2600 fullspeed and I'm sure they could be had for dirt-cheap per piece in that volume (900K).

917223[/snapback]

 

An ARM without assistive hardware is not going to be able to produce a quirks-accurate emulation of the TIA at full speed. And if one is going to add assistive hardware, one has the same issues as when just doing the thing "directly" with hardware.

 

What I would have liked to have seen (obviously too late now) would have been a selectable option to enable or disable the ugly hmove bars. Probably wouldn't be that difficult to do, wouldn't affect compatibility (even if the bars aren't there, the sprites are still blanked and can't participate in collisions), and would improve the appearance of a lot of games. Then people could choose between "authentic mode" and "better looking" mode.

 

The bigger problem than the HMOVE bars is the behavior or RESPx (and probably RESMx). I don't think any games, as written, are improved by the Flashback's behavior there. While games that were written to take advantage of that behavior could benefit from it, I really see no point to writing Flashback-only games.

[Carlos_Lopez]

...in fact everything was as it should have been in the initial ASIC run we did for the E3 demo units, someone decided that they should "improve" the design and it is now permanently part of 860K chips that were run...

What do you mean with "everything was as it should have been"? if you are saying that your original design was accurate and those engineers in your HK office screwed the HMOVE bars, sound, reset position circuits, messed the motion circuits (that generated the Cosmic Ark stars bug), etc. then it looks to me someone has to be fired or a company sued.

 

EDIT: About the console, cool product still. I'll definitely buy one or two (I like the case design).

Edited August 23, 2005 by Carlos_Lopez