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

[B 9]

On Sat, Nov 12, 2022 at 12:37 AM John R. Hogerhuis  wrote:

>
> Cover will be a picture of me with lockdown beard and a Model 100 strapped
> on the back of my 286cc motorcycle. Where is he going? Nowhere exceedingly
> fast, but he's wringing it out for everything it's worth!
>
>
I love that description of where you're going as it applies pretty well to
the whole Model T community, I think. I look forward to reading chapter
12777!

--b9

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

[John R. Hogerhuis]

Well if there is that much interest I will give it a try. I know some stuff
but like I said it will be more of a research project but you all will be
leaner upon, there is the list archive for detailed discussions I know we
all have had, and probably other groups are around with serious Dartmouth /
Microsoft BASIC byte and cycle count fighters.But the focus will be the
model 100 maybe with cross reference for 8201 and 200. It will limit the
audience from small to smaller but you cannot be everything to everybody.

Should be fun!

I think there will be one chapter named 12777

-- John

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

[Joshua O'Keefe]

> Cover will be a picture of me with lockdown beard and a Model 100 strapped on 
> the back of my 286cc motorcycle. Where is he going? Nowhere exceedingly fast

I'll admit my primary interest in this notional book -- a high interest, I 
should add -- is in its content, the bike and beard will certainly add to buyer 
satisfaction in my case.

Somewhat more seriously, this is something I do care deeply about at a larger 
level.  There's knowledge and systems understanding, some only recently 
uncovered, at risk of disappearing into time unless we leave some marks on the 
cave walls, and I encourage you and anyone else with a story to share, a design 
insight to show off, or the benefit of experience, to consider publication.  
More than a few such folks are gathered here.

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

[Daryl Tester]

On 12/11/22 18:55, Brian White wrote:


I just can't get over some of that stuff from Bing about "we like quality 
sites..."


Plus the usual support mantra of "you did something wrong, we're not telling 
you what it
is", him doing absolutely nothing to his website, then presto, it suddenly 
works again.

And yes, Google are just as bad. I wish that DDG would just stop using these 
tainted
sources and run their own.

John H. wrote:


Another problem is probably lack of links to bitchin100.



I need more friends...


That whole link farming thing is too easy to abuse. Determining quality content
programmatically is hard ...

Cheers,
  --dt

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

[John R. Hogerhuis]

On Sat, Nov 12, 2022 at 12:27 AM B 9  wrote:

> On Fri, Nov 11, 2022 at 4:28 PM John R. Hogerhuis 
> wrote:
>
>>
>> On Fri, Nov 11, 2022 at 4:00 PM B 9  wrote:
>>
>>> I wonder when the last book for Model T tinkerers was published? So much
>>> new knowledge has been found since then.
>>> The best books I've seen are
>>>
>>
>> Inside The Model 100 (Oppedahl)
>> Hidden Powers of the TRS-80 Model 100 (Morgan)
>>
>
> Oppedahl's "Inside the M100"
>  (1985) definitely
> looks like a good book to read. I got a glimpse of it recently when I was
> searching for a better description of the attribute flag in the RAM
> Directory. (Side note: I notice that Carl Oppedahl now apparently runs a
> patent/trademark/copyright law firm that still sells his book
> , first
> published in 1985!
>

That is awesome. I have two printed copies. Maybe he sent them to me? I
share orphan works... I'd rather they not be orphaned and buy them.


> Unfortunately, they don't ship to my location.)
>
>
Bummer... guess you'll have to live with samizdat


> I haven't read Morgan's "Hidden Powers
> " (1984),
> yet, but I recognize that cover. And I remember now trying to read it. I
> think I got bogged down at the very start where he says, “First, type in
> these five pages of code so we'll have a disassembler”. I wandered off to
> look for a disassembler for my Tandy 200 and never came back.
>
>
> While Tips, Peeks, and Pokes
>>> 
>>> (Anderson, 1985) can't be said to be coherent, it is a carefully curated
>>> collection of short, non-obvious tips, expressed succinctly.
>>>
>>> I've never read it, I will have to check it out.
>>
>
> I found it useful, but I'm starting from a very different place than you.
> Also, I should warn you, it's not very pretty to look at. I don't know how
> you feel about line printer text, but it appears Anderson may have actually
> written, formatted, and printed his book on a Model 100. You can read it
> here:
>
>
> https://archive.org/details/ProgrammingTipsPeeksAndPokesForTheTandyPortableComputers/
>
>
Thanks

>
>
>> Yeah I've been thinking about writing something. It would mostly be a
>> research project. And there's a lot I don't know, and a lot that only a few
>> ever knew.
>>
>> How about
>>
>> "TRS-80 Model 100 Pet Tricks: Rediscovering The Lost Dark Art of
>> Performant BASIC and ML Programming"
>>
>
> Sign me up for the pre-order. I'd read anything titled that!
> (Although, I admit I had a brief moment of cognitive dissonance trying to
> figure out what the Commodore PET computer had to do with the Model T.)
>
>

Hmm yeah. Meant "Stupid Pet Tricks"

Cover will be a picture of me with lockdown beard and a Model 100 strapped
on the back of my 286cc motorcycle. Where is he going? Nowhere exceedingly
fast, but he's wringing it out for everything it's worth!

-- John.

>

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

[John R. Hogerhuis]

Another problem is probably lack of links to bitchin100.

I need more friends...

-- John.

>

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

[Brian White]

I just can't get over some of that stuff from Bing about "we like quality
sites..."

who the what the ever loving F , where do you even begin with that

bkw

On Sat, Nov 12, 2022, 3:20 AM Brian White  wrote:

> wow, that article and the others linked from there are quite enlightening.
>
> I hate to help create a monoculture and single supplier and overlord, but
> it looks like Bing and all of it's resellers should just not be used.
>
> That really sucks because I really hate how much power g already has.
>
> You'd think Bing or any search engine should want to accept reports from
> any random user not just site owners, and it shouldn't matter if a site
> owner is willing to satisfy them. It is valuable to some site owners to be
> listed, so for some there may be that power dynamic where the engine may
> dictate to sites and sites will perform.
>
> But what about the users? The engine purports to be providing a service of
> search results to me a searching user. So in the apparently polyanna
> fantasy world I should be able to say to Bing "hey, bug report, here is
> some stuff on the net that you're failing to show" and they should consider
> that a problem just based on that logic, regardless whether the site owner
> cares to have any special relationship with Bing.
>
> It's almost like Bing doesn't show you what exists, it just shows you the
> sites that pay to be seen. Not literally in money but in cooperation in
> whatever kind of user manipulation game they are playing.
>
> I know google exerts the same sort of editorial control themselves though,
> so, it's not like they're really any better in principle.
>
> --
> bkw
>
> On Sat, Nov 12, 2022, 1:16 AM John R. Hogerhuis  wrote:
>
>>
>>
>> On Fri, Nov 11, 2022 at 7:21 PM Brian K. White 
>> wrote:
>>
>>> On 11/11/22 18:59, B 9 wrote:
>>> > On a tangent: I need to work on my searching skills. It occurred to me
>>> a
>>> > while ago that the Tandy 200 schematic looked like the RTS/CTS lines
>>> > were fully wired, but when I searched for things like "model 100
>>> serial
>>> > port rts cts", I never saw that page... Oh! Wait. The problem may have
>>> > been that I was googling with DuckDuckGo. I'm able to get
>>> bitchin100.com
>>> >  as the first result when I search for "model
>>> 100
>>> > uart", but only on Google.
>>>
>>>
>>> I have noticed this for probably 2 or more years now. I've been meaning
>>> to say something but never did. It's like bitchin100 is blacklisted on
>>> DDG, (and thus, probably on Bing too). Not only do none of the wiki
>>> pages show up, even if you search for literally "bitchin100.com", you
>>> can scroll for pages and pages of results forever and never get a single
>>> link to any bitchin100.com url, only references to it in other pages,
>>> mostly archived mail list posts on Narkive.
>>>
>>>
>> I don't know. I only ever search on Google. The progression for me was
>> Gopher, then Altavista, Yahoo, and now Google. Each better than the last,
>> haven't felt any compelling need to switch again. Privacy? That ship has
>> sailed, went into orbit, crashed into the an asteroid, merged with
>> alien spores and is sentient.
>>
>> And DDG/Bing already don't like me, so...
>>
>> Maybe Dreamhost IPs are the issue?
>>
>> As to spammers, some spam was loaded onto the wiki at some point, but it
>> wasn't there very long and I cleaned it up. I think it probably predates
>> DDG and Bing, and Google has never cared. But that spam attack is why I
>> make accounts upon request from members.
>>
>> URL rewriting... I could do that. But I don't see how it would help.  I
>> cannot think of a URL scheme that you could easily infer article titles.
>>
>> Most of Bitchin100 is the wiki. To link, I type bitchin100.com/wiki into
>> my url bar, then search in the mediawiki search, find the result, and then
>> copy and paste the URL.
>>
>> "tandy.wiki/REX"
>>
>> Most of the articles on bitchin100 have longer titles.
>>
>> B100 links are like
>>
>> bitchin100.com/wiki/index.php?title=Model_100_Serial_Interface
>>
>> rewriting I guess could skip the "wiki/index.php?title=" boilerplate.
>>
>> But you'd still need memorize the exact article title... 9/10 I'd end up
>> having to search anyway... so I don't see the difference.
>>
>>
>> Here's an interesting article on Bing/DDG
>>
>>
>> https://www.jessesquires.com/blog/2022/03/25/my-website-disappeared-from-bing-and-duckduckgo/
>>
>> Sounds like Bing is the way to get your site into DDG.
>>
>> -- John.
>>
>

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

[B 9]

On Fri, Nov 11, 2022 at 4:28 PM John R. Hogerhuis  wrote:

>
> On Fri, Nov 11, 2022 at 4:00 PM B 9  wrote:
>
>> I wonder when the last book for Model T tinkerers was published? So much
>> new knowledge has been found since then.
>> The best books I've seen are
>>
>
> Inside The Model 100 (Oppedahl)
> Hidden Powers of the TRS-80 Model 100 (Morgan)
>

Oppedahl's "Inside the M100"
 (1985) definitely
looks like a good book to read. I got a glimpse of it recently when I was
searching for a better description of the attribute flag in the RAM
Directory. (Side note: I notice that Carl Oppedahl now apparently runs a
patent/trademark/copyright law firm that still sells his book
, first published
in 1985! Unfortunately, they don't ship to my location.)

I haven't read Morgan's "Hidden Powers
" (1984), yet,
but I recognize that cover. And I remember now trying to read it. I think I
got bogged down at the very start where he says, “First, type in these five
pages of code so we'll have a disassembler”. I wandered off to look for a
disassembler for my Tandy 200 and never came back.


While Tips, Peeks, and Pokes
>> 
>> (Anderson, 1985) can't be said to be coherent, it is a carefully curated
>> collection of short, non-obvious tips, expressed succinctly.
>>
>> I've never read it, I will have to check it out.
>

I found it useful, but I'm starting from a very different place than you.
Also, I should warn you, it's not very pretty to look at. I don't know how
you feel about line printer text, but it appears Anderson may have actually
written, formatted, and printed his book on a Model 100. You can read it
here:


https://archive.org/details/ProgrammingTipsPeeksAndPokesForTheTandyPortableComputers/



> Yeah I've been thinking about writing something. It would mostly be a
> research project. And there's a lot I don't know, and a lot that only a few
> ever knew.
>
> How about
>
> "TRS-80 Model 100 Pet Tricks: Rediscovering The Lost Dark Art of
> Performant BASIC and ML Programming"
>

Sign me up for the pre-order. I'd read anything titled that!
(Although, I admit I had a brief moment of cognitive dissonance trying to
figure out what the Commodore PET computer had to do with the Model T.)

—b9

>

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

[Brian White]

wow, that article and the others linked from there are quite enlightening.

I hate to help create a monoculture and single supplier and overlord, but
it looks like Bing and all of it's resellers should just not be used.

That really sucks because I really hate how much power g already has.

You'd think Bing or any search engine should want to accept reports from
any random user not just site owners, and it shouldn't matter if a site
owner is willing to satisfy them. It is valuable to some site owners to be
listed, so for some there may be that power dynamic where the engine may
dictate to sites and sites will perform.

But what about the users? The engine purports to be providing a service of
search results to me a searching user. So in the apparently polyanna
fantasy world I should be able to say to Bing "hey, bug report, here is
some stuff on the net that you're failing to show" and they should consider
that a problem just based on that logic, regardless whether the site owner
cares to have any special relationship with Bing.

It's almost like Bing doesn't show you what exists, it just shows you the
sites that pay to be seen. Not literally in money but in cooperation in
whatever kind of user manipulation game they are playing.

I know google exerts the same sort of editorial control themselves though,
so, it's not like they're really any better in principle.

-- 
bkw

On Sat, Nov 12, 2022, 1:16 AM John R. Hogerhuis  wrote:

>
>
> On Fri, Nov 11, 2022 at 7:21 PM Brian K. White 
> wrote:
>
>> On 11/11/22 18:59, B 9 wrote:
>> > On a tangent: I need to work on my searching skills. It occurred to me
>> a
>> > while ago that the Tandy 200 schematic looked like the RTS/CTS lines
>> > were fully wired, but when I searched for things like "model 100 serial
>> > port rts cts", I never saw that page... Oh! Wait. The problem may have
>> > been that I was googling with DuckDuckGo. I'm able to get
>> bitchin100.com
>> >  as the first result when I search for "model
>> 100
>> > uart", but only on Google.
>>
>>
>> I have noticed this for probably 2 or more years now. I've been meaning
>> to say something but never did. It's like bitchin100 is blacklisted on
>> DDG, (and thus, probably on Bing too). Not only do none of the wiki
>> pages show up, even if you search for literally "bitchin100.com", you
>> can scroll for pages and pages of results forever and never get a single
>> link to any bitchin100.com url, only references to it in other pages,
>> mostly archived mail list posts on Narkive.
>>
>>
> I don't know. I only ever search on Google. The progression for me was
> Gopher, then Altavista, Yahoo, and now Google. Each better than the last,
> haven't felt any compelling need to switch again. Privacy? That ship has
> sailed, went into orbit, crashed into the an asteroid, merged with
> alien spores and is sentient.
>
> And DDG/Bing already don't like me, so...
>
> Maybe Dreamhost IPs are the issue?
>
> As to spammers, some spam was loaded onto the wiki at some point, but it
> wasn't there very long and I cleaned it up. I think it probably predates
> DDG and Bing, and Google has never cared. But that spam attack is why I
> make accounts upon request from members.
>
> URL rewriting... I could do that. But I don't see how it would help.  I
> cannot think of a URL scheme that you could easily infer article titles.
>
> Most of Bitchin100 is the wiki. To link, I type bitchin100.com/wiki into
> my url bar, then search in the mediawiki search, find the result, and then
> copy and paste the URL.
>
> "tandy.wiki/REX"
>
> Most of the articles on bitchin100 have longer titles.
>
> B100 links are like
>
> bitchin100.com/wiki/index.php?title=Model_100_Serial_Interface
>
> rewriting I guess could skip the "wiki/index.php?title=" boilerplate.
>
> But you'd still need memorize the exact article title... 9/10 I'd end up
> having to search anyway... so I don't see the difference.
>
>
> Here's an interesting article on Bing/DDG
>
>
> https://www.jessesquires.com/blog/2022/03/25/my-website-disappeared-from-bing-and-duckduckgo/
>
> Sounds like Bing is the way to get your site into DDG.
>
> -- John.
>

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

[John R. Hogerhuis]

On Fri, Nov 11, 2022 at 7:21 PM Brian K. White  wrote:

> On 11/11/22 18:59, B 9 wrote:
> > On a tangent: I need to work on my searching skills. It occurred to me a
> > while ago that the Tandy 200 schematic looked like the RTS/CTS lines
> > were fully wired, but when I searched for things like "model 100 serial
> > port rts cts", I never saw that page... Oh! Wait. The problem may have
> > been that I was googling with DuckDuckGo. I'm able to get bitchin100.com
> >  as the first result when I search for "model
> 100
> > uart", but only on Google.
>
>
> I have noticed this for probably 2 or more years now. I've been meaning
> to say something but never did. It's like bitchin100 is blacklisted on
> DDG, (and thus, probably on Bing too). Not only do none of the wiki
> pages show up, even if you search for literally "bitchin100.com", you
> can scroll for pages and pages of results forever and never get a single
> link to any bitchin100.com url, only references to it in other pages,
> mostly archived mail list posts on Narkive.
>
>
I don't know. I only ever search on Google. The progression for me was
Gopher, then Altavista, Yahoo, and now Google. Each better than the last,
haven't felt any compelling need to switch again. Privacy? That ship has
sailed, went into orbit, crashed into the an asteroid, merged with
alien spores and is sentient.

And DDG/Bing already don't like me, so...

Maybe Dreamhost IPs are the issue?

As to spammers, some spam was loaded onto the wiki at some point, but it
wasn't there very long and I cleaned it up. I think it probably predates
DDG and Bing, and Google has never cared. But that spam attack is why I
make accounts upon request from members.

URL rewriting... I could do that. But I don't see how it would help.  I
cannot think of a URL scheme that you could easily infer article titles.

Most of Bitchin100 is the wiki. To link, I type bitchin100.com/wiki into my
url bar, then search in the mediawiki search, find the result, and then
copy and paste the URL.

"tandy.wiki/REX"

Most of the articles on bitchin100 have longer titles.

B100 links are like

bitchin100.com/wiki/index.php?title=Model_100_Serial_Interface

rewriting I guess could skip the "wiki/index.php?title=" boilerplate.

But you'd still need memorize the exact article title... 9/10 I'd end up
having to search anyway... so I don't see the difference.


Here's an interesting article on Bing/DDG

https://www.jessesquires.com/blog/2022/03/25/my-website-disappeared-from-bing-and-duckduckgo/

Sounds like Bing is the way to get your site into DDG.

-- John.

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

[Brian K. White]

On 11/11/22 18:59, B 9 wrote:
On a tangent: I need to work on my searching skills. It occurred to me a 
while ago that the Tandy 200 schematic looked like the RTS/CTS lines 
were fully wired, but when I searched for things like "model 100 serial 
port rts cts", I never saw that page... Oh! Wait. The problem may have 
been that I was googling with DuckDuckGo. I'm able to get bitchin100.com 
 as the first result when I search for "model 100 
uart", but only on Google.



I have noticed this for probably 2 or more years now. I've been meaning 
to say something but never did. It's like bitchin100 is blacklisted on 
DDG, (and thus, probably on Bing too). Not only do none of the wiki 
pages show up, even if you search for literally "bitchin100.com", you 
can scroll for pages and pages of results forever and never get a single 
link to any bitchin100.com url, only references to it in other pages, 
mostly archived mail list posts on Narkive.


Maybe there is something about the site or the domain that causes it to 
be delisted in Bing or DDG, like maybe the crawler finds the site  web 
server config to be insecure so it could be co-opted by hackers or 
spammers, or some other scanner doesn't like something about the domain 
like the email server config (maybe lack of modern SPF/DKIM/DMARC stuff) 
causing the search engine to "protect" everyone from reaching it.


I switched my default search to DDG a few years ago and have noticed a 
few different problems like that, but I run into this particular one for 
bitchin100 All. The. Time. because every time I want to answer a 
question on facebook or something, and point someone to say a REX docs 
page, bitchin100 doesn't have pretty url rewriting enabled, so all the 
urls are long and arcane and hard to remember manually, unlike 
"tandy.wiki/REX", I have to search to get to the page and then cut & 
paste the real url.


But DDG never shows anything from bitchin100.com at all, so I have to 
explicitly go to google or bitchin100 directly, then search, then cut & 
paste.


To fix it, probably John would have to find some support form somewhere 
on DDG or Bing to ask "why is my site/domain censored?" and probably 
there will be some non-trivial hoops he would have to jump through to 
satisfy Bing or DDG that the site is wholesome despite the name, and 
secure according to whatever they say defines secure. (safe from hackers 
being able to use it to feed people viruses through their browsers, or 
the email server safe from being usable by hackers to send spam or 
phishing attacks). Or it could be as simple as the name, though that 
seems unlikely. Then again, with so much stuff being done by black box 
mystery AI's, even the name might be causing it, but not for any obvious 
reason we can see but for some AI mistaken association like maybe how a 
"model 100" is a gun, and so "bitchin100" might be about guns. Who 
knows. These days, nothing is deterministic like it used to be. MAybe 
the fix is just to get a human to review and unblock after taking a glance.


--
bkw

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

[John R. Hogerhuis]

On Fri, Nov 11, 2022 at 4:00 PM B 9  wrote:

> On Fri, Nov 11, 2022 at 11:12 AM John R. Hogerhuis 
> wrote:
>
>>
>>
>> I think you probably are the discoverer of that, even if the Model T was
> over twenty years old when you started. I don't believe hobbyists had easy
> access to datasheets in the 1980s.
>

Right. But I got that reference from Ken so he saw it when he wrote
VirtualT. But maybe I was the first one to play with it on real hardware
since Gates and Co chose not to implement hardware flow control and higher
baud rates (who would ever need more than 19200 bps?)


>
> I wonder when the last book for Model T tinkerers was published? So much
> new knowledge has been found since then. Wikis are great for looking up
> information, if you already know what you don't know, but they're not so
> great for giving a person new to a subject an idea of what is available and
> what is even important. It's hard to read through an entire wiki, or even
> to flip through one. By design, wikis are supposed to be quick to write,
> not well thought out or coherent. That's one reason I've more often turned
> to the Model T books and documentation instead of mailing list archives or
> wiki pages.
>

The best books I've seen are

Inside The Model 100 (Oppedahl)
Hidden Powers of the TRS-80 Model 100 (Morgan)


>
>
> While Tips, Peeks, and Pokes
> 
> (Anderson, 1985) can't be said to be coherent, it is a carefully curated
> collection of short, non-obvious tips, expressed succinctly.
> I feel like a second volume of such tips could be created with everything
> that has be learned since 1985. For example, the ability to point a string
> to a memory address is a pretty neat trick, as is the ability to exceed the
> serial port speed limit. Also, some of the tricks could be updated.
>
>
I've never read it, I will have to check it out.

Yeah I've been thinking about writing something. It would mostly be a
research project. And there's a lot I don't know, and a lot that only a few
ever knew.

How about

"TRS-80 Model 100 Pet Tricks: Rediscovering The Lost Dark Art of Performant
BASIC and ML Programming"


> Just in my own research, I've found that I could expand on a few of
> Anderson's articles. For example, the PEEK to distinguish
> 
> between a Model 100, Tandy 200, and Tandy 102 could also distinguish the
> Kyocera Kyotronic-85, the Olivetti M10 (Italy), the M10 (US), and the NEC
> family of portables. And Anderson's discussion of the RAM Directory
> 
> describes the addresses of files in memory as only useful to assembly
> language programmers, but there are actually good use cases for accessing
> RAM files directly in BASIC using PEEK (fast, random access of binary data
> without needing a duplicate in RAM).
>
>
If you want to understand the filesystem stuff you need to read the NEC
programmer's guides over at Web8201. Fantastic stuff.


>
> Is the source code to TBACK.EXE available to learn from?
>>>
>>
>> No. HTERM source is available if you want to look at serial stuff.
>>
>
> I was actually wondering about how TBACK.EXE handles XON/XOFF. Does the
> program it sends to the Model T use hardware handshaking? Does it work with
> a Tandy 200 or only a Model 100? How does it configure the serial port on
> the PC side?
>

I will look. I don't think it depends on that. Since the magic words are
RUN"COM:98N1E", the E means enable, so XON/XOFF is in play. But I it's not
enough to slow things down on Linux, so, IIRC, when injecting it simply
adds a sufficient delay to avoid overrunning the receive buffer + tokenizer
logic. For backup/restore it uses hardware flow control to achieve maximum
possible speed.

TBACK is model 100 only.

-- John.

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

[B 9]

On Fri, Nov 11, 2022 at 11:12 AM John R. Hogerhuis  wrote:

>
> So, it's not only been done, but you can poke the baud rate higher than
> 19,200?
>
> Yes, as far as I know I was the first one to do anything with higher baud
> rates. But I didn't come to the Model 100 scene until about 2004, I think.
>
> https://bitchin100.com/wiki/index.php?title=Model_100_Serial_Interface
>

That's an excellent page and contains all I need to use the higher speeds.
It's a shame that BASIC is too slow for anything higher than 19,200.

I wonder if it would help if the BASIC ROMs were patched to use hardware
handshaking. Has anyone done that?

[On a tangent: I need to work on my searching skills. It occurred to me a
while ago that the Tandy 200 schematic looked like the RTS/CTS lines were
fully wired, but when I searched for things like "model 100 serial port rts
cts", I never saw that page... Oh! Wait. The problem may have been that I
was googling with DuckDuckGo. I'm able to get bitchin100.com as the first
result when I search for "model 100 uart", but only on Google.]


And it is stable?
>>
>
> At least on the Model 100 and T102 it is fine all the way up to 76800bps
>

Awesome. I think I should be able to connect at 76,800 on my PC since I've
got GNU/Linux and I can set custom baud rates by dividing the serial card's
base rate. I think my 16950 card's baud_base is 921600, so if I set the
divisor to 12, I should get exactly 76800. (setserial /dev/ttyS0 spd_cust
divisor 12.)



> The possibility for the higher baud rates was clear from the UART data
> sheet. https://bitchin100.com/wiki/images/2/22/6402.pdf
>

I think you probably are the discoverer of that, even if the Model T was
over twenty years old when you started. I don't believe hobbyists had easy
access to datasheets in the 1980s.

I wonder when the last book for Model T tinkerers was published? So much
new knowledge has been found since then. Wikis are great for looking up
information, if you already know what you don't know, but they're not so
great for giving a person new to a subject an idea of what is available and
what is even important. It's hard to read through an entire wiki, or even
to flip through one. By design, wikis are supposed to be quick to write,
not well thought out or coherent. That's one reason I've more often turned
to the Model T books and documentation instead of mailing list archives or
wiki pages.

While Tips, Peeks, and Pokes

(Anderson, 1985) can't be said to be coherent, it is a carefully curated
collection of short, non-obvious tips, expressed succinctly.
I feel like a second volume of such tips could be created with everything
that has be learned since 1985. For example, the ability to point a string
to a memory address is a pretty neat trick, as is the ability to exceed the
serial port speed limit. Also, some of the tricks could be updated.

Just in my own research, I've found that I could expand on a few of
Anderson's articles. For example, the PEEK to distinguish

between a Model 100, Tandy 200, and Tandy 102 could also distinguish the
Kyocera Kyotronic-85, the Olivetti M10 (Italy), the M10 (US), and the NEC
family of portables. And Anderson's discussion of the RAM Directory

describes the addresses of files in memory as only useful to assembly
language programmers, but there are actually good use cases for accessing
RAM files directly in BASIC using PEEK (fast, random access of binary data
without needing a duplicate in RAM).


Is the source code to TBACK.EXE available to learn from?
>>
>
> No. HTERM source is available if you want to look at serial stuff.
>

I was actually wondering about how TBACK.EXE handles XON/XOFF. Does the
program it sends to the Model T use hardware handshaking? Does it work with
a Tandy 200 or only a Model 100? How does it configure the serial port on
the PC side?


There's a story docent told me... Frank Lloyd Wright designed walls at a
> slight angle because he didn't like people hanging pictures on (his) walls.
> The owners still figured out how to hang pictures.
>
> The idea with the one-liners being in PDF was to force you into the
> enlightening joy of typing them in. They're short so it should be feasible
> for most.
>

 Ah! Well, I guess your gambit worked then. My OCR program was having
fits over recognizing that dot matrix font, so I ended up just typing in
the text by hand to create the PDF. And now I understand why I've been
filled with enlightened joy of late.

—b9

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

[John R. Hogerhuis]

On Thu, Nov 10, 2022 at 11:15 PM B 9  wrote:

> Oh! The more I learn, the more I find there is to learn. I like that no
> matter what mountain I climb, there's always Guru Hogerhuis already at the
> top, smiling and pointing the way forward.
>
> So, it's not only been done, but you can poke the baud rate higher than
> 19,200?
>

Yes, as far as I know I was the first one to do anything with higher baud
rates. But I didn't come to the Model 100 scene until about 2004, I think.

https://bitchin100.com/wiki/index.php?title=Model_100_Serial_Interface


> And it is stable?
>

At least on the Model 100 and T102 it is fine all the way up to 7600bps.


> I didn't see that mentioned in Anderson'sProgramming Tips, Peeks and Pokes
> for the Tandy Portable Computers. Did I miss it? Or is this another thing
> that needs to go in the hypothetical Volume II?
>
>
I've never looked at it. The possibility for the higher baud rates was
clear from the UART data sheet.
https://bitchin100.com/wiki/images/2/22/6402.pdf


> Is the source code to TBACK.EXE available to learn from?
>
>
No. HTERM source is available if you want to look at serial stuff.

https://bitchin100.com/wiki/index.php?title=HTERM
https://bitchin100.com/pub-git/hterm.git/


> —b9
>
> P.S. The program listing for your one-liner was a PNG image, which isn't
> easy to copy text out of. I've converted it to a PDF for you, in case you
> or someone would like to post it on the wiki.
>
>
Oh that was on purpose...

There's a story docent told me... Frank Lloyd Wright designed walls at a
slight angle because he didn't like people hanging pictures on (his) walls.
The owners still figured out how to hang pictures.

The idea with the one-liners being in PDF was to force you into the
enlightening joy of typing them in. They're short so it should be feasible
for most.

We really should revive the one-liner contest. Produces a lot of learning
and creativity.

-- John.

>

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

[Stephen Adolph]

76800 is possible with custom software.
38400 is possible while still using the internal rom routines.
Iirc.

On Friday, November 11, 2022, B 9  wrote:

> Oh! The more I learn, the more I find there is to learn. I like that no
> matter what mountain I climb, there's always Guru Hogerhuis already at the
> top, smiling and pointing the way forward.
>
> So, it's not only been done, but you can poke the baud rate higher than
> 19,200? And it is stable? I didn't see that mentioned in
> Anderson'sProgramming Tips, Peeks and Pokes for the Tandy Portable
> Computers. Did I miss it? Or is this another thing that needs to go in the
> hypothetical Volume II?
>
> Is the source code to TBACK.EXE available to learn from?
>
> —b9
>
> P.S. The program listing for your one-liner was a PNG image, which isn't
> easy to copy text out of. I've converted it to a PDF for you, in case you
> or someone would like to post it on the wiki.
>
> On Thu, Nov 10, 2022 at 11:55 AM John R. Hogerhuis 
> wrote:
>
>> " If Model T strings can hold NULLs, then maybe one could create a string
>> and change its pointers so it reads from any arbitrary location in memory."
>>
>> Indeed... we used this fact to dump the entire RAM in binary format out
>> the serial port, from a  BASIC program in less than 30 seconds. Faster if
>> you poke a higher baud rate.
>>
>> This one dumps to NADSBox (has code to invokes the command to get NADSBox
>> to start capturing)
>>
>> https://bitchin100.com/wiki/index.php?title=Model_100_RAM_Dump_One-Liners
>>
>> Or there's TBACK.EXE, no special hardware needed... can both inject the
>> dump code and receive the file on the host in one step (tested on
>> Linux/WINE as well as Windows). And it can restore the image onto a laptop.
>> The only thing you need to do on the laptop is remember RUN"COM:98N1E
>>
>> -- John.
>>
>

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

[B 9]

Oh! The more I learn, the more I find there is to learn. I like that no
matter what mountain I climb, there's always Guru Hogerhuis already at the
top, smiling and pointing the way forward.

So, it's not only been done, but you can poke the baud rate higher than
19,200? And it is stable? I didn't see that mentioned in
Anderson'sProgramming Tips, Peeks and Pokes for the Tandy Portable
Computers. Did I miss it? Or is this another thing that needs to go in the
hypothetical Volume II?

Is the source code to TBACK.EXE available to learn from?

—b9

P.S. The program listing for your one-liner was a PNG image, which isn't
easy to copy text out of. I've converted it to a PDF for you, in case you
or someone would like to post it on the wiki.

On Thu, Nov 10, 2022 at 11:55 AM John R. Hogerhuis  wrote:

> " If Model T strings can hold NULLs, then maybe one could create a string
> and change its pointers so it reads from any arbitrary location in memory."
>
> Indeed... we used this fact to dump the entire RAM in binary format out
> the serial port, from a  BASIC program in less than 30 seconds. Faster if
> you poke a higher baud rate.
>
> This one dumps to NADSBox (has code to invokes the command to get NADSBox
> to start capturing)
>
> https://bitchin100.com/wiki/index.php?title=Model_100_RAM_Dump_One-Liners
>
> Or there's TBACK.EXE, no special hardware needed... can both inject the
> dump code and receive the file on the host in one step (tested on
> Linux/WINE as well as Windows). And it can restore the image onto a laptop.
> The only thing you need to do on the laptop is remember RUN"COM:98N1E
>
> -- John.
>


DMPRMN.PDF
Description: Adobe PDF document

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

[John R. Hogerhuis]

" If Model T strings can hold NULLs, then maybe one could create a string
and change its pointers so it reads from any arbitrary location in memory."

Indeed... we used this fact to dump the entire RAM in binary format out the
serial port, from a  BASIC program in less than 30 seconds. Faster if you
poke a higher baud rate.

This one dumps to NADSBox (has code to invokes the command to get NADSBox
to start capturing)

https://bitchin100.com/wiki/index.php?title=Model_100_RAM_Dump_One-Liners

Or there's TBACK.EXE, no special hardware needed... can both inject the
dump code and receive the file on the host in one step (tested on
Linux/WINE as well as Windows). And it can restore the image onto a laptop.
The only thing you need to do on the laptop is remember RUN"COM:98N1E

-- John.

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

[B 9]

On Wed, Oct 26, 2022 at 7:24 PM runrin  wrote:

> 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, [...]


I also noticed that PEEK() seemed surprisingly slow, no faster than using
an array. But I'm surprised to hear that MID$ was faster. I hadn't even
tried that because I just presumed it'd be slow.

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
>

Ah! That's why my VARPTR attempts were failing. I had presumed the first
two bytes would be the address. Using a length instead of a NULL terminator
is interesting. If Model T strings can hold NULLs, then maybe one could
create a string and change its pointers so it reads from any arbitrary
location in memory. Would using MID$ on that be faster than grabbing the
bytes via PEEK? I wouldn't think so, but I've been wrong before.

[...] i know those extra spaces make my code slower, i'm just formatting it
> that way here so its actually legible.
>

That is another thing that I wonder about. I can see that it saves bytes,
but how much performance does removing spaces actually give? It seems like
it'd only matter in tight loops, so the whole program wouldn't need to be
crunched. My guess is that the speed difference is miniscule, especially
compared to the readability benefits.

On a historical sidenote, in 1979, Microsoft released MBASIC 5.0 for the
Z80. I believe it was the first BASIC Microsoft released that allowed
variable names to be longer than two letters. However, in order to do that,
they had to require spaces so that long variables wouldn't get parsed into
reserved words ("FOR  TRANSUXB AS ICRULZ!"). Did the mandatory spaces cause
a large performance hit? The manual mentions that a version of BASIC is
still available with the old two letter variable names, but it was
advertised as being for computers with tiny amounts of RAM, not for speed.

—b9

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

[B 9]

Sidenote: For wonks who want to check my numbers, the file was 16197 bytes
long. For effective bps, I used 10 bits per byte because I don't recall
exactly how all the stop bits and parity add up, but I know it is more than
8 bits. I did the timing by typing ?TIME$: LOAD... and then, once that was
started, typed ?TIME$ and hit ENTER so that it'd show up as soon as the
loading was finished. On the PC end, I used my other hand to hit ENTER a
fraction of a second after I hit ENTER to start the LOAD on the Tandy 200.

On Tue, Nov 1, 2022 at 10:58 AM B 9  wrote:

> Good question. I know that 19,200 makes a substantial qualitative
> difference compared to 9600 when using TELCOM to connect to a UNIX shell.
> For loading BASIC programs, I don't know that it would make a difference as
> I usually just let it run and forget about it while it tokenizes.I only
> mentioned loading from BASIC because that was the lowest maximum download
> speed in your table (600 baud).
>
> Timing test for a 16K BASIC (in ASCII) sent to a Tandy 200:
>
>
>
> Command Bits per
> second
> Time Effective
> bps
> LOAD "COM:98N1ENN" 19200 58s 2793
> LOAD "COM:88N1ENN" 9600 59s 2745
> LOAD "COM:68N1ENN" 2400 78s 2076
> LOAD "COM:48N1ENN" 600 270s 600
>
> So, as Mike predicted, there is no difference between 9600 and 19,200.
> What was interesting to me was that, although those rates are able to go
> faster than 2400 bps on average, when the connection speed is 2400, the
> effective rate is lower. That shows that the tokenization speed on my Tandy
> 200 varies. It is rarely faster than 9600 but it is sometimes slower than
> 2400, which is probably why Mike suggested 600 as a safe maximum speed.
> And, sure enough, when I try 600 bps, the BASIC tokenizer is able to keep
> up perfectly without ever having to send XOFF to pause the transmission.
>
> This also shows that any PC serial port that is able to send a BASIC file
> at 9600 has to have XOFF/XON working well. While it is not conclusive, I
> would guess that the same connection would work fine at 19,200.
>
> —b9
>
>
>
> On Tue, Nov 1, 2022 at 8:57 AM MikeS  wrote:
>
>> Maybe I should have said that XON/XOFF is hit-and-miss depending on the
>> hardware instead of 'unreliable' ;-) .
>>
>> It's not always easy to know whether a particular setup will work or
>> not; I've seen USB cables recommended that I couldn't get to work and,
>> conversely, had no problems with others that supposedly did not.
>>
>> FWIW, I normally also run at 19200bd but thought it would be safer to
>> recommend 9600 bd in this discussion since it usually works no matter what
>> and makes very little difference in actual throughput.
>>
>> Have you ever compared actual BASIC download speed at 9600 vs. 19200bd?
>>
>> m
>>
>>
>> - Original Message -
>> *From:* B 9 
>> *To:* m...@bitchin100.com
>> *Sent:* Tuesday, November 01, 2022 3:33 AM
>> *Subject:* Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding
>> it up appreciated
>>
>>
>> On Mon, Oct 31, 2022 at 12:11 AM MikeS  wrote:
>>
>>> Reliable maximum download speeds on the M100 without handshaking are
>>> around:
>>> BASIC: 600 bd to allow time to tokenize and store.
>>> TERM: 2400 because of the slow LCD scrolling.
>>> TEXT: 9600 since it does not display while loading.
>>>
>>
>> That sounds right when the other end does not have hardware-level
>> XON/XOFF, but it should be much faster with a better UART on the PC, like
>> an OX16C950
>> <https://pdf1.alldatasheet.com/datasheet-pdf/download/161698/OXFORD/OX16C950.html>
>> or a chip from FTDI or MOXA. As soon as the M100 sends XOFF, the UART chip
>> in the serial port automatically stops the flow of data. No lag, no lost
>> characters. I connect using 19,200 bps in BASIC (*LOAD "COM:98N1ENN"* )
>> and it works perfectly when I use certain USB serial adapters (and not
>> others).
>>
>> Has anyone with a Model 100 tried using a serial card or USB adapter that
>> supports "automated in-band flow-control"? Do you see the same high-speed
>> connection as I do on my Tandy 200?
>>
>> —b9
>>
>>

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

[B 9]

Good question. I know that 19,200 makes a substantial qualitative
difference compared to 9600 when using TELCOM to connect to a UNIX shell.
For loading BASIC programs, I don't know that it would make a difference as
I usually just let it run and forget about it while it tokenizes.I only
mentioned loading from BASIC because that was the lowest maximum download
speed in your table (600 baud).

Timing test for a 16K BASIC (in ASCII) sent to a Tandy 200:



Command Bits per
second
Time Effective
bps
LOAD "COM:98N1ENN" 19200 58s 2793
LOAD "COM:88N1ENN" 9600 59s 2745
LOAD "COM:68N1ENN" 2400 78s 2076
LOAD "COM:48N1ENN" 600 270s 600

So, as Mike predicted, there is no difference between 9600 and 19,200. What
was interesting to me was that, although those rates are able to go faster
than 2400 bps on average, when the connection speed is 2400, the effective
rate is lower. That shows that the tokenization speed on my Tandy 200
varies. It is rarely faster than 9600 but it is sometimes slower than 2400,
which is probably why Mike suggested 600 as a safe maximum speed. And, sure
enough, when I try 600 bps, the BASIC tokenizer is able to keep up
perfectly without ever having to send XOFF to pause the transmission.

This also shows that any PC serial port that is able to send a BASIC file
at 9600 has to have XOFF/XON working well. While it is not conclusive, I
would guess that the same connection would work fine at 19,200.

—b9



On Tue, Nov 1, 2022 at 8:57 AM MikeS  wrote:

> Maybe I should have said that XON/XOFF is hit-and-miss depending on the
> hardware instead of 'unreliable' ;-) .
>
> It's not always easy to know whether a particular setup will work or not;
> I've seen USB cables recommended that I couldn't get to work and,
> conversely, had no problems with others that supposedly did not.
>
> FWIW, I normally also run at 19200bd but thought it would be safer to
> recommend 9600 bd in this discussion since it usually works no matter what
> and makes very little difference in actual throughput.
>
> Have you ever compared actual BASIC download speed at 9600 vs. 19200bd?
>
> m
>
>
> - Original Message -
> *From:* B 9 
> *To:* m...@bitchin100.com
> *Sent:* Tuesday, November 01, 2022 3:33 AM
> *Subject:* Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it
> up appreciated
>
>
> On Mon, Oct 31, 2022 at 12:11 AM MikeS  wrote:
>
>> Reliable maximum download speeds on the M100 without handshaking are
>> around:
>> BASIC: 600 bd to allow time to tokenize and store.
>> TERM: 2400 because of the slow LCD scrolling.
>> TEXT: 9600 since it does not display while loading.
>>
>
> That sounds right when the other end does not have hardware-level
> XON/XOFF, but it should be much faster with a better UART on the PC, like
> an OX16C950
> <https://pdf1.alldatasheet.com/datasheet-pdf/download/161698/OXFORD/OX16C950.html>
> or a chip from FTDI or MOXA. As soon as the M100 sends XOFF, the UART chip
> in the serial port automatically stops the flow of data. No lag, no lost
> characters. I connect using 19,200 bps in BASIC (*LOAD "COM:98N1ENN"* )
> and it works perfectly when I use certain USB serial adapters (and not
> others).
>
> Has anyone with a Model 100 tried using a serial card or USB adapter that
> supports "automated in-band flow-control"? Do you see the same high-speed
> connection as I do on my Tandy 200?
>
> —b9
>
>

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

[MikeS]

Maybe I should have said that XON/XOFF is hit-and-miss depending on the 
hardware instead of 'unreliable' ;-) .

