From: nowhere@never.at   
      
   Kerr-Mudd,John wrote:   
      
   >>>>> For education and amusement I hereby present clax with a 5:4   
   >>>>> (base85) decoder for DOS!   
   []   
   >>>> I'll check on it, but give me some more time ...   
      
   >>> Sure; it is a bit complicated (at least to me!). I use bp::dx as a   
   >>> qword accumulator for the 5:4 decoding.   
      
   >> I couldn't fully figure all details so far. What I got is your decoder   
   >> at 03d..07e and it seem to work (I had to stop on the first INT21   
   >> call). a few questions:   
      
   >> * DEC BP  JNO   you want a branch always?   
   > If you mean the INC BP, JO at the top of the secondary, then yes. I   
   > branch back to here and forward again to avoid a fixup; effectively it   
   > replaces an inline ADC BP,0.   
      
   >> OV is only set on transitions from 8000 to 7FFF (opposite for INC) but   
   >> not from 0 to FFFF and reverse, I dont think that my debugger is   
   >> wrong.   
   > perhaps a JNZ would look better?   
      
   it wont matter as long no value set OV.   
      
   >> * XOR BH,[si] JNZ 06A ;if this isn't a 'branch never' it may act   
   >> endless.   
      
   > It's a branch once! BH is 0 at start; it re-executes the previous code.   
      
   Oh, a neat trick indeed.   
      
   >> * EXCH AL,AH  ;Big Endian encoded ?   
   > no, it's to correct for STOSW's Little-Ending storage!   
      
   mmh?   
      
   >> perhaps you can save on one branch in the prologue: JB 0171 JA 0171   
   >> with a single JNE 0171.   
      
   > Ah no, that 2nd JA address gets changed on the fly at the end the search,   
   > to JA to a MOVSB. the JB continues to reject cr/lf etc. after DH is XOR'd   
      
   Ok, I haven't seen this.   
      
   >> Your encoder must be tricky to avoid some characters so your 5:4   
   >> format can use 0x21..0x7D except quote marks (90 characters ?)   
      
   > Ah; no I haven't done any of that (yet?). So it won't be much use In Real   
   > Life.   
      
   I see, your test string was an encoded ASCII-text and not any code.   
      
   > It makes the decoder too big to fit in early memory too; either a lookup   
   > table (+code) or lots of "if x, add 7, if y sub 34" code; c. 30 bytes   
      
   A LUT for 2^32 * 5 byte seems not very practical :)   
   a simple divide by powers of 85 may produce all characters in range, but   
   I cant see anything wrong with quote marks in plain text.   
      
   >> the use of 0x66 overrides may make the whole story easier ie:   
      
   let me try a 16-bit variant with some 66's: [si]->[di]   
   Not tested, just out of my head...   
      
    L0:               ;BP and BX arent used   
   000 MOV cx,5   
   003 PUSH cx   
   004 POP  dx   
   005 AND dword [di],0  ;(66 83 25 00)   
    L1:   
   009 XOR eax,eax    ;(66 31 C0)   
   00C LODSB   
   00D CMP al,7E      ;standard defined end mark ?   
   00F  JZ L4         ;end   
   011 CMP al,21      ;   
   013  JC L1         ;skip   
   015 DEC cx   
   016  JZ L3         ;fifth   
   018 PUSH cx   
    L2:   
   019 IMUL eax,eax,55  ;(66 6B C0 55)   
   01D LOOP L2   
   01F POP cx   
   020 ADD [di],eax     ;(66 01 05)   
   023  JMP L1   
    L3:   
   025 ADD [di],eax     ;again   
   028 ADD di,4   
   02B DEC dx   
   02C  JNZ L1   
   02E  JMP L0   
    L4:   
   030 RET   
      
   ...and if this work at all, I'm sure you'll be able to shorten it and make it   
   SMC-friendlier :)   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)