Unfortunately some ASC codes can't be stored as a string so there is a
clever sub-routine that handles this problem. All of the ABC packets
call this decoder "SUB U" and here it is (cleaned up a bit for clarity):
SUB U (A$)
FOR A = 1 TO LEN(A$)
C = ASC(MID$(A$, A)) - 37
IF C < 0 THEN C = 91 + C * 32
IF K < 4 THEN K = C + 243 ELSE PRINT #ZipFile, CHR$(C + (K MOD 3) * 86);
K = K \ 3
B& = B& + 1
S = (S + C) AND 255
NEXT
END SUB
And here are a few sample strings that it processes:
CALL U "%up()%9%%%I-%zORGG:P=SB/(.%%[/%%%-%%%%in%xpSgRfx&%;<>T[j5w=9ZxZ"
CALL U "_s>bl_[t'4&Gt%9/eh)W922qkteUUO*w)g\J?pId:<ZsX#rks=A6H%BkLi)GFHS"
My question is, does anyone have the sub-routine to do this in reverse?
What I'm actually working on are LFN routines that I hope to put into my
QB45 library. Right now my PROBAS and CRESCENT lib file routines only
handle 8.3 file names. In digging through the ABC packets I came across
some interesting call Absolute routines that I don't understand but that
I'm hoping to adapt. But the code is unnecessarily long and I want to
condense it. Here's an example:
asm$ = asm$ + CHR$(&H55)
asm$ = asm$ + CHR$(&H89) + CHR$(&HE5)
asm$ = asm$ + CHR$(&H57)
asm$ = asm$ + CHR$(&H6)
asm$ = asm$ + CHR$(&H56)
asm$ = asm$ + CHR$(&H1E)
asm$ = asm$ + CHR$(&H8B) + CHR$(&H5E) + CHR$(&H6)
asm$ = asm$ + CHR$(&H8B) + CHR$(&H3F)
asm$ = asm$ + CHR$(&H8B) + CHR$(&H5E) + CHR$(&H8)
asm$ = asm$ + CHR$(&H8E) + CHR$(&H7)
asm$ = asm$ + CHR$(&H8B) + CHR$(&H5E) + CHR$(&HA)
asm$ = asm$ + CHR$(&H8B) + CHR$(&H17)
asm$ = asm$ + CHR$(&H8B) + CHR$(&H5E) + CHR$(&HE)
asm$ = asm$ + CHR$(&H8A) + CHR$(&H2F)
asm$ = asm$ + CHR$(&H8B) + CHR$(&H5E) + CHR$(&H10)
asm$ = asm$ + CHR$(&H8A) + CHR$(&HF)
..... and on, and on...
I would like to do the ABC trick and store this more efficiently. Sorry
for the excessive length of this post! Appreciate all your help.
Love to help but it could be tricky with the routine that you've
posted. The trouble is that it's not the whole story. It only creates
part of the file. Note the variables B&, S which are calculated within
the routine but not used within it. They are likely to be global
variables which are used in another routine which also writes to the
file. The variable B& in particular may be placed somewhere in that
file and we really need to know where if we are going to decode it
successfully.
Cheers
Derek
Love to help but it could be tricky with the routine that you've
The B& is not important and I should have removed it when I reformatted
the code. The variables in this sub are preserved with a share
statement but they are only used or modified by this sub. Here is the
actual subroutine without any of my re-formating:
SUB U(A$):FOR A=1TO LEN(A$):C=ASC(MID$(A$,A))-37:IF C<0THEN C=91+C*32
IF K<4THEN K=C+243ELSE?#1,CHR$(C+(K MOD 3)*86);:K=K\3:B&=B&+1
S=(S+C)AND 255:NEXT:LOCATE,1:?STRING$(B&*50\Z&,219);:END SUB
As you can see, the B& variable is just used to print a progress bar on
the screen.
Today, after some more research, I did find the source code to make
these condensed zip files. The program is called PostIt! but it's
hundreds of lines and extremely complex to understand. It's an
interesting puzzle but for my purposes I've decided to just make a
substitution table for the errant chr$'s. Thanks for your input.
Oh well. That's good news.
Cheers
Derek