It's not always easy to know whether a particular setup will work or not; I've 
seen USB cables recommended that I couldn't get to work and, conversely, had no 
problems with others that supposedly did not.

FWIW, I normally also run at 19200bd but thought it would be safer to recommend 
9600 bd in this discussion since it usually works no matter what and makes very 
little difference in actual throughput.

Have you ever compared actual BASIC download speed at 9600 vs. 19200bd?

m

  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Tuesday, November 01, 2022 3:33 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated




  On Mon, Oct 31, 2022 at 12:11 AM MikeS  wrote:
Reliable maximum download speeds on the M100 without handshaking are around:
BASIC: 600 bd to allow time to tokenize and store.
TERM: 2400 because of the slow LCD scrolling.
TEXT: 9600 since it does not display while loading.


  That sounds right when the other end does not have hardware-level XON/XOFF, 
but it should be much faster with a better UART on the PC, like an OX16C950 or 
a chip from FTDI or MOXA. As soon as the M100 sends XOFF, the UART chip in the 
serial port automatically stops the flow of data. No lag, no lost characters. I 
connect using 19,200 bps in BASIC (LOAD "COM:98N1ENN" ) and it works perfectly 
when I use certain USB serial adapters (and not others). 



  Has anyone with a Model 100 tried using a serial card or USB adapter that 
