Arrow Reason Why Fta Is Down And Will Stay Down !!! Parrot mode ON: For those in denial, the code below does one simple thing: it writes 94h to location $8B7E. This causes the stack return to point to $94xx instead of $8Bxx when the function returns. They have sent this code via the latest revision and are sending it down in EMM packets too! They want to be sure every card gets the update. Now, when the stack returns to $94xx, glitching is not possible for a variety of technical reasons that only a coder understands. The cam is shut tight. End of story. So all subbed cards now have the new routine and can't be glitched - at least not with the old methods. Those using the latest blocker code can glitch in because you e3m just ignores the stack point stuff. However, once all the subbed cards are updated, all they have to do is check if the card is locked or unlocked. Unlocked cards will call a MAP function that disables part of the MAPRom. Locked cards will function normally. That doesn't leave us much choice, does it? Either we let them lock our cards OR we risk losing the MAPRom functionality. If you let them lock your card, then you will eventually lose your tiers and will be watching a black screen. Since you can't glitch back in, that black screen will be around for a while. If they kill your MAPRom, well, black screen once again. In layman's terms, the code update means this: Charlie is saying: "sheep, sheep, where are you going?" Testers say: "to the slaughterhouse, bah, bah." Guys, you are all being set up by Charlie and unknowingly being led to the slaughterhouse. When having a real update on your card is enforced pull your ROM102 cards while you have a chance. An "Aux" type solution will probably surface once the big kill comes down. At that time, there will be a severe SHORTAGE of ROM102 cards. ---------------------------------------------- Rev 109 code ---------------------------------------------- 93E3: A694 lda #94 ; Load in A 93E5: AC push dsr ; push dsr on stack 93E6: 7180 ldp #80 ; Load into paging register 93E8: C18B7E cmpa 8B7E ; cmp ram with a 93EB: 2712 jreq $93FF ; Jump if Z = 1 (equal) 93ED: CD5700 call 5700 93F0: 8B lda dsr ; Load dsr in a 93F1: 7E swap(x) ; Swap nibbles 93F2: BE6B ldx 006B 93F4: 89 pushx ; Push x onto the Stack 93F5: AE96 ldx #96 ; Load in X 93F7: BF6B stx 006B ; Store x in... 93F9: CD6DC9 call 6DC9 93FC: 85 popx ; Pop x from the Stack 93FD: BF6B stx 006B ; Store x in... 93FF: AF pop dsr ; pop dsr from stack 9400: 81 rts ; Return from subroutine -------------------------------------------- Don't let the FTA makers pull the wool over your eyes. Don't believe them when they say the fix is taking so long because "we have to read through 155 pages of prime number theory, AES ciphering" or "the new bin required is so massive the coder is exhausted" or my personal favourite "Mr. Viewsat will be putting 1 Canadian and 1 Korean in the same room with a electron laserscope". Complete and utter kaka. The reason FTA, Atmega, Armulator, ROM101, ROM10/11 and everything else (except ROM102) is down is because of these two lines of code: 936E: lda #$57 9370: jsrp #$00, $A822 Thats it! Those buggers are causing all this chaos. That code is assembly. Assembly works by calling and executing various instructions. The instruction at line 936E: lda #$57 means "load register a with the value 57". The instruction at 9370: jsrp #$00, $A822 means "okay, jump-to-routine MAP function that was loaded in register a, namely 57". So basically, those two lines of code execute something called MAP 57. The problem is, WE DON'T KNOW WHAT MAP 57 is. That is why Mr. Viewsat and the other FTA makers are sweating right about now. You see, without knowledge of MAP 57 their gravy train will run away soon. For those that say "well, the FTA people will figure it out, don't worry". Start worrying. Think of MAP 57 as a kind of black box. There is an input to the black box and an output. The idea is to try and figure out what this black box does. For example, if we input 2 and the output is 4, if when we input 3 the ouput is 6, if when we input 4 the output is 8, then we may reasonably deduce that this black box just multiplies the input by 2. That was easy. The real MAP 57 takes 128 bytes of input, another 16 bytes of input and magically produces a 128 byte output. Here is an example: INPUT 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 SECONDARY INPUT AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA OUTPUT 34 FD 23 BD 67 55 32 DD 12 11 AE A1 43 78 E1 F0 21 56 78 32 A2 B4 67 88 99 DE 11 12 57 89 FA AE 56 23 BB C1 23 BA F2 E5 E5 A1 90 29 07 5A 9B 2C 88 45 33 D1 00 00 00 00 00 00 00 00 00 00 00 00 9E 21 8A B1 4C 31 28 98 5A B2 C1 1D 28 56 23 F3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 15 C1 22 8D F4 4A 87 59 00 AA D2 C1 04 31 21 07 67 21 BA A8 93 24 B1 FF D2 31 20 02 9D 3F 0D 4A Does anyone see the pattern? How did we go from the input to the output? If you input different numbers you will get a different output. So how does this MAP 57 black box work? Anyone? Not as easy as multiplication by two. Not so easy to figure out, eh? I assure you, Mr. Viewsat can put 1 Canadian and 1 Korean in a room together with a laserscope and the problem doesn't change one bit. That folks is the story behind MAP call 57 and why FTA no longer works. Now you have the facts and you will know when the FTA makers are bluffing you with delayed bin excuses, emu re-write excuses, and the big prime number won't come out of my excuse. Well, there you have it. Just the facts. Plain and simple. __________________