Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[B 9]

On Thu, Oct 27, 2022 at 8:51 AM MikeS  wrote:

>  It might not be so bad on a 200 but my main annoyance is having to
> scroll up and down on the M100's 8 line screen; as a matter of fact the
> larger screen was the main reason I bought a DVI when they came out.
>

When they came out? I wonder if they were more expensive when they were new
or now that they are rare and "vintage". Is that a picture of your
Disk/Video Interface setup? Looks nifty!


>  For a lot of stuff in the old days I actually used GWBASIC or TBASIC to
> program on a PC; except for screen printing and graphics they're almost
> completely compatible and with a few conditional lines many programs could
> be run and tested on both the PC and the M100.
>

There's something I didn't know! I've been surprised at how capable the
Model T's 8-bit BASIC is. Was it the last one Microsoft made? Given what I
had expected after seeing the Apple ][ and C64, it's quite a bit more
advanced. (For example, ON COM GOSUB). And I read that the NEC 8201A
version of the DVI allowed not only color graphics, but extended the BASIC
language with graphics commands that I think may be from GW-BASIC.


>  I can understand that some folks want to relive the total experience of
> doing everything on the old hardware [...]
>

Sure, and there's nothing wrong with reliving the past. But, that's not me.
I didn't get to experience the M100 when it was current. This is my first
time around with this technology, so part of the fun is trying to see what
it was like back then. I know, it's sort of like people who go camping for
a week to get in touch with their primitive hunter-gatherer ancestors. Not
likely to be terribly accurate, but still, it's fun.


> Nevertheless, for just noodling around while relaxing on the couch not
> much can beat the M100.
>

I'm beginning to learn that! I still haven't got a true Model 100. I only
have a Tandy 200 because my neighbor was throwing it away and wondered if I
could use "an old laptop".  I had no idea what it was. But, given my
experiences so far, maybe I should look into getting the real thing some
day.

—b9

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[Joshua O'Keefe]

> On Oct 27, 2022, at 8:39 PM, B 9  wrote:
> 200 REM Print 2 hexits

In all my years, this is the first time I have seen the term "hexit."  From the 
code it's apparently another way of describing a hex representation of a 
nibble!  Quite a good couple of days for learning from the list, that's for 
sure.  Thanks.

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[B 9]

P.S. I forgot to put in `18 TS$=TIME$`, so the timing is inaccurate. Once I
got that corrected it does seem like PEEKing at the bytes in the integer is
faster than dividing by 4096.

On Thu, Oct 27, 2022 at 8:38 PM B 9  wrote:

> On Thu, Oct 27, 2022 at 3:04 PM John R. Hogerhuis 
> wrote:
>
>>
>> With hex it's a question though since MOD 16 can be done with AND 15
>> which is probably faster than a general integer 16 modulus. There's no
>> bitshift operator so you still need a integer divide by 16%. Who knows how
>> efficient an integer divide by 16 is in the interpreter versus 4096
>> (integer) divides.
>>
>
> That's a good question about efficiency. Integer division by 4096 seems
> reasonably quick, but it would have been nice if BASIC had exposed the bit
> shift operators. (I'm presuming the 8085 had some, right?)
>
> I'm not sure it'd be any faster than division by 4096, but one could use
> the fact that we're using a 2-byte integer for the address and just look at
> each byte.
> hexit.do
>
> 1 TS$=TIME$
> 5 DIM H$(15): *FOR* T=0 *TO* 9:H$(T)=CHR$(48+T): *NEXT* T: *FOR* T=ASC("A") 
> *TO* ASC("F"): H$(T-55)=CHR$(T): *NEXT*
> 6 DIM R$(7): *FOR* T=0 *TO* 7: R$(T)=" ": *NEXT*
> 10 DEFINT A-F, P: D=0: P=VARPTR(D)
> 15 INPUT "Start"; ST%
> 16 INPUT "End"; EN%
> 20 *FOR* D=ST% *TO* EN%
> 30 *IF* (D MOD 8) = 0 *THEN* *PRINT*" ";: *FOR* T=0 *TO* 7: *PRINT* R$(T);: 
> *NEXT*: *PRINT*: S=0: *GOSUB* 400
> 40 *GOSUB* 200
> 90 *NEXT*
> 100 REM Timing
> 110 TE$=TIME$
> 115 *PRINT*
> 120 *PRINT* TS$ " to " TE$
> 199 *END*
> 200 REM Print 2 hexits
> 201 *' *Input: D is address of an 8-bit integer202* '* Output: None, but 2 
> hexits are printed followed by a space
> 210 A=PEEK(D)
> 220 *PRINT *H$(A\16); H$(A MOD 16); " ";
> 230 *IF* A<32 *THEN* A=46
> 240 R$(S)=CHR$(A)
> 250 S=S+1
> 260 *RETURN*
> 400 REM Print 4 hexits
> 401 *' *Input: P is address of a 16-bit little endian integer
> 402* '* Output: None, but 4 hexits are printed followed by a space
> 410 A=PEEK(P+1): B=PEEK(P)
> 420 *PRINT *H$(A\16); H$(A MOD 16); H$(B\16); H$(B MOD 16); " ";
> 430 *RETURN*
>
> --
> —b9
>

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[B 9]

On Thu, Oct 27, 2022 at 3:04 PM John R. Hogerhuis  wrote:

>
> With hex it's a question though since MOD 16 can be done with AND 15 which
> is probably faster than a general integer 16 modulus. There's no bitshift
> operator so you still need a integer divide by 16%. Who knows how efficient
> an integer divide by 16 is in the interpreter versus 4096 (integer)
> divides.
>

That's a good question about efficiency. Integer division by 4096 seems
reasonably quick, but it would have been nice if BASIC had exposed the bit
shift operators. (I'm presuming the 8085 had some, right?)

I'm not sure it'd be any faster than division by 4096, but one could use
the fact that we're using a 2-byte integer for the address and just look at
each byte.
hexit.do

1 TS$=TIME$
5 DIM H$(15): *FOR* T=0 *TO* 9:H$(T)=CHR$(48+T): *NEXT* T: *FOR*
T=ASC("A") *TO* ASC("F"): H$(T-55)=CHR$(T): *NEXT*
6 DIM R$(7): *FOR* T=0 *TO* 7: R$(T)=" ": *NEXT*
10 DEFINT A-F, P: D=0: P=VARPTR(D)
15 INPUT "Start"; ST%
16 INPUT "End"; EN%
20 *FOR* D=ST% *TO* EN%
30 *IF* (D MOD 8) = 0 *THEN* *PRINT*" ";: *FOR* T=0 *TO* 7: *PRINT*
R$(T);: *NEXT*: *PRINT*: S=0: *GOSUB* 400
40 *GOSUB* 200
90 *NEXT*
100 REM Timing
110 TE$=TIME$
115 *PRINT*
120 *PRINT* TS$ " to " TE$
199 *END*
200 REM Print 2 hexits
201 *' *Input: D is address of an 8-bit integer202* '* Output: None,
but 2 hexits are printed followed by a space
210 A=PEEK(D)
220 *PRINT *H$(A\16); H$(A MOD 16); " ";
230 *IF* A<32 *THEN* A=46
240 R$(S)=CHR$(A)
250 S=S+1
260 *RETURN*
400 REM Print 4 hexits
401 *' *Input: P is address of a 16-bit little endian integer
402* '* Output: None, but 4 hexits are printed followed by a space
410 A=PEEK(P+1): B=PEEK(P)
420 *PRINT *H$(A\16); H$(A MOD 16); H$(B\16); H$(B MOD 16); " ";
430 *RETURN*

--
—b9

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[Mike Stein]

I don't see where it makes much difference In general in BASIC but in this
case there is a justification for MSB first ;-)
It goes from MSB to LSB because the same routine does 4 or 2 digits
depending on where you enter; line 5 gives the 4 digit address and it falls
through to line 7 which also gives the 2 digit bytes peeked and creates the
ASCII value for the text on the right hand side.

I suppose going the other way I'd always have to start at the beginning and
return after two digits* 'if'* doing peeks instead of addresses; more
complicated IMO.

m


On Thu, Oct 27, 2022 at 6:04 PM John R. Hogerhuis  wrote:

>
>
> On Thu, Oct 27, 2022 at 1:10 PM MikeS  wrote:
>
>> More good tips, thanks. Yes, I have to look at defining the various
>> types, especially the ones that can go above 32768.
>>
>> Concatenation with '+' is a habit from other languages I've worked with;
>> as a matter of fact in most cases the M100 lets you print without any
>> separators at all, e.g. print A$" to "B$ or a"plus"b
>>
>> Interesting discussion (at least for some of us ;-) )
>>
>>
>
> One overall thing in outputting numbers in any radix, is that it is
> *usually* most tractable in reverse of how you output since we generally
> write/read numbers with the most significant digit first. So for generating
> a number to output, It is most efficient to extract the least significant
> digit, shift or otherwise divide by the radix, prepend the extracted number
> onto a string/buffer, and when the value gets to zero, you're done, output
> the string.
>
> So for the number 1235 in decimal,
>
> 1235 MOD 10 = 5. Prepend ASC('0') + 5 on buffer. Divide remaining value by
> 10
> 123 MOD 10 = 3. Prepend  ASC('0') + 3 on buffer.  Divide remaining value
> by 10
> 12 MOD 10 = 2.  Prepend  ASC('0') + 2 on buffer.  Divide remaining value
> by 10
> 1 MOD 10 = 1. Prepend  ASC('0') + 1 on buffer. Divide remaining value by 10
> Remaining value is 0, so we're done. Buffer contains the number
>
> In your subroutine at 5 it is doing it MSB to LSB, I think. Overall your
> way may still be faster in BASIC even with the larger divisors.
>
> With hex it's a question though since MOD 16 can be done with AND 15 which
> is probably faster than a general integer 16 modulus. There's no bitshift
> operator so you still need a integer divide by 16%. Who knows how efficient
> an integer divide by 16 is in the interpreter versus 4096 (integer)
> divides.
>
> -- John.
>
>>

Re: [M100] Compute a 16-bit signed value in BASIC

[MikeS]

Yeah, i try to avoid IF..THEN wherever I can, especially if it requires an 
extra line.

It does give some strange-looking code though, like line 40 in the HEX to 
decimal conversion in my dump program that conditionally converts the from/to 
address digits to upper case if necessary by subtracting 32 (a simple AND 95 
would probably have been simpler ;-) )

Convert up to 4 HEX digits in X$ to decimal equivalent in X:

20 X=0:X$=RIGHT$(""+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))

  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Thursday, October 27, 2022 5:19 PM
  Subject: Re: [M100] Compute a 16-bit signed value in BASIC


  I was curious if loading a string pointer could be done without an explicit 