supports "automated in-band flow-control"? Do you see the same high-speed 
connection as I do on my Tandy 200?



  —b9

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

[B 9]

On Mon, Oct 31, 2022 at 12:11 AM MikeS  wrote:

> Reliable maximum download speeds on the M100 without handshaking are
> around:
> BASIC: 600 bd to allow time to tokenize and store.
> TERM: 2400 because of the slow LCD scrolling.
> TEXT: 9600 since it does not display while loading.
>

That sounds right when the other end does not have hardware-level XON/XOFF,
but it should be much faster with a better UART on the PC, like an OX16C950

or a chip from FTDI or MOXA. As soon as the M100 sends XOFF, the UART chip
in the serial port automatically stops the flow of data. No lag, no lost
characters. I connect using 19,200 bps in BASIC (*LOAD "COM:98N1ENN"* ) and
it works perfectly when I use certain USB serial adapters (and not others).

Has anyone with a Model 100 tried using a serial card or USB adapter that
supports "automated in-band flow-control"? Do you see the same high-speed
connection as I do on my Tandy 200?

—b9

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

[MikeS]

Sounds like what I do when I want separate versions and can't be bothered 
extracting the desired file from the main log. ;-)

On the PC using old venerable ProComm:

Save new version:
ESC:   terminates previous D/L
PgDn,7: selects new ASCII D/L
Enter version no.
Ready to receive next version, for save, restore, compare, whatever.
5 keystrokes

