From: nowhere@never.at   
      
   Kerr-Mudd,John wrote:   
   ...   
   >>> 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.   
      
   > I now have something that works, but I haven't "newline"-proofed it.   
   > 213 bytes of pure B64 (if you allow crlfs). Quite a struggle to get the   
   > fixups working; that and avoiding invalid fixup addresses (e.g. the 5A to   
   > 61 gap). If/when I overcome that last problem I'll post it here.   
      
   Perhaps less struggle if you'd had my hex-editable disass/dump-tool :)   
      
   Ok if just for the fun of doing it, but I still don't understand why   
   we restrict ourself to the final decoder's format, we could allow all   
   transferable characters (21..7e) in the header part which may create   
   any chosen decoder for an appended encoded string.   
      
   >> 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.   
      
   > Next project!   
      
   looking forward to a CLAX approved encoding style ... :)   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)