Thanks; that was on my mental list of possible speedups. Speaking of, I ran into the same signed integer issue as John, i.e. MOD can only deal with values up to 32768.
What you say about GOTO and GOSUB is interesting; that suggests that they should always be forward references as opposed to being close to the beginning. Further research is indicated ;-) m ----- Original Message ----- From: B 9 To: [email protected] Sent: Thursday, October 27, 2022 1:16 AM Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated You can get a small (~15%) speedup just by doing this: 0 DEFINT A-D, L, X, Y —b9 On Wed, Oct 26, 2022 at 8:46 PM MikeS <[email protected]> wrote: Oops; looks like I forgot to attach my version last night; good thing, found a couple of bugs tonight. Looks like it could be speeded up a bit; no error checking. I'd forgotten what a PITA it was to program on the real hardware. 1 DEFSTRH:H="0123456789ABCDEF":GOTO100 5 A=INT(X/4096):X=X-A*4096:B=INT(X/256) 6 PRINTMID$(H$,A+1,1)+MID$(H$,B+1,1); 7 C=INT((XMOD256)/16):D=XMOD16:Y=C*16+D 8 PRINTMID$(H,C+1,1)+MID$(H,D+1,1)+" "; 9 RETURN 20 X=0:X$=RIGHT$("0000"+X$,4) 30 FORI=1TO4:Y=ASC(MID$(X$,I,1)) 40 Y$=CHR$(Y+(Y>95)*32) 50 L=INSTR(1,H,Y$)-1:X=X+L*(16^(4-I)) 60 NEXT:RETURN 100 INPUT"From";S$:INPUT"to";E$ 110 X$=S$:GOSUB20:S=X 120 X$=E$:GOSUB20:E=X 200 B$=TIME$:FORI=STOESTEP8:X=I:GOSUB5 210 L$="":FORJ=0TO7:X=PEEK(I+J):GOSUB7 220 Y=C*16+D 230 Y$=".":IFY>31ANDY<127THENY$=CHR$(Y) 240 L$=L$+Y$:NEXT:PRINTL$:NEXT 250 PRINTB$+" to "+TIME$:END Constructive criticism welcome. m ----- Original Message ----- From: "runrin" <[email protected]> To: <[email protected]> Sent: Wednesday, October 26, 2022 10:24 PM Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated > this seemed fun so i gave it a quick try. here's what i came up with. > > it's a shame you can't do bitshift operations because i suspect > ``((V AND 240) >> 4)'' would be faster than using integer division. > > i'm a total neophyte when it comes to basic so i don't think this code > is actually very fast. at least it's faster than the screen scrolls :P. > in both examples i'm just peeking 0-59 since it's what fits on the > screen nicely. that's also the reason for the " ". > > i like this version because it makes the print statement easy to read, > it takes a lot more memory to store each character as it's own string > though. > > 10 DATA "0","1","2","3","4","5","6","7","8","9","A","B","C","D","E","F" > 20 DIM H$(15) > 30 FOR I = 0 TO 15 > 40 READ H$(I) > 50 NEXT > 60 FOR I = 0 to 59 > 70 V = PEEK(I) > 80 PRINT H$(V \ 16); H$(V AND 15); " "; > 90 NEXT > > --- > > i made another version that uses string pointers because i felt bad > using 16 strings. the PEEKS seem to be pretty expensive though, so i > think it's actually slower than the previous version, but the code is a > bit clearer. using MID$ is probably faster, but i mostly just did this > for fun. this is more along the lines of how i would do something like > this in C, which is the language i'm most familiar with. > > string pointers are weird in basic. the pointer returned by VARPTR(S$) > points to the following: > > ptr + 0 = string length > ptr + 1 = low byte of pointer to string > ptr + 2 = high byte of pointer to string > > i had to look in the basic language lab (pp. 182) to find that > information. it's not even listed on > https://help.ayra.ch/trs80-reference . i think i would have preferred > if it just returned the string pointer with null terminator lol. not > sure why they did it this way. anyway, here's the code: > > 10 H$ = "0123456789ABCDEF" > 20 P = VARPTR(H$) > 30 SP = PEEK(P + 1) + PEEK(P + 2) * 256 > 40 FOR I = 0 TO 59 > 50 V = PEEK(I) > 60 PRINT CHR$(PEEK(SP + (V \ 16))); CHR$(PEEK(SP + (V AND 15))); " "; > 70 NEXT > > i know those extra spaces make my code slower, i'm just formatting it > that way here so its actually legible. > > -runrin