Restore previous version:
ESC: Get out of D/L mode.
PgUp,7:   select ASCII upload
Enter version number
'Enter' when the M100 is ready
5 keystrokes.

What can I say; if you're going to program on the M100 why not do it the way 
you could have done it in pre-Git and even pre-Windows days... No need to 
fumble with those newfangled mice either ;-)

One annoyance: It appears that BASIC does not send CR/LF so you have to enable 
that on the terminal. However, that now double-spaces 'normal' COM files so you 
either have to change the terminal settings or do your own CR/LFs.

(Unless someone has a better idea ?)

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






  On Sun, Oct 30, 2022 at 8:58 PM B 9  wrote:

On Sun, Oct 30, 2022 at 7:28 PM John R. Hogerhuis  wrote:

  You could always script it out to do a git commit after every ctrl-z


Sometimes, I don't know if you're joking or not... I mean, yes, that's 
brilliant and should work. But, oh boy. Once again, you've got my brain turning 
on completely needless, yet very cool ideas. ☺




  Wasn't joking... this time. 

  If you're going to keep a host-side running backup of a program you're 
working on in this way, might as well let the host side help you manage the 
versions. git will list out the versions and you can compare versions at will 
to see exactly what changed.


  Could be a useful workflow.

  The other way to do that is filesystems and backup agents that give you a 
