Jump to content

Photo

FB2 compatiblity list


52 replies to this topic

#26 supercat OFFLINE  

supercat

    Quadrunner

  • 6,401 posts

Posted Wed Aug 31, 2005 4:29 PM

Couldn't they just convert the 1 chip schematic to CMOS?


Gate level designs convert pretty easily, usually. Transistor-level designs can be another story. The problem is that in situations where, e.g., you have a series string of two transistors trying to pull a node up and a series string of four trying to pull it down, it's not necessarily clear from a schematic what should "win". I would expect that many of the trickier aspects of the TIA aren't as they are because they were deliberately designed that way, but instead because of what results certain logic contentions happened to produce.

Any attempt to recreate the TIA should combine analysis of the schematics with experments on the "real thing". Each type of analysis will show things the other does not.

#27 jsoper OFFLINE  

jsoper

    Stargunner

  • Topic Starter
  • 1,527 posts
  • Location:San Jose Ca

Posted Wed Aug 31, 2005 5:14 PM

I would guess asynchronous issues would be more of a problem then contention, but who knows. With skilled people and the original documentation, it shouldn't be that hard to figure out 1977 technology. Look how close the hobbyists are getting.

Edited by jsoper, Wed Aug 31, 2005 6:05 PM.


#28 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • 3,614 posts
  • CD C9 01
  • Location:San Antonio, TX

Posted Wed Aug 31, 2005 5:51 PM

