supercat Posted August 31, 2005 Share Posted August 31, 2005 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. Quote Link to comment Share on other sites More sharing options...
jsoper Posted August 31, 2005 Author Share Posted August 31, 2005 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Bruce Tomlin Posted August 31, 2005 Share Posted August 31, 2005 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. Quote Link to comment Share on other sites More sharing options...
supercat Posted August 31, 2005 Share Posted August 31, 2005 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. Quote Link to comment Share on other sites More sharing options...
ehenciak Posted September 3, 2005 Share Posted September 3, 2005 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 Quote Link to comment Share on other sites More sharing options...
ehenciak Posted September 4, 2005 Share Posted September 4, 2005 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... Quote Link to comment Share on other sites More sharing options...
Pipercub Posted September 5, 2005 Share Posted September 5, 2005 "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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 5, 2005 Share Posted September 5, 2005 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. Quote Link to comment Share on other sites More sharing options...
keilbaca Posted September 27, 2005 Share Posted September 27, 2005 Has anyone tried giving the thing 5V instead of 4.2V? Quote Link to comment Share on other sites More sharing options...
Raiu Posted September 27, 2005 Share Posted September 27, 2005 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- Quote Link to comment Share on other sites More sharing options...
mos6507 Posted September 27, 2005 Share Posted September 27, 2005 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted October 25, 2005 Share Posted October 25, 2005 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. Quote Link to comment Share on other sites More sharing options...
supercat Posted October 25, 2005 Share Posted October 25, 2005 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! Quote Link to comment Share on other sites More sharing options...
DEBRO Posted October 25, 2005 Share Posted October 25, 2005 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted October 26, 2005 Share Posted October 26, 2005 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 26, 2005 Share Posted October 26, 2005 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. Quote Link to comment Share on other sites More sharing options...
DEBRO Posted October 26, 2005 Share Posted October 26, 2005 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 26, 2005 Share Posted October 26, 2005 (edited) 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 Quote Link to comment Share on other sites More sharing options...
DEBRO Posted October 26, 2005 Share Posted October 26, 2005 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 26, 2005 Share Posted October 26, 2005 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 Quote Link to comment Share on other sites More sharing options...
DEBRO Posted October 26, 2005 Share Posted October 26, 2005 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted October 26, 2005 Share Posted October 26, 2005 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 theAND 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. */ Quote Link to comment Share on other sites More sharing options...
supercat Posted October 26, 2005 Share Posted October 26, 2005 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 27, 2005 Share Posted October 27, 2005 (edited) In Decimal mode (D flag set), the ARR instruction first performs theAND 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 Quote Link to comment Share on other sites More sharing options...
antron Posted March 12, 2007 Share Posted March 12, 2007 Swoops doesn't load Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.