time machine feature.


  -- John. 

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

[Joshua O'Keefe]

> On Oct 31, 2022, at 1:31 PM, John R. Hogerhuis  wrote:
> The other way to do that is filesystems and backup agents that give you a 
> time machine feature.

My TPDD emulator of choice is pointed at a corner of my home directory.  My 
home directory is in a ZFS dataset.  The ZFS dataset is snapshot every 15 
minutes, rolled up into a week's worth of dailies, three month's worth of 
weeklies, a year's worth of monthlies, and a few year's worth of yearlies.

I have a habit of trying to keep DOS-ON when I can so most on-device BASIC dev 
can be sent off-device with an occasional SAVE"0:THING if I happen to be at my 
desk.

The notion of hooking SAVE to commits, though, is pretty attractive!  The 
granularity would be nice.

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

[John R. Hogerhuis]

On Sun, Oct 30, 2022 at 8:58 PM B 9  wrote:

> On Sun, Oct 30, 2022 at 7:28 PM John R. Hogerhuis 
> wrote:
>
>> You could always script it out to do a git commit after every ctrl-z
>>
>
> Sometimes, I don't know if you're joking or not... I mean, yes, that's
> brilliant and should work. But, oh boy. Once again, you've got my brain
> turning on completely needless, yet very cool ideas. ☺
>
>
Wasn't joking... this time.

If you're going to keep a host-side running backup of a program you're
working on in this way, might as well let the host side help you manage the
versions. git will list out the versions and you can compare versions at
will to see exactly what changed.

Could be a useful workflow.

The other way to do that is filesystems and backup agents that give you a
time machine feature.

-- John.

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

[MikeS]

In my rather verbose reply I probably didn't make it clear that there should be 
no problem uploading/saving to the server at 19,200bd; the issues are with 
downloading to the M100. I just keep it at 9600 because it isn't really much 
slower and I don't have to change baud rate on the server when I download a 
file.

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


  That sounds like a nice workflow. This ought to be in a FAQ of tips and hints 
for people new to the M100.



  I might just try it out. I'm pretty rigorous about using SAVE "COM:98N1ENN", 
but I have to tell my Unix box to receive the file each time (cp /dev/ttyUSB0 
foo.do). And every copy I save overwrites the previous one, unlike the natural 
history you'll have in your log file if you find you need to go back a few 
revisions. 



  One question though: why do you send at 9600 bps? I thought all Model T's 
could do 19,200bps.



  —b9



  On Sat, Oct 29, 2022 at 10:26 AM 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, i

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

[MikeS]

You've summed it up very well indeed.

Putting it another way:

If the 'server' handles it correctly (and apparently some versions of Linux do 
not) then the actual XON/XOFF protocol is completely reliable if you are 
connected directly or through compatible modems. The receiving client sends an 
XOFF (CTL-S, CHR$(19)) to signal that it needs time to process the received 
data and the sending server immediately stops and waits for an XON (CTL-Q, 
CHR$(17)) to start sending again.

Note that XON/XOFF is not just used for communication; many programs also use 
it locally, e.g. to pause scrolling while listing a large file.

Hardware handshaking works the same way, but instead of sending handshaking 
characters it uses additional wires in the connecting cable to send and receive 
equivalent electrical signals. Unfortunately the M100 does not natively 
implement hardware handshaking, although there are programs that do, such as 
John H's Hterm

Problems can arise when the M100 with its puny 64 byte buffer is connected 
through a USB<>RS232 adapter or an Ethernet or WiFi 'modem'; these devices send 
data in packets of multiple bytes at a time and will finish sending the packet 
before they acknowledges the XOFF and pause. Unless the packet size can be 
adjusted to a small enough size (e.g. 1) then the M100's receive buffer will 
probably overflow and drop characters by then.

As you say, some adapters/modems do work well if properly configured, while 
others do not and you have to run at a baud rate low enough that the receiving 
program can process the characters as they come. 

Reliable maximum download speeds on the M100 without handshaking are around:
BASIC: 600 bd to allow time to tokenize and store.
TERM: 2400 because of the slow LCD scrolling.
TEXT: 9600 since it does not display while loading.

YMMV of course.

Myself, I play with a number of vintage systems and prefer to use 'real' RS232 
ports whenever practical.

m

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


  On Sun, Oct 30, 2022 at 7:16 PM Mike Stein  wrote:

That's odd; can't your terminal program just wait forever for the next 
dump? If it times out, can't you override that?



  Sure, it's actually even easier to just let it all accumulate in one file. It 
just hadn't occurred to me to do it that way. 




It probably won't matter with a small file like this but I've found that at 
19200 even TEXT has trouble keeping up when downloading. The M100 doesn't have 
hardware handshaking and only has XON/XOFF, which is not always reliable.


  I used to believe the same things about XON/XOFF: I derisively referred to it 
as an unreliable protocol that should have died with disco. I never understood 
how people could have used serial connections before hardware handshaking. (Nor 
did I understand disco.)



  It turns out, I was wrong. On my Tandy 200, what I've discovered is that 
XON/XOFF is 100% reliable at 19200, if you've got a good serial card on your 
PC. The key thing is that latency has to be very low. That means, either Ⓐ 
disabling all buffers, including the FIFO buffer on the serial port, or Ⓑ, 
which is preferable if your UART chips support doing so, enabling 
hardware-level XON/XOFF. (The Linux kernel automatically sets this up for you 
if your hardware can handle it; I presume other systems are similar.)  



  Ⓐ Back in the days of yore, when the Model T was current, serial cards had a 
1-byte buffer, which meant every single byte caused a system interrupt. (!) 
That meant, they actually had less latency relative to speed of filling the 
output buffer than our fast, modern computers. I haven't had one to test, but I 
believe old PCs with an 8250 UART would not overwhelm a Model T, even at 
19,200. Nowadays, every serial card comes with a minimum of 16-bytes for the 
FIFO and it is not always easy (or possible) to disable it. 



  Ⓑ Despite XON/XOFF being called "software flow control", many chips actually 
offer hardware implementations so they can stop the flow of communication the 
instant the Model 100 holds up its hand and says, “Whoa!”  Without 
hardware-level support, you have to wait for the XOFF (^S) character to go 
through all the buffers on the PC and get processed before data stops getting 
sent. By the time that happens, the buffer of data going to the Model 100, 
which has been filling up at 19,200 bps, is now so large that it will overwhelm 
the M100, causing data loss. 



  Some cheap USB Serial adapters do not offer on-chip XON/XOFF and they are 
unreliable at high-speeds.  What serial card / USB adapter are you using? I 
know the 16950 UART has on-chip xon/xoff, as do most (all?) FTDI chips. 
ProLific's PL2303 *sometimes* has support, but they rarely label it on the box 
so it's hard to know before you buy an adapter.



  —b

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

[MikeS]

I added a couple of options:
H:  Hexadecimal addresses
D:  Decimal addresses
L:   List on LCD
C:  List to COM port (for scrolling, saving, printing etc.)

Timings (seconds for 50 lines):
HL: 39 (As the previous version)
DL: 36
HC: 19
DC: 17

One last minute addition: the variable W in line 160 is the width, i.e. the 
number of bytes per line -1. Useful if you're listing on a terminal (e.g. 15 
will list 16 bytes)

