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

[MikeS]

Verbose ruminations? We doan need no steenkin' documentation!

Here's my latest (final?) version incorporating some of the ideas and hopefully 
a little less esoteric. Time to print 50 lines from 61 seconds down to 34, size 
from 635 bytes down to 406. Funny to watch it dump itself ;-)

BTW, just to repeat: LOADing from a PC using TEXT runs flawlessly at 9600bd 
whereas loading from BASIC definitely drops characters. 

It's actually sorta been fun programming on the 'real' M100; I left a download 
running on the PC and every time I wanted to backup an interim version just in 
case, I just pressed F3 and F7 (which I'd programmed with the COM stats).

As usual, constructive criticism welcome.

1 DEFINTJ-Z:DIMH$(15):FORI=0TO15:REM V3
10 H$(I)=CHR$(48+I-(7*(I>9))):NEXT:CLS
15 INPUT"From";A:INPUT"to";B:T$=TIME$
20 FORI=ATOBSTEP8:K=I/4096:PRINTH$(K);
25 L=(I-K*4096):PRINTH$(L\256);
30 PRINTH$((LMOD256)\16)H$(LMOD16)" ";
40 L$="":FORJ=0TO7:X=PEEK(I+J)
50 PRINTH$(X\16);H$(XMOD16)" ";
60 Y$=".":IFX>31ANDX<127THENY$=CHR$(X)
70 L$=L$+Y$:NEXT:PRINTL$:NEXT
80 E$=TIME$:PRINTT$+" to "+E$:END

-
 1 Initialize
10 Load H$( array with 1-F
15 Get range, start timer
20-30 Convert & print every 8th address
40 PEEK 8 bytes
50 Convert & print bytes
60 Replace invalid chars with '.'
70 Assemble and print text
80 Print elapsed time



  - Original Message - 
  From: Will Senn 
  To: m100@lists.bitchin100.com 
  Sent: Friday, October 28, 2022 1:54 PM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  Oh yes, am I ever. A bit overwhelmed, actually. It'll take me a month to work 
through all of these suggestions and potential optimizations :). I suspected 
there were folks in the world who took BASIC to its edges, but I had no idea 
:). The thread on that weird listing a while back should have been a clue, but 
I thought it was a one-off. I'm in awe of y'all's grasp of the finer points and 
look forward to learning more. I tend to try to avoid the more esoteric 
optimizations in favor of clarity, but in this case, so long as I notate 
appropriately, I'll get over it! It seems like folks tend to move their more 
verbose ruminations out of the BASIC files and into accompanying .DO files, 
that about right?

  Thanks, 

  Will

  On 10/28/22 2:07 AM, MikeS wrote:

 
Thanks for that; I'll have to check it out later. Meanwhile, I think if 
we're going to use a lookup table at all then I also prefer your use of an 
array for H$, but I'd load it a little differently (as John and I were 
discussing):

5 DIM H$(15):FOR T=0 TO 15:H$(T)=CHR$(48+T-(7*(T>9))):NEXT

Tsk, tsk; you're cheating by inputting the range in decimal so you don't 
have to do a HEX to decimal conversion ;-) I suppose it makes sense though...

More serious, using integers for the addresses restricts the dump to 
<8000H; I had the same problem first time around.

Enjoying the thread... wonder if Will's getting anything out of it ;-)

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


  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 integer
202 ' 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

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

[Eric LK]

"John R. Hogerhuis"  wrote:
> 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

Very nice. That seems a little more optimized than the solution I used
for my "direct file access from RAM" implementation :o)

You could skip the second multiplication by using AND instead:
1000 P=PEEK(P)+256%*(PEEK(P+1)-(PEEK(P+1)>127AND256))
(Note that the sign has been reversed) but... somehow the execution
time isn't really impacted (I suppose multiplying by -1 is fast)

FWIW, I also tried "caching" the result of "PEEK(P+1)" but again, it
didn't change the result (in all 3 implementations, 1000 iterations
took 14 seconds, so those modifications aren't really interesting,
except for the brain picking exercise ;o)).

If I may ask a question, I almost dever used DEFINT and DEFSTR: I just
use "%" or "$" prefixes for my variables. Are DEFINT and DEFSTR faster
or is this a question of personal preferences?