Someone (not too many people have been doing TIA VHDL, so it can't have been one of too many people) was telling me recently that once his design was converted to synchronous rather than asynchronous logic, the whole thing worked a lot better.

#29 supercat OFFLINE  

supercat

    Quadrunner

  • 6,401 posts

Posted Wed Aug 31, 2005 5:59 PM

Someone (not too many people have been doing TIA VHDL, so it can't have been one of too many people) was telling me recently that once his design was converted to synchronous rather than asynchronous logic, the whole thing worked a lot better.

View Post


I don't doubt it. But I would expect that such a design would not work like a "real" TIA unless the person implementing it took care to test all the race conditions and determine "who wins". Things like not showing the first copy of a sprite following a RESPx/RESMx, but showing the ball following RESBL, may be a result of such race conditions; an implementor who doesn't know what the TIA actually DOES could easily guess them wrong.

#30 ehenciak OFFLINE  

ehenciak

    Star Raider

  • 75 posts
  • Location:Pittsburgh, PA USA

Posted Sat Sep 3, 2005 3:32 PM

Someone (not too many people have been doing TIA VHDL, so it can't have been one of too many people) was telling me recently that once his design was converted to synchronous rather than asynchronous logic, the whole thing worked a lot better.

View Post


I don't doubt it. But I would expect that such a design would not work like a "real" TIA unless the person implementing it took care to test all the race conditions and determine "who wins". Things like not showing the first copy of a sprite following a RESPx/RESMx, but showing the ball following RESBL, may be a result of such race conditions; an implementor who doesn't know what the TIA actually DOES could easily guess them wrong.

View Post


What games do this? This doesn't sound like a race condition or the results would not be deterministic...forgive me if I am wrong, but this sounds more like an additional clock cycle of delay rather than a race condition.

From what I have seen thus far, you can make TIA truly synchronous and 100% compatible....however, having said that, I am still waiting to find the one game that pisses me off :)!

Ed

#31 ehenciak OFFLINE  

ehenciak

    Star Raider

  • 75 posts
  • Location:Pittsburgh, PA USA

Posted Sat Sep 3, 2005 6:40 PM

Someone (not too many people have been doing TIA VHDL, so it can't have been one of too many people) was telling me recently that once his design was converted to synchronous rather than asynchronous logic, the whole thing worked a lot better.

View Post


I don't doubt it. But I would expect that such a design would not work like a "real" TIA unless the person implementing it took care to test all the race conditions and determine "who wins". Things like not showing the first copy of a sprite following a RESPx/RESMx, but showing the ball following RESBL, may be a result of such race conditions; an implementor who doesn't know what the TIA actually DOES could easily guess them wrong.

View Post


What games do this? This doesn't sound like a race condition or the results would not be deterministic...forgive me if I am wrong, but this sounds more like an additional clock cycle of delay rather than a race condition.

From what I have seen thus far, you can make TIA truly synchronous and 100% compatible....however, having said that, I am still waiting to find the one game that pisses me off :)!

Ed

View Post


Ahhh, I see on another post that Missile Command uses this "trick/feature/whatever"....my FPGA does not exhibit this behavior, so I think I got it right...

#32 Pipercub OFFLINE  

Pipercub

    Moonsweeper

  • 298 posts

Posted Sun Sep 4, 2005 11:18 PM

"I've been wondering that since they aquired Atari, they should have direct access to all the schematics, gate descriptions, and layouts of both the 3 chip and 1 chip designs and should be able to replicate those circuits fairly easily. Couldn't they just convert the 1 chip schematic to CMOS?"

I might be stating the obvious here, or it may not apply, but in another thread Curt said that the overseas engineers made some unauthorized "corrections" to the chip.

#33 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 24,031 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Mon Sep 5, 2005 3:04 AM

Ahhh, I see on another post that Missile Command uses this "trick/feature/whatever"....my FPGA does not exhibit this behavior, so I think I got it right.

Galaxians might be another example.

#34 keilbaca OFFLINE  

keilbaca

    Fight like a robot!

  • 7,759 posts
  • Berzerk (Atari 2600) champ
  • Location:Lower Burrell, PA

Posted Mon Sep 26, 2005 7:13 PM

Has anyone tried giving the thing 5V instead of 4.2V?

#35 Raiu OFFLINE  

Raiu

    Chopper Commander

  • 172 posts

Posted Tue Sep 27, 2005 2:37 AM

The Kool-Aid Man bug sounds like what happens on a lot of very-late model 2600 jrs, so it's probably not an "emulation" problem.

-DS-

#36 mos6507 OFFLINE  

mos6507

    River Patroller

  • 4,916 posts

Posted Tue Sep 27, 2005 4:26 PM

I might be stating the obvious here, or it may not apply, but in another thread Curt said that the overseas engineers made some unauthorized "corrections" to the chip.

View Post



Such are the evils of outsourcing.

#37 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,680 posts
  • begin 644 contest

Posted Tue Oct 25, 2005 4:37 PM

I just discovered that one of my 1k minigames does not work on the FB2. However, this is not a TIA issue at all, unlike the other incompatibilities that have been discussed.

I traced the problem to some undocumented 650x opcodes. My game uses LAX, DCP, NOP zp, SAX, ISB, ARR and SBX, but the FB2 only seems to have issues with ARR and SBX.

I suppose I will see if I can recode my game to use regular opcodes while still fitting in 1k of space, as ARR and SBX are seldom used anyway. But still, if 100% compatibility with the 2600 is the goal with the Rev. C FB2, maybe the FB2 engineering team should consider implementing all undocumented opcodes, even the most obscure of them.

#38 supercat OFFLINE  

supercat

    Quadrunner

  • 6,401 posts

Posted Tue Oct 25, 2005 4:51 PM

I suppose I will see if I can recode my game to use regular opcodes while still fitting in 1k of space, as ARR and SBX are seldom used anyway.  But still, if 100% compatibility with the 2600 is the goal with the Rev. C FB2, maybe the FB2 engineering team should consider implementing all undocumented opcodes, even the most obscure of them.

View Post


SBX doesn't seem obscure. To be sure, it's probably mostly only useful in the cases where either A=X, A=$FF, or X=$FF, but even with those restrictions it's still useful.

And there are some other useful cases as well. For example, if I understand it right, I could replace the sequence:
  lda Bitmap,x
  and #$55
  tay
  lda (ColPtr1),y
  sta Color1
  lda (ColPtr2),y
  sta Color1a
with
  ldx Bitmap,y
  lda #$55
  sbx ColorAdj
  lda COLTABL1,X
  sta Color1
  lda COLTABL2,X
  sta Color1a
If I needed to save a cycle or save three bytes of RAM this could be very handy. (think think think) I just might do that. (looks at opcode list) Drat--Immediate only. Waaah!

#39 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,957 posts
  • Location:Atlanta, GA

Posted Tue Oct 25, 2005 5:27 PM

I suppose I will see if I can recode my game to use regular opcodes while still fitting in 1k of space, as ARR and SBX are seldom used anyway.  But still, if 100% compatibility with the 2600 is the goal with the Rev. C FB2, maybe the FB2 engineering team should consider implementing all undocumented opcodes, even the most obscure of them.

This is news to me. I thought all of them were implemented. I know for a fact that LAX and DCP are implemented because I'm using them in Atari Climber. I'm think I'm using NOP zp too but I'd have to go through the source to be sure.

#40 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,680 posts
  • begin 644 contest

Posted Wed Oct 26, 2005 2:32 AM

I suppose I will see if I can recode my game to use regular opcodes while still fitting in 1k of space, as ARR and SBX are seldom used anyway.  But still, if 100% compatibility with the 2600 is the goal with the Rev. C FB2, maybe the FB2 engineering team should consider implementing all undocumented opcodes, even the most obscure of them.

This is news to me. I thought all of them were implemented. I know for a fact that LAX and DCP are implemented because I'm using them in Atari Climber. I'm think I'm using NOP zp too but I'd have to go through the source to be sure.

View Post

I think it's true. My game Zirconium definitely does not work on the FB2 (crashes after only a few frames) so I recoded it to take out SBX. Then it worked but had glitches in the code where I used ARR (calculating score pointers). But the changes require space that I don't have to spare in the 1k.

I use DCP, LAX, ISB, and SAX and they work just fine. But these are all in the same family (combinations of two nearby instructions.) Maybe the FB2 team did this family only.

SBX and ARR are in a different family, which includes ASR, ANE and LXA. Perhaps none of these were done. Granted, some of the opcodes in this family (ANE, LXA) I think are unpredictable and therefore basucally useless, and SBX does some really funky things if you happen to be in decimal mode. Regardless, I think SBX is useful, and perhaps the most useful in this family.

I said SBX was obscure since I've never heard of anyone else actually using it in a game, but I have seen it mentioned before. I used it twice in my game, actually, and I used it in the first bB kernel until people reported problems with PCAE (which, of course, is a limitation of PCAE but I opted for compatibility in this case.)

In my game, I have a loop like this:
LDX #56
loop:
;do some stuff here
TXA
SBX #14
BNE loop

TO recode, you need to do this:

LDX #56
loop:
;do some stuff here
TXA
SEC
SBC #14
TAX
BNE loop

the whole routine above was in a loop that was executed up to 10 times, thus saving 2 bytes and up to 160 cycles.

I wonder if they bothered with SHS, SHA, SHY, SHX and the like, which are also in a family of their own. I doubt anyone has used these yet, but I think Supercat has at least found a possible use for some of them.

Anyway, it wouldn't be hard to write some code to test each instruction and report the results somehow... Maybe I'll do this.

#41 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 24,031 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Wed Oct 26, 2005 5:36 AM

Wow, some really clever coding above. :thumbsup:

Maybe you could post some short code snippets which show useful illegal opcodes to [stella]? I am sure, Paul would like to collect them in the MiniDig too.

#42 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,957 posts
  • Location:Atlanta, GA

Posted Wed Oct 26, 2005 5:48 AM

Regardless, I think SBX is useful, and perhaps the most useful in this family.

You're using opcode $CB which I read as unstable :? This is the same issue I ran into with opcode $8B.

Also...wouldn't
LDX #56
loop:
;do some stuff here
TXA
SBX #14
BNE loop

be translated to...
LDX #56
loop:
;do some stuff here
STA tempVar
TXA
AND tempVar
SEC
SBC #14
TAX
LDA tempVar
BNE loop

Edited by DEBRO, Wed Oct 26, 2005 6:11 AM.


#43 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 24,031 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Wed Oct 26, 2005 6:55 AM

You're using opcode $CB which I read as unstable :? This is the same issue I ran into with opcode $8B.

Where? According to my docs $CB is stable, $8B is not.

Other unstable opcodes which should not be used: $93, $9B, $9C, $9E, $9F and $AB (some sources say $BB and $BF are unreliable too). The rest should be safe.

Edited by Thomas Jentzsch, Wed Oct 26, 2005 7:06 AM.


#44 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,957 posts
  • Location:Atlanta, GA

Posted Wed Oct 26, 2005 7:17 AM

Where? According to my docs $CB is stable, $8B is not.

Sorry, it does seem to be stable on the Atari 6502 but not on the 6510 according to the doc I'm attaching.

$8B is also stable on the Atari 6502 according to docs on the web. I know we ran a test on [stella] for this opcode but I can't remember the final results. I guess I'll have to fish through the archives again.

Attached Files



#45 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 24,031 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Wed Oct 26, 2005 7:39 AM

Sorry, it does seem to be stable on the Atari 6502 but not on the 6510 according to the doc I'm attaching.

$8B is also stable on the Atari 6502 according to docs on the web.

This is the source I am using (available under several addresses in the web):
http://www.oxyron.de.../opcodes02.html

#46 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,957 posts
  • Location:Atlanta, GA

Posted Wed Oct 26, 2005 7:46 AM

This is the source I am using (available under several addresses in the web):
http://www.oxyron.de.../opcodes02.html

Thanks. I believe this is the link I sent the FB2 guys but I'll send again to be sure.

The document I posted could have a typo. Plus with all others I searched showing it as stable I think I can count it as stable :)

I looked at Fred's code sniplet again and now I see how he's getting around the X & A restriction...very clever.

#47 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,680 posts
  • begin 644 contest

Posted Wed Oct 26, 2005 3:58 PM

Regardless, I think SBX is useful, and perhaps the most useful in this family.

You're using opcode $CB which I read as unstable :? This is the same issue I ran into with opcode $8B.

Also...wouldn't
LDX #56
loop:
;do some stuff here
TXA
SBX #14
BNE loop

be translated to...
LDX #56
loop:
;do some stuff here
STA tempVar
TXA
AND tempVar
SEC
SBC #14
TAX
LDA tempVar
BNE loop

View Post

Incidentally, my code did not require that I preserve the accumulator. If it did, then yes, I'd have to put in all of that extra code.

I was wrong, however, when I said that SBX did weird things in decimal mode - Actually, it ignores decimal mode altogether.

It was ARR that had a weird decimal mode. It's sort of amazing how complex this instruction is in this case:

In Decimal mode (D flag set), the ARR instruction first performs the
AND and ROR, just like in Binary mode. The N flag will be copied from
the initial C flag, and the Z flag will be set according to the ROR
result, as expected. The V flag will be set if the bit 6 of the
accumulator changed its state between the AND and the ROR, cleared
otherwise.

Now comes the funny part. If the low nybble of the AND result,
incremented by its lowmost bit, is greater than 5, the low nybble in
the ROR result will be incremented by 6. The low nybble may overflow
as a consequence of this BCD fixup, but the high nybble won't be
adjusted. The high nybble will be BCD fixed in a similar way. If the
high nybble of the AND result, incremented by its lowmost bit, is
greater than 5, the high nybble in the ROR result will be incremented
by 6, and the Carry flag will be set. Otherwise the C flag will be
cleared.

To help you understand this description, here is a C routine that
illustrates the ARR operation in Decimal mode:

        unsigned
          A,  /* Accumulator */
          AL, /* low nybble of accumulator */
          AH, /* high nybble of accumulator */

          C,  /* Carry flag */
          Z,  /* Zero flag */
          V,  /* oVerflow flag */
          N,  /* Negative flag */

          t,  /* temporary value */
          s;  /* value to be ARRed with Accumulator */

        t = A & s;                      /* Perform the AND. */

        AH = t >> 4;                    /* Separate the high */
        AL = t & 15;                    /* and low nybbles. */

        N = C;                          /* Set the N and */
        Z = !(A = (t >> 1) | (C << 7)); /* Z flags traditionally */
        V = (t ^ A) & 64;              /* and V flag in a weird way. */

        if (AL + (AL & 1) > 5)          /* BCD "fixup" for low nybble. */
          A = (A & 0xF0) | ((A + 6) & 0xF);

        if (C = AH + (AH & 1) > 5)      /* Set the Carry flag. */
          A = (A + 0x60) & 0xFF;        /* BCD "fixup" for high nybble. */



#48 supercat OFFLINE  

supercat

    Quadrunner

  • 6,401 posts

Posted Wed Oct 26, 2005 4:14 PM

be translated to...

LDX #56
loop:
;do some stuff here
STA tempVar
TXA
AND tempVar
...

View Post


Since he does a TXA immediately before the SBX instruction, tempvar and X will hold the same thing. The "AND" function you suggest will thus have no effect.

#49 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 24,031 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Thu Oct 27, 2005 3:24 AM

In Decimal mode (D flag set), the ARR instruction first performs the
AND and ROR, just like in Binary mode. The N flag will be copied from
the initial C flag, and the Z flag will be set according to the ROR
result, as expected. The V flag will be set if the bit 6 of the
accumulator changed its state between the AND and the ROR, cleared
otherwise.

Now comes the funny part. If the low nybble of the AND result,
incremented by its lowmost bit, is greater than 5, the low nybble in
the ROR result will be incremented by 6. The low nybble may overflow
as a consequence of this BCD fixup, but the high nybble won't be
adjusted. The high nybble will be BCD fixed in a similar way. If the
high nybble of the AND result, incremented by its lowmost bit, is
greater than 5, the high nybble in the ROR result will be incremented
by 6, and the Carry flag will be set. Otherwise the C flag will be
cleared.

To help you understand this description, here is a C routine that
illustrates the ARR operation in Decimal mode:

        unsigned
           A,  /* Accumulator */
           AL, /* low nybble of accumulator */
           AH, /* high nybble of accumulator */

           C,  /* Carry flag */
           Z,  /* Zero flag */
           V,  /* oVerflow flag */
           N,  /* Negative flag */

           t,  /* temporary value */
           s;  /* value to be ARRed with Accumulator */

        t = A & s;                      /* Perform the AND. */

        AH = t >> 4;                    /* Separate the high */
        AL = t & 15;                    /* and low nybbles. */

        N = C;                          /* Set the N and */
        Z = !(A = (t >> 1) | (C << 7)); /* Z flags traditionally */
        V = (t ^ A) & 64;               /* and V flag in a weird way. */

        if (AL + (AL & 1) > 5)          /* BCD "fixup" for low nybble. */
          A = (A & 0xF0) | ((A + 6) & 0xF);

        if (C = AH + (AH & 1) > 5)      /* Set the Carry flag. */
          A = (A + 0x60) & 0xFF;        /* BCD "fixup" for high nybble. */

Interesting, looks like ARR is doing something like AND, flags and BCD correction after ADC and ROR. Maybe reordering the code above would make ARR look more "logical".

BTW: This doesn't make any sense to me:
if (AL + (AL & 1) > 5)
IMO it is 100% identical to:
if (AL >= 5)
So it seems that an ordinary BCD correction is happening after "thinking" AL/AH have been RORed too.

Or maybe BCD correction (and V flag?) is happening based on an addition of (A & s) + (A & s) whichs result is thrown away? Hm...

Edited by Thomas Jentzsch, Thu Oct 27, 2005 3:52 AM.


#50 antron OFFLINE  

antron

    Chopper Commander

  • 196 posts

Posted Mon Mar 12, 2007 10:09 AM

Swoops doesn't load




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users