IF.


  Seems like what we're doing is J as LSB, K as MSB

  K>127: J + K*256-65536
  or
  K<=127: J + K*256 - 0


  Taking J + K * 256 - 65536


  factoring out 256 and putting both functions in a similar form:

  K > 127: J + 256 ( K - 256)
  K <= 127: J + 256 ( K - 0 )

  Knowing comparisons can be done without 'IF'... if an expression is true you 
get -1 and 0 if false, we can inline the conditional into the expression 

  So the computation without IF would be

  J + 256% * ( K + 256% * (K > 127%))

  So something like this:

  10 DEFINTP:DEFSTRH
  20 H=CHR$(201)
  30 P=VARPTR(H)+1
  1000 P=PEEK(P)+256%*(PEEK(P+1)+256%*(PEEK(P+1)>127))
  1010 PRINTP


  Not sure if this works, particularly with the integer constants. And there 
might be speed optimizations... certainly it is doing the MSB peek twice.


  -- John.

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[John R. Hogerhuis]

On Thu, Oct 27, 2022 at 1:10 PM MikeS  wrote:

> More good tips, thanks. Yes, I have to look at defining the various types,
> especially the ones that can go above 32768.
>
> Concatenation with '+' is a habit from other languages I've worked with;
> as a matter of fact in most cases the M100 lets you print without any
> separators at all, e.g. print A$" to "B$ or a"plus"b
>
> Interesting discussion (at least for some of us ;-) )
>
>