I kind of like that I can tell the type of variables by their name,
but if the other solution gives a performance boost I'm ready to
reconsider.

Eric

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

[John R. Hogerhuis]

As to type sigils on variables... Don't know how much it changes ram use or
execution time. Some! Maybe look at the tokenized output difference for the
space difference.

As to the multiplication versus the AND... you'd have to test. Interesting.
I will try it.

Speaking of testing, I'm wondering if the conditional expression is ok to
avoid on the first PEEK. The intent of this is to generate a signed integer
number on the range -32768 to 32767. If it goes over 32767 on any
permutation of peek'd values it will fail. Probably worth generating every
permutation and confirming it works.

-- John.

On Sat, Oct 29, 2022, 4:16 AM Eric LK  wrote:

> "John R. Hogerhuis"  wrote:
> > 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
>
> Very nice. That seems a little more optimized than the solution I used
> for my "direct file access from RAM" implementation :o)
>
> You could skip the second multiplication by using AND instead:
> 1000 P=PEEK(P)+256%*(PEEK(P+1)-(PEEK(P+1)>127AND256))
> (Note that the sign has been reversed) but... somehow the execution
> time isn't really impacted (I suppose multiplying by -1 is fast)
>
> FWIW, I also tried "caching" the result of "PEEK(P+1)" but again, it
> didn't change the result (in all 3 implementations, 1000 iterations
> took 14 seconds, so those modifications aren't really interesting,
> except for the brain picking exercise ;o)).
>
> If I may ask a question, I almost dever used DEFINT and DEFSTR: I just
> use "%" or "$" prefixes for my variables. Are DEFINT and DEFSTR faster
> or is this a question of personal preferences?
>
> I kind of like that I can tell the type of variables by their name,
> but if the other solution gives a performance boost I'm ready to
> reconsider.
>
> Eric
>

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

[Will Senn]

Wow. Crazy fast. I've been schooled for sure. For a program with no 
whitespace to speak of, it's pretty straightforward (not that I would 
have come up with it anytime soon, but it reads well). Thanks for taking 
the time and providing it... along with the comments!Lots of things to 
think about and learn about here.


Will

On 10/29/22 4:07 AM, MikeS wrote:
Verbose ruminations? We doan need no steenkin' documentation!
Here's my latest (final?) version incorporating some of the ideas and 
hopefully a little less esoteric. Time to print 50 lines from 61 seconds 
down to 34, size from 635 bytes down to 406. Funny to watch it dump 
itself ;-)
BTW, just to repeat: LOADing from a PC using TEXT runs flawlessly at 
9600bd whereas loading from BASIC definitely drops characters.
It's actually sorta been fun programming on the 'real' M100; I left a 
download running on the PC and every time I wanted to backup an interim 
version just in case, I just pressed F3 and F7 (which I'd programmed 
with the COM stats).

As usual, constructive criticism welcome.
1 DEFINTJ-Z:DIMH$(15):FORI=0TO15:REM V3
10 H$(I)=CHR$(48+I-(7*(I>9))):NEXT:CLS
15 INPUT"From";A:INPUT"to";B:T$=TIME$
20 FORI=ATOBSTEP8:K=I/4096:PRINTH$(K);
25 L=(I-K*4096):PRINTH$(L\256);
30 PRINTH$((LMOD256)\16)H$(LMOD16)" ";
40 L$="":FORJ=0TO7:X=PEEK(I+J)
50 PRINTH$(X\16);H$(XMOD16)" ";
60 Y$=".":IFX>31ANDX<127THENY$=CHR$(X)
70 L$=L$+Y$:NEXT:PRINTL$:NEXT
80 E$=TIME$:PRINTT$+" to "+E$:END
-
 1 Initialize