No error checking; defaults are H and L as before.

Sorry; got a little carried away ;-) Try it; you'll like it! ;-)

m
-
1 DEFINTJ-Z:DIMH$(15):FORI=0TO15:REM V4
10 H$(I)=CHR$(48+I-(7*(I>9))):NEXT:CLS
15 GOSUB200:INPUT"From";A:INPUT"to";B
20 T$=TIME$: FORI=ATOBSTEPW+1
25 IFDTHENPRINT#1,USING"#";I;:PRINT#1,": ";:GOTO50
30 K=I/4096:PRINT#1,H$(K);
35 L=(I-K*4096):PRINT#1,H$(L\256);
40 PRINT#1,H$((LMOD256)\16)H$(LMOD16)" ";
50 L$="":FORJ=0TOW:X=PEEK(I+J)
55 PRINT#1,H$(X\16);H$(XMOD16)" ";
60 Y$=".":IFX>31ANDX<127THENY$=CHR$(X)
65 L$=L$+Y$:NEXT:PRINT#1,L$:NEXT
70 E$=TIME$:PRINT#1," "T$+" to "+E$
100 T=VAL(MID$(TIME$,4,2))*60+VAL(RIGHT$(TIME$,2))
110 R=VAL(MID$(T$,4,2))*60+VAL(RIGHT$(T$,2))
120 PRINT#1," "T-R" seconds":END
200 D$="H":INPUT"(H)EX or (D)ec address";D$
210 D=INSTR("dD",D$)>0:B$="88n1e":C$="L"
220 INPUT"(L)CD or (C)om output ";C$
230 IF INSTR("cC",C$)=0THENOPEN"LCD:"FOR OUTPUT AS 1:GOTO260
240 INPUT"Stat (88N1E)";B$
250 F$="COM:"+B$:OPENF$FOR OUTPUT AS 1
260 W=15:RETURN

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