One overall thing in outputting numbers in any radix, is that it is
*usually* most tractable in reverse of how you output since we generally
write/read numbers with the most significant digit first. So for generating
a number to output, It is most efficient to extract the least significant
digit, shift or otherwise divide by the radix, prepend the extracted number
onto a string/buffer, and when the value gets to zero, you're done, output
the string.

So for the number 1235 in decimal,

1235 MOD 10 = 5. Prepend ASC('0') + 5 on buffer. Divide remaining value by
10
123 MOD 10 = 3. Prepend  ASC('0') + 3 on buffer.  Divide remaining value by
10
12 MOD 10 = 2.  Prepend  ASC('0') + 2 on buffer.  Divide remaining value by
10
1 MOD 10 = 1. Prepend  ASC('0') + 1 on buffer. Divide remaining value by 10
Remaining value is 0, so we're done. Buffer contains the number

In your subroutine at 5 it is doing it MSB to LSB, I think. Overall your
way may still be faster in BASIC even with the larger divisors.

With hex it's a question though since MOD 16 can be done with AND 15 which
is probably faster than a general integer 16 modulus. There's no bitshift
operator so you still need a integer divide by 16%. Who knows how efficient
an integer divide by 16 is in the interpreter versus 4096 (integer)
divides.

-- John.