10 Load H$( array with 1-F
15 Get range, start timer
20-30 Convert & print every 8th address
40 PEEK 8 bytes
50 Convert & print bytes
60 Replace invalid chars with '.'
70 Assemble and print text
80 Print elapsed time

   - Original Message -
   *From:* Will Senn 
   *To:* m100@lists.bitchin100.com
   *Sent:* Friday, October 28, 2022 1:54 PM
   *Subject:* Re: [M100] Notoriously S.L.O.W BASIC posted - help
   speeding it up appreciated

   Oh yes, am I ever. A bit overwhelmed, actually. It'll take me a
   month to work through all of these suggestions and potential
   optimizations :). I suspected there were folks in the world who took
   BASIC to its edges, but I had no idea :). The thread on that weird
   listing a while back should have been a clue, but I thought it was a
   one-off. I'm in awe of y'all's grasp of the finer points and look
   forward to learning more. I tend to try to avoid the more esoteric
   optimizations in favor of clarity, but in this case, so long as I
   notate appropriately, I'll get over it! It seems like folks tend to
   move their more verbose ruminations out of the BASIC files and into
   accompanying .DO files, that about right?

   Thanks,

   Will

   On 10/28/22 2:07 AM, MikeS wrote:


Thanks for that; I'll have to check it out later. Meanwhile, I
think if we're going to use a lookup table at all then I also
prefer your use of an array for H$, but I'd load it a little
differently (as John and I were discussing):
5 DIM H$(15):FOR T=0 TO 15:H$(T)=CHR$(48+T-(7*(T>9))):NEXT
Tsk, tsk; you're cheating by inputting the range in decimal so you
don't have to do a HEX to decimal conversion ;-) I suppose it
makes sense though...
More serious, using integers for the addresses restricts the dump
to <8000H; I had the same problem first time around.
Enjoying the thread... wonder if Will's getting anything out of it ;-)
m

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

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*" ";:*FO

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

[Will Senn]

Hi Mike,

I'm curious about the COM stuff. In a later note you said:

It's actually sorta been fun programming on the 'real' M100; I left a 
download running on the PC and every time I wanted to backup an interim 
version just in case, I just pressed F3 and F7 (which I'd programmed 
with the COM stats).


and here, you say stuff about programming the function keys with 
"COM:88N1E"...


It would be nice to be able to transfer / save from BASIC and/or my 
terminal on the Mac without the overhead of dl/TEENY.CO. I know enough 
to be dangerous and that the keys can easily be programmed to 
effectively type stuff. I'm just not clear on is how this works 
mechanically. Are you in BASIC, typing away, having just fixed some bit 
and are ready to SAVE it remotely, so you press F3 and voila, it just 
does it, or do you press F3 and then do something to get it 
transferring, or what?


I have the cables hooked up and usually, I:
1. SAVE from BASIC to .DO or .BA
2. Start up DL on the Mac side, if it isn't already running in my ~/m100 
directory

3. Press F8 to get menu
4. Select TEENY.CO
5. Type S HEXIT .DO
6. Watch it complete without error (so long as HEXIT.DO doesn't already 
exist, I think)


What I'm imagining happen is:
1. SAVE from BASIC to .DO or .BA
2. Press F3
3. Magically a file is sent and received on the Mac (where does it's 
name come from?)

4. Celebration
or
1. F2 from BASIC
2. Start sending a file (how?) from the Mac
3. Celebration

Just curious!

Will


On 10/28/22 12:30 PM, MikeS wrote:


Yeah, that's a setup I used for a while, sort of a poor man's 
tablet/clamshell 'convertible. ;-) No problem extending the cable to 
around 2 feet.
Never did use the disk drives very much although I did install a 
second  one; even today while playing with Will's dump program it's so 
simple to plug in the cable to the PC, select download or upload on 
the PC and either BASIC F3 (SAVE) to com: or TEXT F2 (LOAD) from com:, 
not to mention being able to print on the PC and send/receive over the 
Internet.
Question for the experts: I have "COM:88N1E" stored in one of the 
BASIC function keys; I don't suppose there's a way to do that for TEXT?
Back in the day IIRC the DVI and the M100 were both around $800; 
probably still have the receipts somewhere; don't know what that'd be 
today..
And yes, the Model T and NEC BASICs are remarkably versatile, 
especially considering the size constraints.

Definitely unique and, I don't know, friendly in a way...
m

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



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 

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

[MikeS]

Hi Will,

Too many times I've made some changes and either accidentally deleted the file 
or messed it up so badly that I want to revert to the previous version, so I've 
learned the hard way that it's a good idea to save the work before making major 
changes.