[B 9]

 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

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

[B 9]

On Sun, Oct 30, 2022 at 7:28 PM John R. Hogerhuis  wrote:

> You could always script it out to do a git commit after every ctrl-z
>

Sometimes, I don't know if you're joking or not... I mean, yes, that's
brilliant and should work. But, oh boy. Once again, you've got my brain
turning on completely needless, yet very cool ideas. ☺

—b9

P.S. For those who don't know ^Z is the Model 100's End-of-File character
which I believe gets sent at the end of an ASCII file. Though, now that I
think about it, I never see that character in my files on my UNIX box...
Oh, wait, I bound EOF to ^Z using stty -f /dev/ttyUSB0 EOF ^Z, so maybe
UNIX's tty is consuming it.

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

[MikeS]

This is the period-accurate pre-Git equivalent ;-)

We're doing it the hard way, without VirtualT, REX etc.; more fun that way ...

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


  You could always script it out to do a git commit after every ctrl-z


  -- John. 

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

[John R. Hogerhuis]

You could always script it out to do a git commit after every ctrl-z

-- John.

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

[Mike Stein]

That's odd; can't your terminal program just wait forever for the next
dump? If it times out, can't you override that?

It probably won't matter with a small file like this but I've found that at
19200 even TEXT has trouble keeping up when downloading. The M100 doesn't
have hardware handshaking and only has XON/XOFF, which is not always
reliable.

When uploading/saving from BASIC there doesn't seem to be much difference
between 9600 and 19200, since it has to detokenize as it goes. Try it and
see how it goes at 19200; TELCOM and text would probably be a little faster.

I've added an option to send the dump output to the com port; that seems to
work fine at 19200.

BTW, I don't think we'll do much better than 34 seconds/50 lines; as I
mentioned, LCD performance is pretty bad, especially scrolling.

For comparison, outputting to the com port halves the time to 17 seconds,
and of course you can scroll, save and print that on your PC as well.

m

On Sun, Oct 30, 2022 at 9:54 PM B 9  wrote:

> That sounds like a nice workflow. This ought to be in a FAQ of tips and
> hints for people new to the M100.
>
> I might just try it out. I'm pretty rigorous about using *SAVE
> "COM:98N1ENN"*, but I have to tell my Unix box to receive the file each
> time (cp /dev/ttyUSB0 foo.do). And every copy I save overwrites the
> previous one, unlike the natural history you'll have in your log file if
> you find you need to go back a few revisions.
>
> One question though: why do you send at 9600 bps? I thought all Model T's
> could do 19,200bps.
>
> —b9
>
> On Sat, Oct 29, 2022 at 10:26 AM 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 l

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

[B 9]

That sounds like a nice workflow. This ought to be in a FAQ of tips and
hints for people new to the M100.

I might just try it out. I'm pretty rigorous about using *SAVE
"COM:98N1ENN"*, but I have to tell my Unix box to receive the file each
time (cp /dev/ttyUSB0 foo.do). And every copy I save overwrites the
previous one, unlike the natural history you'll have in your log file if
you find you need to go back a few revisions.

One question though: why do you send at 9600 bps? I thought all Model T's
could do 19,200bps.

—b9

On Sat, Oct 29, 2022 at 10:26 AM 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 .

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
>

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

[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 

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 <mailto:hacke...@gmail.com>
*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,

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 <mailto:will.s...@gmail.com>
   *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 <mailto:hacke...@gmail.com>
    *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

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

[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

[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 endi

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

[MikeS]

Well, I'm still not convinced that there's an advantage in this case, although 
it does sound more suited to machine language. The only padding I had to  do 
(the way you describe) was to bring the HEX range user input values to a fixed 
4 digits, but I think as in B 9's example it probably makes more sense to input 
in decimal.

I think I'll leave the Forth version for another day ;-)

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






  On Thu, Oct 27, 2022 at 6:04 PM Mike Stein  wrote:

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.


  The general idea is to do-while convert until you get to zero on the value 
being converted to string. So in reverse, you wouldn't need multiple entry 
points, it works for either 1-4 nibbles length.

  That leaves a question of zero-padding, but RIGHT$("000"+D$, 2 or 4) always 
works.


  FWIW, Forth's "pictured numeric output" is organized around this principle of 
LSB to MSB. It goes beyond radix conversions to support advanced number 
formatting like BASIC supports through PRINT USING. It probably helps that 
Forthers are used to doing everything backwards ;-)


  
https://www.jimbrooks.org/archive/programming/forth/forthPicturedNumericOutput.php



  Also of note for M100 specifically, MFORTH has a built-in DUMP word that can 
be compared for speed, though I actually don't know if that word is implemented 
in ML or threaded code. There's also an 8085 assembler for it, so it should 
make a nice environment for directly experimenting with machine code.


  -- John.




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] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[John R. Hogerhuis]

On Thu, Oct 27, 2022 at 6:04 PM Mike Stein  wrote:

> 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.
>

The general idea is to do-while convert until you get to zero on the value
being converted to string. So in reverse, you wouldn't need multiple
entry points, it works for either 1-4 nibbles length.

That leaves a question of zero-padding, but RIGHT$("000"+D$, 2 or 4) always
works.

FWIW, Forth's "pictured numeric output" is organized around this principle
of LSB to MSB. It goes beyond radix conversions to support advanced number
formatting like BASIC supports through PRINT USING. It probably helps that
Forthers are used to doing everything backwards ;-)

https://www.jimbrooks.org/archive/programming/forth/forthPicturedNumericOutput.php

Also of note for M100 specifically, MFORTH has a built-in DUMP word that
can be compared for speed, though I actually don't know if that word is
implemented in ML or threaded code. There's also an 8085 assembler for it,
so it should make a nice environment for directly experimenting with
machine code.

-- John.


>
> 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] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[Will Senn]

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 <mailto:hacke...@gmail.com>
*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*


—b9

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

[MikeS]

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 thing some day.



  —b9

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

[MikeS]

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

--

  —b9

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] 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] 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 

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] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[B 9]

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

[B 9]

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
> > 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]

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

[runrin]

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

[John R. Hogerhuis]

On Wed, Oct 26, 2022 at 4:33 PM Eric LK  wrote:

