From: notsaying@nospicedham.invalid.org   
      
   "wolfgang kern"  wrote in news:on3jtp$tjj$1   
   @gioia.aioe.org:   
      
   > Kerr-Mudd,John wrote:   
   > [..]   
   >> B64 216 bytes, ll63   
   >> ZRRj=hZhXP5ZiPRR4wPj9aSH5q+1GuA0O+0O80g387z9F84uC07pIu=Sajq0fa=   
   >> 660FW0Fv4r0Fg0Ft1FbhghX1FH1FJ1FN1FU0FX0fe0Fp0G34g666eeee   
   >> h=+hr5==ht2=ahreDaDAyjlE=3hwapNcAHHAA666L/40MGVOQX4o4gudOPYPqM   
   >> tAm6CAHNIcNIZWxsbyB3b3JsZCEk=   
   >   
   > very good, and now you confirmed that SMC may be shorter than 2:1,   
   > and it's already pretty close to 214(209)! :)   
   >   
   > is there any reason for the two first lines show different size ?   
   > I mean other than visual separation of blocks.   
      
   Yes, I was unable to fit in an "ignore crlf" step earlier; I need the   
   B64decoder to be contiguous.   
      
   > It works here but it may not work on other machines because you modify   
   > 012b,0133,0138 within the same cache-line without a branch.   
   >   
   I see; the first branch FU is dodgy; but the flow should always take the   
   2nd branch 1st time, so that should refresh the cache for the 2nd and 3rd   
   FU AIUI.   
      
   > I can't catch why: 012a  jpe +7 ;wouldn't jz +7 do it as well ?   
   Because the value at bx (5A=pop dx) isn't zero?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)