One way is to SAVE it locally on the M100 as a .DO file ("Foo.do" or "Foo",A) , 
changing the name as appropriate; note that BASIC will save a file as .BA by 
default but will LOAD a .DO file without specifying the '.DO' or ',A' if no .BA 
file with the same file exists. Of course if it's a very large file you may not 
have room for both the .BA and .DO files in RAM at the same time.

What I do if I'm close enough to a PC to easily connect or stay connected is to 
open a file (e.g. "backup.txt") on the PC for ASCII text download with a 
terminal program and just leave it open.

On the M100 I've programmed F7 to 'Key 7, "COM:88N1E"', so when I want to save 
the file I'm working on I press F3 to save, F7 in response to 'Save "' and 
Return. It's a good idea to embed a version no. in the program and update it 
every time.

This concatenates all the saved files in one file; if you actually need to go 
back then you'd have to stop the transfer, edit the file on the PC and send it 
back to the M100. Of course you can open a new file on the PC every time if you 
don't mind typing on the PC every time.

To Load a .DO file from the PC, open TEXT, enter the File name, LOAD (F2) and 
enter 'COM:88N1E' in response to 'Load from:'; on the PC terminal program 
select Upload ASCII or whatever it's called and the file name (which does not 
have to be the same as on the M100). You may not see anything happening but the 
terminal program should indicate somehow when the transfer is finished. Type a 
CTL-Z on the PC and the file should appear on the M100; switch to BASIC and 
Load it, and Bob's your mother's brother.

This is mainly meant for folks who want to or have to just use the M100's 
built-in functions, and to show how to avoid overruns when Loading BASIC .DO 
programs as in a previous post here a few days ago.

Teeny, TS-DOS etc. certainly are very useful and in fact necessary if you're 
working with .BA tokenized files or Machine language code.

Other than my phone I'm not an Apple kind of guy, so I can't give any 
Mac-specific hints.

One other hint: to simplify switching from RUN to EDIT mode I've programmed 
'F6,"Edit"+chr$(13)'

Not too verbose, I hope...

m


  - Original Message - 
  From: Will Senn 
  To: m100@lists.bitchin100.com 
  Sent: Saturday, October 29, 2022 10:16 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  Hi Mike,

  I'm curious about the COM stuff. In a later note you said:


  It's actually sorta been fun programming on the 'real' M100; I left a 
download running on the PC and every time I wanted to backup an interim version 
just in case, I just pressed F3 and F7 (which I'd programmed with the COM 
stats).

  and here, you say stuff about programming the function keys with 
"COM:88N1E"...

  It would be nice to be able to transfer / save from BASIC and/or my terminal 
on the Mac without the overhead of dl/TEENY.CO. I know enough to be dangerous 
and that the keys can easily be programmed to effectively type stuff. I'm just 
not clear on is how this works mechanically. Are you in BASIC, typing away, 
having just fixed some bit and are ready to SAVE it remotely, so you press F3 
and voila, it just does it, or do you press F3 and then do something to get it 
transferring, or what?

  I have the cables hooked up and usually, I:
  1. SAVE from BASIC to .DO or .BA
  2. Start up DL on the Mac side, if it isn't already running in my ~/m100 
directory
  3. Press F8 to get menu
  4. Select TEENY.CO
  5. Type S HEXIT .DO
  6. Watch it complete without error (so long as HEXIT.DO doesn't already 
exist, I think) 

  What I'm imagining happen is:
  1. SAVE from BASIC to .DO or .BA
  2. Press F3
  3. Magically a file is sent and received on the Mac (where does it's name 
come from?)
  4. Celebration
  or
  1. F2 from BASIC
  2. Start sending a file (how?) from the Mac
  3. Celebration

  Just curious!

  Will



  On 10/28/22 12:30 PM, MikeS wrote:

 
Yeah, that's a setup I used for a while, sort of a poor man's 
tablet/clamshell 'convertible. ;-) No problem extending the cable to around 2 
feet.

Never did use the disk drives very much although I did install a second  
one; even today while playing with Will's dump program it's so simple to plug 
in the cable to the PC, select download or upload on the PC and either BASIC F3 
(SAVE) to com: or TEXT F2 (LOAD) from com:, not to mention being able to print 
on the PC and send/receive over the Internet.

Question for the experts: I have "COM:88N1E" stored in one of the BASIC 
function keys; I don't suppose there's a way to do that for TEXT?