>

Re: [M100] Compute a 16-bit signed value in BASIC

[John R. Hogerhuis]

I was curious if loading a string pointer could be done without an explicit
IF.

Seems like what we're doing is J as LSB, K as MSB

K>127: J + K*256-65536
or
K<=127: J + K*256 - 0

Taking J + K * 256 - 65536

factoring out 256 and putting both functions in a similar form:

K > 127: J + 256 ( K - 256)
K <= 127: J + 256 ( K - 0 )

Knowing comparisons can be done without 'IF'... if an expression is true
you get -1 and 0 if false, we can inline the conditional into the
expression

So the computation without IF would be

J + 256% * ( K + 256% * (K > 127%))

So something like this:

10 DEFINTP:DEFSTRH
20 H=CHR$(201)
30 P=VARPTR(H)+1
1000 P=PEEK(P)+256%*(PEEK(P+1)+256%*(PEEK(P+1)>127))
1010 PRINTP

Not sure if this works, particularly with the integer constants. And there
might be speed optimizations... certainly it is doing the MSB peek twice.

-- John.

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

More good tips, thanks. Yes, I have to look at defining the various types, 
especially the ones that can go above 32768.

Concatenation with '+' is a habit from other languages I've worked with; as a 
matter of fact in most cases the M100 lets you print without any separators at 
all, e.g. print A$" to "B$ or a"plus"b

Interesting discussion (at least for some of us ;-) )

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Thursday, October 27, 2022 3:39 PM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated





  On Thu, Oct 27, 2022, 12:14 PM MikeS  wrote:

Good tips.

DEFINT a-z reduced the time to print 50 lines from 61 seconds to 51

I'd also forgotten about integer division; that reduced it another 4 
seconds to 47.

Any more ideas?

m


  Seems like you can declare constants in expressions as integers? So 4096 
would be 4096% I guess.


  I haven't experimented much with it but it might prevent copies, casts, 
intermediate calculations from going to double precision floats..


  And I don't know if there's much difference but you added two strings that 
were being printed. It might be faster to use ; instead of + since it doesn't 
do a intermediate string copy. 


  -- John. 

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[John R. Hogerhuis]

On Thu, Oct 27, 2022, 12:14 PM MikeS  wrote:

