FB2 compatiblity list

[supercat]

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.

[jsoper]

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 September 1, 2005 by jsoper

[Bruce Tomlin]

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.

[supercat]

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.

922724[/snapback]

 

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.

[ehenciak]

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.

922724[/snapback]

 

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.

922731[/snapback]

 

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

[ehenciak]

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.

922724[/snapback]

 

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.

922731[/snapback]

 

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

924545[/snapback]

 

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...

[Pipercub]

"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.

[Thomas Jentzsch]

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.

[keilbaca]

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

[Raiu]

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-

[mos6507]

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.

925287[/snapback]

 

 

Such are the evils of outsourcing.

[+batari]

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.

[supercat]

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.

954273[/snapback]

 

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!

[DEBRO]

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.

[+batari]

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.

954312[/snapback]

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.

[Thomas Jentzsch]

Wow, some really clever coding above.

 

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.

[DEBRO]

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 October 26, 2005 by DEBRO

[Thomas Jentzsch]

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 October 26, 2005 by Thomas Jentzsch

[DEBRO]

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.

OPCODE02.TXT

[Thomas Jentzsch]

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/html/opcodes02.html

[DEBRO]

This is the source I am using (available under several addresses in the web):

http://www.oxyron.de/html/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.

[+batari]

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

954577[/snapback]

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. */

 

[supercat]

be translated to...

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

954577[/snapback]

 

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.

[Thomas Jentzsch]

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 October 27, 2005 by Thomas Jentzsch

[antron]

Swoops doesn't load