> "John R. Hogerhuis"  wrote:
> > ?MID$(H$,A/16+1,1);MID$(H$,AMOD16+1,1);" ";
>
> It would be slightly faster with:
> ?MID$(H$,A\16+1,1);MID$(H$,(AAND15)+1,1);" ";
>
> The biggest difference is the integer division, which to be honest
> surprised me, since the variables are already integers.
> Perhaps they are cast into regular (float) values before the division
> is attempted?
>
>
>
Probably gets promoted because of the constant 16. Default for constants is
double precision float... so I guess make it 16% explicit? I don't know if
that syntax is correct. BASIC seems to be happy with it.

-- John.

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

[John R. Hogerhuis]

On Wed, Oct 26, 2022 at 4:33 PM Eric LK  wrote:

> "John R. Hogerhuis"  wrote:
> > ?MID$(H$,A/16+1,1);MID$(H$,AMOD16+1,1);" ";
>
> It would be slightly faster with:
> ?MID$(H$,A\16+1,1);MID$(H$,(AAND15)+1,1);" ";
>
> 1 iterations takes 5:43 vs 7:23 with your version (I tested on
> VirtualT, so it may not be 100% accurate but that should be a good
> estimate).
>
> The biggest difference is the integer division, which to be honest
> surprised me, since the variables are already integers.
>

Excellent! I actually wasn't aware of the integer division operator.

-- John.

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

[Eric LK]

"John R. Hogerhuis"  wrote:
> ?MID$(H$,A/16+1,1);MID$(H$,AMOD16+1,1);" ";

It would be slightly faster with:
?MID$(H$,A\16+1,1);MID$(H$,(AAND15)+1,1);" ";

1 iterations takes 5:43 vs 7:23 with your version (I tested on
VirtualT, so it may not be 100% accurate but that should be a good
estimate).

The biggest difference is the integer division, which to be honest
surprised me, since the variables are already integers.
Perhaps they are cast into regular (float) values before the division
is attempted?

While we're into BASIC optimizations, another good trick is to declare
your variables (just assign anything into them at the beginning of
your program) in reverse order of use (i.e. the ones you access the
most often first).

When I wrote my version of Conways Game of Life, it saved me more than
10 seconds per generation.

Eric

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

[John R. Hogerhuis]

Thanks Joshua! It does seem minimal.

Hopefully it works too :-) My first attempt had a 0 versus 1 string index
based issue. So 255 printed as EE instead of FF.

But I caught that one in testing on CloudT.

For those who want to try the code above, you can go to

https://bitchin100.com/CloudT

Copy the code above to your clipboard

Scroll down the emulator page to the text box, paste it in.

Click "Add Plain Text"

You'll be prompted for a name, like SAMPLE.DO

You will see the file SAMPLE.DO appear in the cassette file queue at the
bottom

Click on the model t window, go into BASIC, and type

CLOAD

The file will load.

If you make edits, to write it back out as a text file you can download and
cut/paste type

CSAVE"SAMPLE.DO",A

Then you will see in the cassette file queue an icon you can use to
download it into your computer's file system.

I had to remember that to share the code above. CloudT is unique in Model T
emulators in that its host file system access is based on hooking the BASIC
ROM's native file I/O (cassette).

-- John.

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

[Joshua O'Keefe]

> On Oct 26, 2022, at 12:27 PM, John R. Hogerhuis  wrote:
> 
> 110 PRINT@B,MID$(H$,A/16+1,1);MID$(H$,AMOD16+1,1);" ";

John, I just want to compliment you on an elegant idiom here.

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

[John R. Hogerhuis]

Here's roughly how I would dump hex bytes in BASIC. I know you're doing
other stuff but I will just pick off one part of the job that could be
optimized.

Line 110 is the key... no IFs or anything special to get padding. And I
wouldn't make it a subroutine per se. Just stick that

?MID$(H$,A/16+1,1);MID$(H$,AMOD16+1,1);" ";

wherever you need it, changing any variable names to protect the innocent

10 DEFINTA-F
100 H$="0123456789ABCDEF"
101 B=0
105 A=RND(1)*256
110 PRINT@B,MID$(H$,A/16+1,1);MID$(H$,AMOD16+1,1);" ";
111 B=(B+3)MOD24
120 GOTO 105

-- John.

>

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

[MikeS]

Hi Steve,

I was going to mention your amazing code from way back when we played with 
one-line programs (and maybe even steal some code ;-) ) but didn't feel like 
hunting through the archives; didn't think of the personal libraries, duh!

m
  - Original Message - 
  From: Stephen Adolph 
  To: m...@bitchin100.com 
  Sent: Wednesday, October 26, 2022 10:41 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  Will,
  Here is a bit of compact code I wrote to convert bases given a number.  There 
may be some simplifications and or speed ups here.



  The one line version
  1 V$=" 
"+CHR$(13)+CHR$(8)+"0123456789ABCDEF":E=INSTR(V$,INKEY$):ONEGOTO1:F=(F-(E=2))MOD3:G=9*F+2-F^2:C=-C*(E=2)-(C*G+E-4)*(E>3ANDE:BASE :CLEAR":PRINT"<+> inc <-> decr":V$=" "+ 
CHR$(13)+"-"+ CHR$(8)+ "+0123456789ABCDEF"
  2 C=0
  3 C=C+E-4:C=C*(C<2^16)*(C>-1)
  4 F=(F-(E=2)) MOD 4:G = INT((F^3)*(4/3) - (F^2)*6 + F*(32/3) + 2):PRINT:PRINT 
MID$("BINOCTDECHEX",3*F+1,3);":";:IF F THEN Z= INT(C/256):D =Z:GOSUB 8:D 
=C-Z*256:GOSUB 8
  5 IF F\2 OR F=0  THEN D = C: GOSUB 10
  6 S$=INKEY$:E=INSTR(LEFT$(V$,5+G),S$):ON E+1 GOTO 
6,6,4,3,2,3:K=C*G+E-6:C=-K*(K<2^16):PRINT S$;:GOTO 6
  8 PRINT" ";
  9 PRINT CHR$(D AND D>31 OR 32 AND D<32);
  10 PRINT" ";:FOR I= 11*(F=0)-4 TO 0:J=G^I:X=INT(D*J):PRINT 
MID$(V$,X+6,1);:D=D-X/J:NEXT:RETURN


  Steve







  On Wed, Oct 26, 2022 at 10:22 AM Will Senn  wrote:

Hi All,

For those of you following my previous BASIC memory dump discussion, I have 
posted the code and some commentary on my blog at: 
http://decuser.blogspot.com/2022/10/notoriously-slow-basic.html

Take a look and if you have suggestions for improving it or find any 
errors, please let me know. I'll be working on its efficiency in the meantime 
and adding to the post as I figure stuff out.

Thanks,

Will

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

[Stephen Adolph]

Will,
Here is a bit of compact code I wrote to convert bases given a number.
There may be some simplifications and or speed ups here.

The one line version
1 V$="
"+CHR$(13)+CHR$(8)+"0123456789ABCDEF":E=INSTR(V$,INKEY$):ONEGOTO1:F=(F-(E=2))MOD3:G=9*F+2-F^2:C=-C*(E=2)-(C*G+E-4)*(E>3ANDE:BASE :CLEAR":PRINT"<+> inc <-> decr":V$=" "+
CHR$(13)+"-"+ CHR$(8)+ "+0123456789ABCDEF"
2 C=0
3 C=C+E-4:C=C*(C<2^16)*(C>-1)
4 F=(F-(E=2)) MOD 4:G = INT((F^3)*(4/3) - (F^2)*6 + F*(32/3) +
2):PRINT:PRINT MID$("BINOCTDECHEX",3*F+1,3);":";:IF F THEN Z= INT(C/256):D
=Z:GOSUB 8:D =C-Z*256:GOSUB 8
5 IF F\2 OR F=0  THEN D = C: GOSUB 10
6 S$=INKEY$:E=INSTR(LEFT$(V$,5+G),S$):ON E+1 GOTO
6,6,4,3,2,3:K=C*G+E-6:C=-K*(K<2^16):PRINT S$;:GOTO 6
8 PRINT" ";
9 PRINT CHR$(D AND D>31 OR 32 AND D<32);
10 PRINT" ";:FOR I= 11*(F=0)-4 TO 0:J=G^I:X=INT(D*J):PRINT
MID$(V$,X+6,1);:D=D-X/J:NEXT:RETURN

Steve



On Wed, Oct 26, 2022 at 10:22 AM Will Senn  wrote:

> Hi All,
>
> For those of you following my previous BASIC memory dump discussion, I
> have posted the code and some commentary on my blog at:
> http://decuser.blogspot.com/2022/10/notoriously-slow-basic.html
>
> Take a look and if you have suggestions for improving it or find any
> errors, please let me know. I'll be working on its efficiency in the
> meantime and adding to the post as I figure stuff out.
>
> Thanks,
>
> Will
>

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

[Will Senn]

Hi All,

For those of you following my previous BASIC memory dump discussion, I 
have posted the code and some commentary on my blog at: 
http://decuser.blogspot.com/2022/10/notoriously-slow-basic.html


Take a look and if you have suggestions for improving it or find any 
errors, please let me know. I'll be working on its efficiency in the 
meantime and adding to the post as I figure stuff out.


Thanks,

Will