> Good tips.
>
> DEFINT a-z reduced the time to print 50 lines from 61 seconds to 51
>
> I'd also forgotten about integer division; that reduced it another 4
> seconds to 47.
>
> Any more ideas?
>
> m
>

Seems like you can declare constants in expressions as integers? So 4096
would be 4096% I guess.

I haven't experimented much with it but it might prevent copies, casts,
intermediate calculations from going to double precision floats..

And I don't know if there's much difference but you added two strings that
were being printed. It might be faster to use ; instead of + since it
doesn't do a intermediate string copy.

-- John.

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Good tips.

DEFINT a-z reduced the time to print 50 lines from 61 seconds to 51

I'd also forgotten about integer division; that reduced it another 4 seconds to 
47.

Any more ideas?

m
  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  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  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$(""+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" 
To: 
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

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Hi,

It might not be so bad on a 200 but my main annoyance is having to scroll up 
and down on the M100's 8 line screen; as a matter of fact the larger screen was 
the main reason I bought a DVI when they came out.

The keyboard is definitely better than most laptops but I prefer a good solid 
desktop keyboard; IMO programming on a modern PC is just so much faster and 
smoother in general. I haven't used it much but Virtual T has to be the perfect 
compromise. 

For a lot of stuff in the old days I actually used GWBASIC or TBASIC to program 
on a PC; except for screen printing and graphics they're almost completely 
compatible and with a few conditional lines many programs could be run and 
tested on both the PC and the M100.

I can understand that some folks want to relive the total experience of doing 
everything on the old hardware but personally I prefer to use whatever's 
fastest, most convenient, has the most options etc.

Nevertheless, for just noodling around while relaxing on the couch not much can 
beat the M100.

m



 
  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Thursday, October 27, 2022 12:45 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  I'm curious what you've found the biggest PITA about programming on real 
hardware has been? I've been directly programming on my Tandy 200 and maybe 
it's just because my expectations were so low, but it's actually surprisingly 
nice. 16 lines of text is a good enough window. The arrow keys on the T200 are 
easy to use (and make sensible jumps with SHIFT and CTRL). Even so, just for 
fun I've been trying to learn what all the CTRL keys do. (I heard that it was 
vaguely WordStar like, but I never used that.) My biggest problem with coding 
on the T200 right now is that I am low on memory, so I can only EDIT small 
chunks of the program at a time.All in all, though, quite fun!



  —b9



  On Wed, Oct 26, 2022 at 8:46 PM MikeS  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$(""+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" 
To: 
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
> 

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

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: m...@bitchin100.com 
  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  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$(""+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" 
To: 
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

Re: [M100] Compute a 16-bit signed value in BASIC

[Ken Pettit]

On 10/26/22 11:50 PM, John R. Hogerhuis wrote:



On Wed, Oct 26, 2022 at 4:57 PM Ken Pettit > wrote:



You have to make it a negative number by subtracting it from 65536:

20 H$="0123456789ABCDEF":

D=VARPTR(H$)+1:IFPEEK(D+1)>127THENC=65536-256*PEEK(D+1)-PEEK(D)ELSEC=PEEK(D)+256*PEEK(D+1)



Thanks! Makes sense.

Pity about the conditional.



Yep.  And actually, that should have been C=256*PEEK(D+1)+PEEK(D) - 
65536, otherwise it is just a different positive value.


Ken

Re: [M100] Compute a 16-bit signed value in BASIC

[John R. Hogerhuis]

On Wed, Oct 26, 2022 at 4:57 PM Ken Pettit  wrote:

>
> You have to make it a negative number by subtracting it from 65536:
>
> 20 H$="0123456789ABCDEF":
>
> D=VARPTR(H$)+1:IFPEEK(D+1)>127THENC=65536-256*PEEK(D+1)-PEEK(D)ELSEC=PEEK(D)+256*PEEK(D+1)
>
>
>
Thanks! Makes sense.

Pity about the conditional.

-- John.