Back in the day IIRC the DVI and the M100 were both around $800; probably 
still have

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

[Eric LK]

I wrote:
>FWIW, I also tried "caching" the result of "PEEK(P+1)" but again,
>it didn't change the result (in all 3 implementations, 1000
>iterations took 14 seconds, so those modifications aren't really
>interesting, except for the brain picking exercise ;o)).

Well, I managed to (almost) half this time :o) : 8 seconds for 1000 iterations!

I'd like to say I found a very innovative solution, but it's so simple
I wonder how we didn't think of it before... Just let the BASIC do the
work for you :o)

10 DEFINTP-Q:DEFSTRH
20 H=CHR$(201)
30 P=VARPTR(H)+1:Q=VARPTR(P)
1000 POKE Q,PEEK(P):POKE Q+1,PEEK(P+1)
1010 PRINTP

"John R. Hogerhuis"  wrote:
> As to type sigils on variables... Don't know how much it changes ram use
> or execution time. Some! Maybe look at the tokenized output difference
> for the space difference.

Thanks, I may give it a try. BTW, is there a good documentation of the
tokenized format (and of the variables encoding) for the M100? I
learned a lot about the ZX-Spectrum BASIC by reading the user guide
which gives a lot of implementation details about this, but I don't
remember the M100 user manual going so deep.

> If it goes over 32767 on any permutation of peek'd values it will fail.
> Probably worth generating every permutation and confirming it
> works.

I suspect the integer conversion is only made when the value is stored
in the integer variable.
For example, this totally works:
A%=1E15/1E14:?A%

The only thing to be careful with is using functions that can only
work with integer arguments like \ or AND:
?1E15\1E14 => OV Error
?!E15AND1E14 => OV Error

Eric

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

[Will Senn]

Clever. Thanks for the specifics. I'm gonna give it a go. Minicom 
receive text and then just save whenever I like, it concatenates, and 
provides a nice history. Sweet.


Will

On 10/29/22 12:24 PM, MikeS wrote:


Hi Will,
Too many times I've made some changes and either accidentally deleted 
the file or messed it up so badly that I want to revert to the 
previous version, so I've learned the hard way that it's a good idea 
to save the work before making major changes.
One way is to SAVE it locally on the M100 as a .DO file ("Foo.do" or 
"Foo",A) , changing the name as appropriate; note that BASIC will save 
a file as .BA by default but will LOAD a .DO file without specifying 
the '.DO' or ',A' if no .BA file with the same file exists. Of course 
if it's a very large file you may not have room for both the .BA and 
.DO files in RAM at the same time.
What I do if I'm close enough to a PC to easily connect or stay 
connected is to open a file (e.g. "backup.txt") on the PC for ASCII 
text download with a terminal program and just leave it open.
On the M100 I've programmed F7 to 'Key 7, "COM:88N1E"', so when I want 
to save the file I'm working on I press F3 to save, F7 in response to 
'Save "' and Return. It's a good idea to embed a version no. in the 
program and update it every time.
This concatenates all the saved files in one file; if you actually 
need to go back then you'd have to stop the transfer, edit the file on 
the PC and send it back to the M100. Of course you can open a new file 
on the PC every time if you don't mind typing on the PC every time.
To Load a .DO file from the PC, open TEXT, enter the File name, LOAD 
(F2) and enter 'COM:88N1E' in response to 'Load from:'; on the PC 
terminal program select Upload ASCII or whatever it's called and the 
file name (which does not have to be the same as on the M100). You may 
not see anything happening but the terminal program should indicate 
somehow when the transfer is finished. Type a CTL-Z on the PC and the 
file should appear on the M100; switch to BASIC and Load it, and Bob's 
your mother's brother.
This is mainly meant for folks who want to or have to just use the 
M100's built-in functions, and to show how to avoid overruns when 
Loading BASIC .DO programs as in a previous post here a few days ago.
Teeny, TS-DOS etc. certainly are very useful and in fact necessary if 
you're working with .BA tokenized files or Machine language code.
Other than my phone I'm not an Apple kind of guy, so I can't give any 
Mac-specific hints.
One other hint: to simplify switching from RUN to EDIT mode I've 
programmed 'F6,"Edit"+chr$(13)'

