From: nowhere@never.at   
      
   Kerr-Mudd,John wrote:   
      
   [about hex..]   
   >>> I already tried this because my favourite is hex, but it needs the   
   >>> conditional Sub,7 which will cause one more modify point.   
      
   >> Simple enough using 2:1, as I've already done that:   
      
   >> ZRPRht0XPR5t1PRRjW4iPaSV5LU1GK1GMUX+G=1GfUXG8+r6238wct083t+R=rY=   
   >> 66UZ2202Zffffff0222F6====MJ=20=17===eeee+++slOBI9UnrAE7oAOnasfrM   
   >> ItvlpB9EEE7D8KaasWhfr8TreEGB9fr8Tw7h8v7a7sCjejeoAlpadITi8YoH9f7=   
   >> B409BA0801CD21C348656C6C6F20776F726C642124=   
      
   >> Only 3 lines of code (could be shortened a bit no doubt, and requiring   
   >> a terminal '=' is just 'cos it's the same 'test for end' code from the   
   >> B64 decoder!)   
      
   > I'm still here; still struggling with a pure B64 char with fixups that's   
   > similar to WK's shortest B64 decoder. (initial setup, main loop enclosing   
   > fixups, then decoder routine [moved to early PSP]).   
      
   > It's tantalisingly close to doable!   
      
   :) it's sure possible to get rid of all the filler bytes, even with B64.   
      
   me too tried some variations of Terje's 16:13 code which needs too many   
   SMC-points so it's prone for a 2:1 prologue, and I also checked on 5:4   
   which become a few bytes less (177+27) than the B64 decoder.   
      
   And both 16:13 and 5:4 encoding may be a good choice for mailing binaries   
   as text (better than this Big Endian 4:3 Base64 anyway).   
   But it would need an agreed format, so that the transfered code can be   
   stored and reviewed before execute and not just run like our examples do.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)