Not too verbose, I hope...
m

- Original Message -
*From:* Will Senn 
*To:* m100@lists.bitchin100.com
*Sent:* Saturday, October 29, 2022 10:16 AM
*Subject:* Re: [M100] Notoriously S.L.O.W BASIC posted - help
speeding it up appreciated

Hi Mike,

I'm curious about the COM stuff. In a later note you said:

It's actually sorta been fun programming on the 'real' M100; I
left a download running on the PC and every time I wanted to
backup an interim version just in case, I just pressed F3 and F7
(which I'd programmed with the COM stats).

and here, you say stuff about programming the function keys with
"COM:88N1E"...

It would be nice to be able to transfer / save from BASIC and/or
my terminal on the Mac without the overhead of dl/TEENY.CO. I know
enough to be dangerous and that the keys can easily be programmed
to effectively type stuff. I'm just not clear on is how this works
mechanically. Are you in BASIC, typing away, having just fixed
some bit and are ready to SAVE it remotely, so you press F3 and
voila, it just does it, or do you press F3 and then do something
to get it transferring, or what?

I have the cables hooked up and usually, I:
1. SAVE from BASIC to .DO or .BA
2. Start up DL on the Mac side, if it isn't already running in my
~/m100 directory
3. Press F8 to get menu
4. Select TEENY.CO
5. Type S HEXIT .DO
6. Watch it complete without error (so long as HEXIT.DO doesn't
already exist, I think)

What I'm imagining happen is:
1. SAVE from BASIC to .DO or .BA
2. Press F3
3. Magically a file is sent and received on the Mac (where does
it's name come from?)
4. Celebration
or
1. F2 from BASIC
2. Start sending a file (how?) from the Mac
3. Celebration

Just curious!

Will


On 10/28/22 12:30 PM, MikeS wrote:


Yeah, that's a setup I used for a while, sort of a poor man's
tablet/clamshell 'convertible. ;-) No problem extending the cable
to around 2 feet.
Never did use the disk drives very much although I did install a
second  one; even today while playing with Will's dump
program it's so simple to plug in the cable to the PC, select
download or upload on the PC and either BASIC F3 (SAVE) 

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

[Mike Stein]

My head hurts ;-)

Oddly enough, explicitly typing variables (e.g. A%) actually slows things
down a bit.

And yes, the intermediate values can be >32767 as long as the result is a
legal integer.

m

On Sat, Oct 29, 2022 at 10:20 PM Eric LK  wrote:

> I wrote:
> >FWIW, I also tried "caching" the result of "PEEK(P+1)" but again,
> >it didn't change the result (in all 3 implementations, 1000
> >iterations took 14 seconds, so those modifications aren't really
> >interesting, except for the brain picking exercise ;o)).
>
> Well, I managed to (almost) half this time :o) : 8 seconds for 1000
> iterations!
>
> I'd like to say I found a very innovative solution, but it's so simple
> I wonder how we didn't think of it before... Just let the BASIC do the
> work for you :o)
>
> 10 DEFINTP-Q:DEFSTRH
> 20 H=CHR$(201)
> 30 P=VARPTR(H)+1:Q=VARPTR(P)
> 1000 POKE Q,PEEK(P):POKE Q+1,PEEK(P+1)
> 1010 PRINTP
>
> "John R. Hogerhuis"  wrote:
> > As to type sigils on variables... Don't know how much it changes ram use
> > or execution time. Some! Maybe look at the tokenized output difference
> > for the space difference.
>
> Thanks, I may give it a try. BTW, is there a good documentation of the
> tokenized format (and of the variables encoding) for the M100? I
> learned a lot about the ZX-Spectrum BASIC by reading the user guide
> which gives a lot of implementation details about this, but I don't
> remember the M100 user manual going so deep.
>
> > If it goes over 32767 on any permutation of peek'd values it will fail.
> > Probably worth generating every permutation and confirming it
> > works.
>
> I suspect the integer conversion is only made when the value is stored
> in the integer variable.
> For example, this totally works:
> A%=1E15/1E14:?A%
>
> The only thing to be careful with is using functions that can only
> work with integer arguments like \ or AND:
> ?1E15\1E14 => OV Error
> ?!E15AND1E14 => OV Error
>
> Eric
>