Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Fri, Mar 3, 2023 at 1:44 AM John R. Hogerhuis  wrote:

>
> Modern structured programming language designers endeavor to make
> them context free. Which just means they can be described fully by a
> context free grammar, like BNF. Programming languages are all parseable,
> but where they deviate from being context free, ad hoc code handles the
> corner cases.
>

Thanks. Now reading up on the Chomsky Hierarchy.

—b9

Re: [M100] - Text Sweet 2.3 Release

[Brian White]

basic is parsable, obviously the interpreter has to do it, but the
difference is to parse basic you pretty much need a state machine, pretty
much the same way the actual interpreter works.

You can't really determine what any given digit or double-quote or almost
anything is, except by starting from the beginning and keeping track of
what you have encountered one byte at a time all along the way.

You enter and exit modes or states serially, at least within a line, and
the rules are the weird rules of basic not any generic rules, ie how a
string of text might be several different things packed together, only
recognized as separate things by recognizing that IFA is not a keyword but
IF is, and so A must be an argument, but not if this all doesn't appear in
the main context outside of quotes or comments or a data statement.

Or how a THEN or ELSE branch ends at the end of the line, which is no
different than the end of any other line, not with some explicit ENDIF or
braces.

bkw

On Fri, Mar 3, 2023, 3:47 AM B 9  wrote:

> On Wed, Mar 1, 2023 at 11:00 PM John R. Hogerhuis 
> wrote:
>
>> Well, for ANSI C 99 lex is probably the best way. C doesn't (didn't?)
>> have any regex engine. I don't know what's in modern C, it might have
>> libraries for regex.
>>
>
> I've used the PCRE library in C, which works but is not as nice as a
> language which is designed from the ground up to use regular expressions.
> While the modern languages that I know technically have regular
> expressions, most of them treat regexes as a weird string which can be used
> in a function call, no different than a library in C. Perl and Python are
> noteworthy here: Perl for being surprisingly good at integrating regular
> expressions into the design of the language and Python for failing quite
> badly when they should have known better. I don't know if there are any
> modern languages that put regular expressions at the heart in the way lex,
> awk, and sed do. I'd love to learn if anyone knows.
>
> If someone is using Python, Perl, C#, Java, Javascript, etc... my
>> minimalist tendency would be to forgo the dependency on a lexer library
>>
>
> If you are speaking of how the compiled executable can literally depend
> upon the lexer library to run, it turns out that is not necessary. But,
> yes, I do see your broader point of wanting to write directly in a language
> instead of using a meta-language.
>
>
> and just use the regex language feature to do the work. Since you can
>> create one being expression with a named line number token, followed by a
>> series of BASIC lexemes as one big list of "|"'s
>>
>
> If the language's regex features made doing so easy, I'd be all for it.
> Unfortunately, as far as I know, they don't. Consider "mini-scanners" where
> part of the input is syntactically different from the rest. For example,
> how do you handle REM or double quotes? It is totally possible to do it in
> a giant regex, but not by me. I mean, I could probably come up with
> something that seems to work, but I'm not sure I have enough skill (or
> patience) to do it right. I would end up kludging it with extra code that
> might work, but certainly would offend anyone's sense of minimalism.
>
> With lex, mini-scanners are trivial. For example, here is the entirety of
> the code needed to handle REM in my tokenizer:
>
> %x remark /* remark is an exclusive start condition */REM 
> putchar(142);   BEGIN(remark);
> <*>\n putchar('\0');  BEGIN(INITIAL);
>
> I simply defined an exclusive start condition named  and have the
> REM statement enter into it. Lex automatically copies verbatim any text
> that doesn't match any rules. The only rule that matches  is
> newline, which returns the scanner to the normal start condition. Double
> quotes are just as easy.
>
>
>
>> For a given line you need to lex the line number first. That can be its
>> own regex.
>> Then you need to lex BASIC tokens one after another. Pretty much that's
>> just one giant regex of alternative lexemes.
>>
> As you extract them you may enter modes for handling expressions, strings,
>> REM content depending on what you're doing (tokenizer, syntax checker,
>> pretty printer, renumber, etc.) . That's your own code and variables, lex
>> doesn't really help with that anyway since it's not a parser.
>>
>
> You are correct about lex not handling expressions. The syntax for REM and
> strings in BASIC is not recursive and doesn't need a parser. That makes lex
> perfect as a BASIC tokenizer, but not so great for any of the other
> examples you listed, at least not on its own. While my tokenizer can
> ~kinda~ pack the .BA file by removing comments and whitespace, the sort of
> optimizations Brian is talking about (merging lines) or that I'm
> considering (removing lines that only contain a remark) are beyond it.
>
>
> Now if you're into trying a proper parser/context free grammar then I can
>> see using lex+yacc or equivalents, even in a higher level language.
>>
>
> I'm 

Re: [M100] - Text Sweet 2.3 Release

[John R. Hogerhuis]

On Fri, Mar 3, 2023 at 12:47 AM B 9  wrote:

> On Wed, Mar 1, 2023 at 11:00 PM John R. Hogerhuis 
> wrote:
>
>>
>> You know a heckuva lot more than I do, John. I had just presumed any
> computer language was parsable.
>
>
Modern structured programming language designers endeavor to make
them context free. Which just means they can be described fully by a
context free grammar, like BNF. Programming languages are all parseable,
but where they deviate from being context free, ad hoc code handles the
corner cases.

-- John.

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Wed, Mar 1, 2023 at 11:00 PM John R. Hogerhuis  wrote:

> Well, for ANSI C 99 lex is probably the best way. C doesn't (didn't?) have
> any regex engine. I don't know what's in modern C, it might have libraries
> for regex.
>

I've used the PCRE library in C, which works but is not as nice as a
language which is designed from the ground up to use regular expressions.
While the modern languages that I know technically have regular
expressions, most of them treat regexes as a weird string which can be used
in a function call, no different than a library in C. Perl and Python are
noteworthy here: Perl for being surprisingly good at integrating regular
expressions into the design of the language and Python for failing quite
badly when they should have known better. I don't know if there are any
modern languages that put regular expressions at the heart in the way lex,
awk, and sed do. I'd love to learn if anyone knows.

If someone is using Python, Perl, C#, Java, Javascript, etc... my
> minimalist tendency would be to forgo the dependency on a lexer library
>

If you are speaking of how the compiled executable can literally depend
upon the lexer library to run, it turns out that is not necessary. But,
yes, I do see your broader point of wanting to write directly in a language
instead of using a meta-language.


and just use the regex language feature to do the work. Since you can
> create one being expression with a named line number token, followed by a
> series of BASIC lexemes as one big list of "|"'s
>

If the language's regex features made doing so easy, I'd be all for it.
Unfortunately, as far as I know, they don't. Consider "mini-scanners" where
part of the input is syntactically different from the rest. For example,
how do you handle REM or double quotes? It is totally possible to do it in
a giant regex, but not by me. I mean, I could probably come up with
something that seems to work, but I'm not sure I have enough skill (or
patience) to do it right. I would end up kludging it with extra code that
might work, but certainly would offend anyone's sense of minimalism.

With lex, mini-scanners are trivial. For example, here is the entirety of
the code needed to handle REM in my tokenizer:

%x remark   /* remark is an exclusive start condition
*/REM   putchar(142);   BEGIN(remark);
<*>\n   putchar('\0');  BEGIN(INITIAL);

I simply defined an exclusive start condition named  and have the
REM statement enter into it. Lex automatically copies verbatim any text
that doesn't match any rules. The only rule that matches  is
newline, which returns the scanner to the normal start condition. Double
quotes are just as easy.



> For a given line you need to lex the line number first. That can be its
> own regex.
> Then you need to lex BASIC tokens one after another. Pretty much that's
> just one giant regex of alternative lexemes.
>
As you extract them you may enter modes for handling expressions, strings,
> REM content depending on what you're doing (tokenizer, syntax checker,
> pretty printer, renumber, etc.) . That's your own code and variables, lex
> doesn't really help with that anyway since it's not a parser.
>

You are correct about lex not handling expressions. The syntax for REM and
strings in BASIC is not recursive and doesn't need a parser. That makes lex
perfect as a BASIC tokenizer, but not so great for any of the other
examples you listed, at least not on its own. While my tokenizer can
~kinda~ pack the .BA file by removing comments and whitespace, the sort of
optimizations Brian is talking about (merging lines) or that I'm
considering (removing lines that only contain a remark) are beyond it.


Now if you're into trying a proper parser/context free grammar then I can
> see using lex+yacc or equivalents, even in a higher level language.
>

I'm not at that level, yet. Maybe someday.



> That said I don't know how parseable BASIC is. It's not a structured
> language. It may be best suited to ad hoc methods.
>

You know a heckuva lot more than I do, John. I had just presumed any
computer language was parsable.

—b9

Re: [M100] - Text Sweet 2.3 Release

[Brian K. White]

On 3/2/23 07:31, Brian K. White wrote:

On 3/1/23 20:05, B 9 wrote:

, 


|egrep -io 
'(GO\s*TO|GOSUB|THEN|ELSE|RESTORE|RESUME|RETURN|RUN)(\s*,?\s*[0-9]+)+' |


As you can see, I had missed exactly the same subtlety as reseq.


And yet I see you are handling things I am not
I don't have GO TO with a space nor RESTORE nor RUN



nor return!

--
bkw

Re: [M100] - Text Sweet 2.3 Release

[Brian K. White]

On 3/1/23 20:05, B 9 wrote:

, 


|egrep -io 
'(GO\s*TO|GOSUB|THEN|ELSE|RESTORE|RESUME|RETURN|RUN)(\s*,?\s*[0-9]+)+' |


As you can see, I had missed exactly the same subtlety as reseq.


And yet I see you are handling things I am not
I don't have GO TO with a space nor RESTORE nor RUN

--
bkw

Re: [M100] - Text Sweet 2.3 Release

[John R. Hogerhuis]

Well, for ANSI C 99 lex is probably the best way. C doesn't (didn't?) have
any regex engine. I don't know what's in modern C, it might have libraries
for regex.

As you say lex is a  "friendly wrapper around regular expressions."

But all it really does is make a giant regex/state machine with hooks for
your code. If someone is using Python, Perl, C#, Java, Javascript, etc...
my minimalist tendency would be to forgo the dependency on a lexer library
and just use the regex language feature to do the work. Since you can
create one being expression with a named line number token, followed by a
series of BASIC lexemes as one big list of "|"'s

For a given line you need to lex the line number first. That can be its own
regex.
Then you need to lex BASIC tokens one after another. Pretty much that's
just one giant regex of alternative lexemes.

As you extract them you may enter modes for handling expressions, strings,
REM content depending on what you're doing (tokenizer, syntax checker,
pretty printer, renumber, etc.) . That's your own code and variables, lex
doesn't really help with that anyway since it's not a parser.

Now if you're into trying a proper parser/context free grammar then I can
see using lex+yacc or equivalents, even in a higher level language.

That said I don't know how parseable BASIC is. It's not a structured
language. It may be best suited to ad hoc methods.

-- John.


On Wed, Mar 1, 2023 at 5:50 PM B 9  wrote:

>
>
> On Wed, Mar 1, 2023 at 9:39 AM John R. Hogerhuis  wrote:
>
>> Parser systems are less work than they're worth. But lexer systems, not
>> so much.
>> Modern languages have advanced regular expression systems which are equal
>> in power to a lexer. Might as well just use a big regex to lex your tokens.
>>
>
> You probably know more about this than me, John, but I'm confused by the
> idea of using regexes *instead* of lex. I think of lex as a friendly
> wrapper around regular expressions. At its heart, lex is a list of regular
> expressions with associated actions for each one. They are implicitly or'ed
> and the longest possible match is taken. Most of my tokenizer is just lines
> like this:
>
> END   putchar(128);FORputchar(129);NEXT   
> putchar(130);DATA   putchar(131);INPUT  
> putchar(132);DIMputchar(133);READ   
> putchar(134);LETputchar(135);
>
> The most "complicated" part is the regexp for matching line numbers which
> has to print four bytes.
>
> ^[[:space:]]*[0-9]+[ ]?   {   /* BASIC line number */
>   uint16_t line=atoi(yytext);
>   putchar(42);  putchar(42);  /* Dummy placeholder values */
>   putchar(line & 0xFF);
>   putchar(line >> 8);
>  }
>
> For me lex makes connecting regular expressions to the actions they
> trigger straightforward and clean. But, that could be because I'm ignorant,
> which is often the case. If there's a better way using advanced regular
> expressions, I'd love to learn it.
>
> —b9
>
>

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Wed, Mar 1, 2023 at 9:39 AM John R. Hogerhuis  wrote:

> Parser systems are less work than they're worth. But lexer systems, not so
> much.
> Modern languages have advanced regular expression systems which are equal
> in power to a lexer. Might as well just use a big regex to lex your tokens.
>

You probably know more about this than me, John, but I'm confused by the
idea of using regexes *instead* of lex. I think of lex as a friendly
wrapper around regular expressions. At its heart, lex is a list of regular
expressions with associated actions for each one. They are implicitly or'ed
and the longest possible match is taken. Most of my tokenizer is just lines
like this:

END putchar(128);FORputchar(129);NEXT   
putchar(130);DATA   putchar(131);INPUT  
putchar(132);DIMputchar(133);READ   
putchar(134);LETputchar(135);

The most "complicated" part is the regexp for matching line numbers which
has to print four bytes.

^[[:space:]]*[0-9]+[ ]? {   /* BASIC line number */
  uint16_t line=atoi(yytext);
  putchar(42);  putchar(42);/* Dummy placeholder values */
  putchar(line & 0xFF);
  putchar(line >> 8);
 }

For me lex makes connecting regular expressions to the actions they trigger
straightforward and clean. But, that could be because I'm ignorant, which
is often the case. If there's a better way using advanced regular
expressions, I'd love to learn it.

—b9

Re: [M100] - Text Sweet 2.3 Release

[Brian White]

127 or 128 so is the limit that the interactive editor can handle, while
the interpreter can handle up to 254 or 255 if you're just executing and
not editing.

bkw

On Wed, Mar 1, 2023, 8:15 PM B 9  wrote:

> On Wed, Mar 1, 2023 at 6:39 AM Brian K. White b.kenyo...@gmail.com
>  wrote:
>
>> I also wrote a renumberer and packer in bash (actually in awk too before
>> that, still in the repo in the "attic")
>>
>> https://github.com/bkw777/BA_stuff
>>
>
>
> Okay, that’s freaking awesome. I can imagine doing it in AWK, but making
> that work in Bash is impressive.
>
>
> I was trying [...]
>>
>> ONAGOSUB310,311,312316,317,318,319
>>
>> and reseq didn't handle that right. I don't know what other renumberers
>> do because I decided at least for what I was working on it would be more
>> convenient to renumber on the host than on the 100.
>>
>
>
> Tricky! I don’t know about other renumberers, but a bit ago I wrote
> something similar: a program to remove all unnecessary comments from a
> program. Part of it was a Bash script, jumpdestinations
> ,
> which identifies the lines which are referenced by other lines and thus
> shouldn’t be removed even if they only contain a REM statement. Until
> today, I used this regular expression:
>
> egrep -io 
> '(GO\s*TO|GOSUB|THEN|ELSE|RESTORE|RESUME|RETURN|RUN)(\s*,?\s*[0-9]+)+'
>
> As you can see, I had missed exactly the same subtlety as reseq.
>
>
>> The packer might be slightly wrong in one aspect. It converts all prints
>> to ?s and rems to 's, which does make the ascii file smaller, but I have
>> since read somewhere that one or both of those may actually result in
>> slightly more ram usage on the 100? I haven't performed a test to find out.
>> So the packer could maybe use an option for that.
>>
>
>
> I analyzed the BA format
> 
> and both ? and PRINT are encoded the same way and make no difference once
> the program is loaded. However, REM and ' are not. If you are looking to
> save space in the ASCII file, then the packer was correct to use ', but
> if you want to save space in the BA file, the packer should have used REM.
>
>
> I am not sure there’s a good use case for minimizing the ASCII file these
> days. Back when 7-bit transfers via TELCOM or LOAD “COM:98N1” were the
> norm, maybe it was worth it, but it seems like a mistake given that the
> ASCII file is only needed briefly while the BA file will remain on the
> computer as long as the program is used.
>
>> I might try to add line-unwrapping to the packer next. There are some
>> unwrapping that would be too involved to try to do, like keeping track of
>> broken but recombinable prints and other literals.
>>
>
>
> Yeah, a proper BASIC parser would be pretty much necessary. But, once you
> had that, you might be able to do fancier things, like unwrapping
> subroutines that are only reachable from one location. For example, lines
> 31000–31020 could be merged into line 23000 in TSWEEP.DO:
>
> 23000 GOSUB 24000:GOSUB 31000:KEY(8) STOP: 
> PRINT@3*YO%+35,"Quit?";:PRINT@4*YO%+35,"(y/n)";:GOSUB2:KEY(8) ON:IF YN%=1 
> THEN CLS:MENU ELSE GOSUB 17200 : GOSUB 17300 : RETURN
> ⋮30090 PRINT@7*YO%+PO%, CHR$(237)+STRING$(38,232)+CHR$(238);:KEY(8) 
> ON:RETURN31000 FOR TY = 0 TO 7 'subroutine: Clear Right Pane31010 PRINT @ 
> TY*YO%+32,STRING$(8,32);31020 NEXT : RETURN
>
>
> But it should be no problem to at least do some combining where if the end
>> of one line is not something like a THEN branch, and the next line number
>> is not a jump target anywhere else in the file, and the total new combined
>> line would be under either the 127 or 254 threshold (whichever you want)
>> it's ok to combine.
>>
>
> Nice. Every line you can remove from the source code will save five bytes
> from the .BA file.
>
> I'm not familiar with the 127 character limit. Is that for the NEC PCs?
> —b9
>
> P.S. What’s the character limit in the .BA format? A quick test of
>
> 10???
>
> shows that I can have a program in memory which is larger than EDIT can
> handle. Perhaps it would be a useful addition to my tokenizer to be able to
> pack lines at the token level.
>
>
>

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Wed, Mar 1, 2023 at 6:39 AM Brian K. White b.kenyo...@gmail.com
 wrote:

> I also wrote a renumberer and packer in bash (actually in awk too before
> that, still in the repo in the "attic")
>
> https://github.com/bkw777/BA_stuff
>


Okay, that’s freaking awesome. I can imagine doing it in AWK, but making
that work in Bash is impressive.


I was trying [...]
>
> ONAGOSUB310,311,312316,317,318,319
>
> and reseq didn't handle that right. I don't know what other renumberers do
> because I decided at least for what I was working on it would be more
> convenient to renumber on the host than on the 100.
>


Tricky! I don’t know about other renumberers, but a bit ago I wrote
something similar: a program to remove all unnecessary comments from a
program. Part of it was a Bash script, jumpdestinations
,
which identifies the lines which are referenced by other lines and thus
shouldn’t be removed even if they only contain a REM statement. Until
today, I used this regular expression:

egrep -io '(GO\s*TO|GOSUB|THEN|ELSE|RESTORE|RESUME|RETURN|RUN)(\s*,?\s*[0-9]+)+'

As you can see, I had missed exactly the same subtlety as reseq.


> The packer might be slightly wrong in one aspect. It converts all prints
> to ?s and rems to 's, which does make the ascii file smaller, but I have
> since read somewhere that one or both of those may actually result in
> slightly more ram usage on the 100? I haven't performed a test to find out.
> So the packer could maybe use an option for that.
>


I analyzed the BA format

and both ? and PRINT are encoded the same way and make no difference once
the program is loaded. However, REM and ' are not. If you are looking to
save space in the ASCII file, then the packer was correct to use ', but if
you want to save space in the BA file, the packer should have used REM.

I am not sure there’s a good use case for minimizing the ASCII file these
days. Back when 7-bit transfers via TELCOM or LOAD “COM:98N1” were the
norm, maybe it was worth it, but it seems like a mistake given that the
ASCII file is only needed briefly while the BA file will remain on the
computer as long as the program is used.

> I might try to add line-unwrapping to the packer next. There are some
> unwrapping that would be too involved to try to do, like keeping track of
> broken but recombinable prints and other literals.
>


Yeah, a proper BASIC parser would be pretty much necessary. But, once you
had that, you might be able to do fancier things, like unwrapping
subroutines that are only reachable from one location. For example, lines
31000–31020 could be merged into line 23000 in TSWEEP.DO:

23000 GOSUB 24000:GOSUB 31000:KEY(8) STOP:
PRINT@3*YO%+35,"Quit?";:PRINT@4*YO%+35,"(y/n)";:GOSUB2:KEY(8)
ON:IF YN%=1 THEN CLS:MENU ELSE GOSUB 17200 : GOSUB 17300 : RETURN
⋮30090 PRINT@7*YO%+PO%, CHR$(237)+STRING$(38,232)+CHR$(238);:KEY(8)
ON:RETURN31000 FOR TY = 0 TO 7 'subroutine: Clear Right Pane31010
PRINT @ TY*YO%+32,STRING$(8,32);31020 NEXT : RETURN


But it should be no problem to at least do some combining where if the end
> of one line is not something like a THEN branch, and the next line number
> is not a jump target anywhere else in the file, and the total new combined
> line would be under either the 127 or 254 threshold (whichever you want)
> it's ok to combine.
>

Nice. Every line you can remove from the source code will save five bytes
from the .BA file.

I'm not familiar with the 127 character limit. Is that for the NEC PCs?
—b9

P.S. What’s the character limit in the .BA format? A quick test of

10???

shows that I can have a program in memory which is larger than EDIT can
handle. Perhaps it would be a useful addition to my tokenizer to be able to
pack lines at the token level.

Re: [M100] - Text Sweet 2.3 Release

[John R. Hogerhuis]

On Tue, Feb 28, 2023, 6:49 PM B 9  wrote:

>
>
> On Tue, Feb 28, 2023 at 4:55 PM grima...@gmail.com 
> wrote:
>
>> Thanks all!
>>
>> At some point I’ll look into adding Tokenization directly into Github.
>>
>
> Awesome. It looks like compiling and running a C program may be trivial in
> the yaml file:
>
> - uses: actions/checkout@v3
>
> - run:   |
>  make
>  ./tokenize FOO.DO
>
>
> By the way, you may be able to use a Python lexer, such as ply
> , to create a Python program from my
> flex source code. However, I suspect that will be more work than it's
> worth.
>
>

Parser systems are less work than they're worth. But lexer systems, not so
much.

Modern languages have advanced regular expression systems which are equal
in power to a lexer. Might as well just use a big regex to lex your tokens.

-- John.

Re: [M100] - Text Sweet 2.3 Release

[Brian K. White]

I also wrote a renumberer and packer in bash (actually in awk too before 
that, still in the repo in the "attic")


https://github.com/bkw777/BA_stuff


The interface could be improved to operate on normal commandline 
arguments instead of env variables and only piping stdin and stdout.


The renumberer in particular actually gets some odd but legal constructs 
right that some others like fail to.


I was trying to use 
https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-08-TECH-PROGRAMMING/RESEQ.100


 to renumber https://ftp.whtech.com/club100/drv/sector.ba, and it was 
getting one thing wrong. sector.ba includes a command with a comma 
seperated list of line numbers, with some of the values empty:


ONAGOSUB310,311,312316,317,318,319

and reseq didn't handle that right. I don't know what other renumberers 
do because I decided at least for what I was working on it would be more 
convenient to renumber on the hos than on the 100. But if you're writing 
on the 100 it obviously would be handy to have the ability on the 100. I 
think one of the option roms like cluseau has a renumberer in rom? I 
would probably try to use that if I were writing on the 100 simply to 
avoid consuming ram.



The packer might be slightly wrong in one aspect. It converts all prints 
to ?s and rems to 's, which does make the ascii file smaller, but I have 
since read somewhere that one or both of those may actually result in 
slightly more ram usage on the 100? I haven't performed a test to find 
out. So the packer could maybe use an option for that.


I might try to add line-unwrapping to the packer next. There are some 
unwrapping that would be too involved to try to do, like keeping track 
of broken but recombinable prints and other literals. But it should be 
no problem to at least do some combining where if the end of one line is 
not something like a THEN branch, and the next line number is not a jump 
target anywhere else in the file, and the total new combined line would 
be under either the 127 or 254 threshold (whichever you want) it's ok to 
combine.


--
bkw

On Tue, Feb 28, 2023, 10:33 PM grima...@gmail.com  
wrote:


   I used Renum1 from Club100 library.

   I have inspected the tokenized BA in a hex editor. As far as I can
   tell, line numbers aren’t really compressed in any way. So in my
   original program, most of my line numbers were between 1000-3,
   and each reference to them was 4-5 bytes.

   Now most of my lines are 1-3 bytes after renumbering from 1.

   I also do use Packer.BA from Club100. This removes comments, and
   combines lines that aren’t referenced by GOTO, GOSUB, etc.

   Best,
   George

   On Tue, Feb 28, 2023 at 9:49 PM B 9  wrote:



   On Tue, Feb 28, 2023 at 4:55 PM grima...@gmail.com
wrote:

   Thanks all!

   At some point I’ll look into adding Tokenization directly
   into Github.


   Awesome. It looks like compiling and running a C program may be
   trivial in the yaml file:

   -uses:actions/checkout@v3

   |- run: | make ./tokenize FOO.DO|


   By the way, you may be able to use a Python lexer, such as ply
   , to create a Python
   program from my flex source code. However, I suspect that will
   be more work than it's worth.

   I also used a line renumberer which brought down the .BA
   file to 76% of the previous version.


   Wow. What renumberer did you use? And why did renumbering reduce
   the file size?

   By the way, a tokenizer should be able to reduce the file size
   dramatically by simply omitting the string after REM statements.
   Having it remove vestigial lines completely would be slightly
   trickier and probably require a second pass as it'd have to make
   sure the line was not a target of GOTO (or any of the other
   varied ways of referring to line numbers).

   —b9

Re: [M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

I used Renum1 from Club100 library.

I have inspected the tokenized BA in a hex editor. As far as I can tell,
line numbers aren’t really compressed in any way. So in my original
program, most of my line numbers were between 1000-3, and each
reference to them was 4-5 bytes.

Now most of my lines are 1-3 bytes after renumbering from 1.

I also do use Packer.BA from Club100. This removes comments, and combines
lines that aren’t referenced by GOTO, GOSUB, etc.

Best,
George

On Tue, Feb 28, 2023 at 9:49 PM B 9  wrote:

>
>
> On Tue, Feb 28, 2023 at 4:55 PM grima...@gmail.com 
> wrote:
>
>> Thanks all!
>>
>> At some point I’ll look into adding Tokenization directly into Github.
>>
>
> Awesome. It looks like compiling and running a C program may be trivial in
> the yaml file:
>
> - uses: actions/checkout@v3
>
> - run:   |
>  make
>  ./tokenize FOO.DO
>
>
> By the way, you may be able to use a Python lexer, such as ply
> , to create a Python program from my
> flex source code. However, I suspect that will be more work than it's
> worth.
>
>
> I also used a line renumberer which brought down the .BA file to 76% of
>> the previous version.
>
>
> Wow. What renumberer did you use? And why did renumbering reduce the file
> size?
>
> By the way, a tokenizer should be able to reduce the file size
> dramatically by simply omitting the string after REM statements. Having it
> remove vestigial lines completely would be slightly trickier and probably
> require a second pass as it'd have to make sure the line was not a target
> of GOTO (or any of the other varied ways of referring to line numbers).
>
> —b9
>

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Tue, Feb 28, 2023 at 6:40 PM B 9 hacke...@gmail.com
 wrote:

By the way, a tokenizer should be able to reduce the file size dramatically
> by simply omitting the string after REM statements. Having it remove
> vestigial lines completely would be slightly trickier and probably require
> a second pass as it'd have to make sure the line was not a target of GOTO
> (or any of the other varied ways of referring to line numbers).
>
Okay, I made a quick and dirty tokenizer that removes comments
 and extra white
space. It does not do the second pass to remove unneeded lines or anything
fancy, like converting ' to REM (which takes up less space). It's not as
good as the renumberer used on TSWEEP, but it's close, creating a binary
that is only 500 bytes larger.

—b9

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Tue, Feb 28, 2023 at 4:55 PM grima...@gmail.com 
wrote:

> Thanks all!
>
> At some point I’ll look into adding Tokenization directly into Github.
>

Awesome. It looks like compiling and running a C program may be trivial in
the yaml file:

- uses: actions/checkout@v3

- run:   |
 make
 ./tokenize FOO.DO


By the way, you may be able to use a Python lexer, such as ply
, to create a Python program from my
flex source code. However, I suspect that will be more work than it's
worth.


I also used a line renumberer which brought down the .BA file to 76% of the
> previous version.


Wow. What renumberer did you use? And why did renumbering reduce the file
size?

By the way, a tokenizer should be able to reduce the file size dramatically
by simply omitting the string after REM statements. Having it remove
vestigial lines completely would be slightly trickier and probably require
a second pass as it'd have to make sure the line was not a target of GOTO
(or any of the other varied ways of referring to line numbers).

—b9

Re: [M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

I work for a relatively major fintech company, and we have used GitHub
actions at scale to automate a ton of workflows, some examples include:

- code and file validation.
- unit testing.
- cloud infrastructure deployment.

Github Actions are just a good way to automate and glue together different
things. For example, embedding your tokenizer into an action would
potentially allow anyone who wants to write Tandy BASIC code and publish it
to GitHub to automatically tokenize it from ASCII on commit.

Alternatively if you prefer to be a bit more generic, you could put your
Tokenizer behind an API and then create a Github action that basically just
interfaces with that API. That way people who aren’t using Github could
still access your Tokenizer-As-A-Service (TAAS)

This seems like a promising solution. However, I don’t really know anything
about C executables, I’m afraid I live over in Python land.

-George


On Tue, Feb 28, 2023 at 2:20 PM B 9  wrote:

> On Mon, Feb 27, 2023 at 7:51 AM grima...@gmail.com grima...@gmail.com
>  wrote:
>
> Currently I’m using VS Code and Virtual T in tandem to develop. It would
>> be great if there were a modern tokenizer and packer written in Python or
>> similar.
>
> Last year I wrote a tokenizer in C. ¹
>
> https://github.com/hackerb9/tokenize
>
> It can handle WIDTH and DSKO$ and it’s easy to add new tokens if some
> other variant of BASIC appears.
>
> While it will work fine for your project, I consider it incomplete as it
> does not generate N82 BASIC tokens, yet.
>
> I’m curious about people’s experiences using GitHub Actions. I haven’t
> used them as I worried it would tie my projects too closely to one company.
> Now that Nektos' act  exists, I'm
> reconsidering.
>
> —b9
> --
>
> ¹ Technically, I wrote it in flex which made tokenization trivial. Flex
> outputs C code, so the program runs anywhere without requiring flex as a
> dependency. I haven’t tried it, but there is a tool called Flex.js which is
> supposed to output JavaScript, if you’re into that kind of thing.
>

Re: [M100] - Text Sweet 2.3 Release

[Joshua O'Keefe]

> On Feb 28, 2023, at 11:21 AM, B 9  wrote:

> Last year I wrote a tokenizer in C. ¹ [well, lexx]
> https://github.com/hackerb9/tokenize
> 

Thank you for reminding me of this!  I was trying to remember it and it was the 
lexx I wanted!

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Tue, Feb 28, 2023 at 11:03 AM B 9  wrote:

> Last year I wrote a tokenizer in C. ¹
>
> https://github.com/hackerb9/tokenize
>
Addendum: the binaries it generates work fine on actual machines, but
Virtual T is overly persnickety about the memory pointers. I'd forgotten
about this as I patched my copy of Virtual T.

—b9

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Mon, Feb 27, 2023 at 7:51 AM grima...@gmail.com grima...@gmail.com
 wrote:

Currently I’m using VS Code and Virtual T in tandem to develop. It would be
> great if there were a modern tokenizer and packer written in Python or
> similar.

Last year I wrote a tokenizer in C. ¹

https://github.com/hackerb9/tokenize

It can handle WIDTH and DSKO$ and it’s easy to add new tokens if some other
variant of BASIC appears.

While it will work fine for your project, I consider it incomplete as it
does not generate N82 BASIC tokens, yet.

I’m curious about people’s experiences using GitHub Actions. I haven’t used
them as I worried it would tie my projects too closely to one company. Now
that Nektos' act  exists, I'm reconsidering.

—b9
--

¹ Technically, I wrote it in flex which made tokenization trivial. Flex
outputs C code, so the program runs anywhere without requiring flex as a
dependency. I haven’t tried it, but there is a tool called Flex.js which is
supposed to output JavaScript, if you’re into that kind of thing.

Re: [M100] - Text Sweet 2.3 Release

[MikeS]

Is that tokenizer Bob Pigford's version? AFAIK it was the latest and best of 
the various versions out there.

m
  - Original Message - 
  From: grima...@gmail.com 
  To: m...@bitchin100.com 
  Sent: Monday, February 27, 2023 7:42 AM
  Subject: Re: [M100] - Text Sweet 2.3 Release


  Thanks for the feedback!


  I’ll try to look into that line terminator business and see whats going on.


  Currently I’m using VS Code and Virtual T in tandem to develop. It would be 
great if there were a modern tokenizer and packer written in Python or similar.


  Then you could tie it in with github actions to tokenize, pack, and commit 
the .DO and BA.


  Best I could find was an old EXE tokenizer meant to run on older version of 
Windows.


  Best,
  George


  On Sun, Feb 26, 2023 at 10:20 PM Stephen Adolph  wrote:

hey works great!!!
thanks George. I'm using my (updated!) MVT100 Desktop terminal emulator to 
play Tsweep!


steve



On Sun, Feb 26, 2023 at 6:02 PM grima...@gmail.com  
wrote:

  Hi Steve,


  I updated it again. I think I accidentally uploaded the wrong file 
initially.


  https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.2


  https://imgur.com/a/JyLsAdX


  I’ve linked photos of how it renders on a real DVI. The above is how I 
have intended it to look.


  Let me know if you’re getting the same results with your program.


  Re: ASCII not loading cleanly. I’ve been experiencing issues when loading 
the ASCII as .BA in Virtual T. However, if I load it as .DO first and then use 
BASIC to tokenize it (either in Virtual T or real hardware), it works fine.


  Not sure if perhaps there is a bug in Virtual T or not.


  -George


  On Sun, Feb 26, 2023 at 5:08 PM Stephen Adolph  
wrote:

thanks George.
I loaded it (.BA version, the .DO version won't load clean.


Runs, but the controls are on top of the bottom half of the board.  

but I can see it coming together!
cheers and thanks
Steve



On Sun, Feb 26, 2023 at 4:41 PM grima...@gmail.com  
wrote:

  Hi Steve,


  https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1


  I just put together a pre-release of 2.5.1, which I have tested 
against the original DVI hardware and it works now in both 40 col and 80 col 
mode. Feel free to check it out with your DVI Work Alike solution, and let me 
know what you think.


  Best,
  George


  On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph  
wrote:


yes, 

I have done a lot of work on making an external 80column video 
solution that is a  "DVI work alike" accessible without actually having a DVI.


First you need some driver software on the M100.
1) VT100 driver - found here --> 
https://bitchin100.com/wiki/index.php?title=VT100
or
2) via REX#/REXCPM.


To actually show video on an external monitor, the driver software 
treats Screen1 as RS-232 and Screen2 as serial via a hardware hack to the BCR 
port.   So, an external serial terminal can be used to show the video info.


Then you need a solution for serial terminal.
There are 2
1)  MVT100 video adapter, based on the Geoff VT100 serial terminal 
board --> https://bitchin100.com/wiki/index.php?title=VT100 
or
2) the MVT100 windows application found here --> 
http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;


Anyhow, I find external video quite nice to have but I never 
appreciated the DVI much myself.  Had 2, sold them both.








On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
 wrote:

  I see, when you say your DVI software do you mean the software 
that emulates the DVI itself?


  Modifying the print statements is definitely doable, and I can 
add that to my TODOs.


  However, as someone who uses the DVI, I personally do like the 40 
column mode. Being able to switch between 40 and 80 col on demand is useful in 
my opinion. Very similar to how the Apple II works: 40col is just more legible 
in a lot of situations.


  -George 


  On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
 wrote:

my stuff doesn't support 40 columns.  that's why I was asking!
To me, 40 column mode on the DVI seems silly, but that's just 
me.


Anyways, if you don't want to adapt the print@ statements, I 
get it.
thanks anyways.




On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
 wrote:

  I think the way I would prefer to handle it would be to check 
the initial setting of 40/80 when the program starts, switch the screen to 40, 
and then switch back on exit.


  Do you know is there a way to s

Re: [M100] - Text Sweet 2.3 Release

[John R. Hogerhuis]

You could try CloudT as a tokenizer.

But it is probably something very simple happening in the text editor.
Extra blankline, encoding or something.

-- John.

Re: [M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

Thanks for the feedback!

I’ll try to look into that line terminator business and see whats going on.

Currently I’m using VS Code and Virtual T in tandem to develop. It would be
great if there were a modern tokenizer and packer written in Python or
similar.

Then you could tie it in with github actions to tokenize, pack, and commit
the .DO and BA.

Best I could find was an old EXE tokenizer meant to run on older version of
Windows.

Best,
George

On Sun, Feb 26, 2023 at 10:20 PM Stephen Adolph 
wrote:

> hey works great!!!
> thanks George. I'm using my (updated!) MVT100 Desktop terminal emulator to
> play Tsweep!
>
> steve
>
> On Sun, Feb 26, 2023 at 6:02 PM grima...@gmail.com 
> wrote:
>
>> Hi Steve,
>>
>> I updated it again. I think I accidentally uploaded the wrong file
>> initially.
>>
>> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.2
>>
>> https://imgur.com/a/JyLsAdX
>>
>> I’ve linked photos of how it renders on a real DVI. The above is how I
>> have intended it to look.
>>
>> Let me know if you’re getting the same results with your program.
>>
>> Re: ASCII not loading cleanly. I’ve been experiencing issues when loading
>> the ASCII as .BA in Virtual T. However, if I load it as .DO first and then
>> use BASIC to tokenize it (either in Virtual T or real hardware), it works
>> fine.
>>
>> Not sure if perhaps there is a bug in Virtual T or not.
>>
>> -George
>>
>> On Sun, Feb 26, 2023 at 5:08 PM Stephen Adolph 
>> wrote:
>>
>>> thanks George.
>>> I loaded it (.BA version, the .DO version won't load clean.
>>>
>>> Runs, but the controls are on top of the bottom half of the board.
>>> but I can see it coming together!
>>> cheers and thanks
>>> Steve
>>>
>>> On Sun, Feb 26, 2023 at 4:41 PM grima...@gmail.com 
>>> wrote:
>>>
 Hi Steve,

 https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1

 I just put together a pre-release of 2.5.1, which I have tested against
 the original DVI hardware and it works now in both 40 col and 80 col mode.
 Feel free to check it out with your DVI Work Alike solution, and let me
 know what you think.

 Best,
 George

 On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph 
 wrote:

> [image: ResizerImage574X765.jpg]
> yes,
> I have done a lot of work on making an external 80column video
> solution that is a  "DVI work alike" accessible without actually having a
> DVI.
>
> First you need some driver software on the M100.
> 1) VT100 driver - found here -->
> https://bitchin100.com/wiki/index.php?title=VT100
> or
> 2) via REX#/REXCPM.
>
> To actually show video on an external monitor, the driver software
> treats Screen1 as RS-232 and Screen2 as serial via a hardware hack to the
> BCR port.   So, an external serial terminal can be used to show the video
> info.
>
> Then you need a solution for serial terminal.
> There are 2
> 1)  MVT100 video adapter, based on the Geoff VT100 serial terminal
> board --> https://bitchin100.com/wiki/index.php?title=VT100
> or
> 2) the MVT100 windows application found here -->
> http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;
>
> Anyhow, I find external video quite nice to have but I never
> appreciated the DVI much myself.  Had 2, sold them both.
>
>
>
>
> On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
> wrote:
>
>> I see, when you say your DVI software do you mean the software that
>> emulates the DVI itself?
>>
>> Modifying the print statements is definitely doable, and I can add
>> that to my TODOs.
>>
>> However, as someone who uses the DVI, I personally do like the 40
>> column mode. Being able to switch between 40 and 80 col on demand is 
>> useful
>> in my opinion. Very similar to how the Apple II works: 40col is just more
>> legible in a lot of situations.
>>
>> -George
>>
>> On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
>> wrote:
>>
>>> my stuff doesn't support 40 columns.  that's why I was asking!
>>> To me, 40 column mode on the DVI seems silly, but that's just me.
>>>
>>> Anyways, if you don't want to adapt the print@ statements, I get it.
>>> thanks anyways.
>>>
>>>
>>> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com <
>>> grima...@gmail.com> wrote:
>>>
 I think the way I would prefer to handle it would be to check the
 initial setting of 40/80 when the program starts, switch the screen to 
 40,
 and then switch back on exit.

 Do you know is there a way to switch to 40 columns mode without
 calling WIDTH? I assume if I use any keywords exclusive to Disk Basic 
 it
 will break compatibility with regular Basic.

 Best,
 George

 On Sun, Feb 26, 2023 at 2:17 PM 

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

hey works great!!!
thanks George. I'm using my (updated!) MVT100 Desktop terminal emulator to
play Tsweep!

steve

On Sun, Feb 26, 2023 at 6:02 PM grima...@gmail.com 
wrote:

> Hi Steve,
>
> I updated it again. I think I accidentally uploaded the wrong file
> initially.
>
> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.2
>
> https://imgur.com/a/JyLsAdX
>
> I’ve linked photos of how it renders on a real DVI. The above is how I
> have intended it to look.
>
> Let me know if you’re getting the same results with your program.
>
> Re: ASCII not loading cleanly. I’ve been experiencing issues when loading
> the ASCII as .BA in Virtual T. However, if I load it as .DO first and then
> use BASIC to tokenize it (either in Virtual T or real hardware), it works
> fine.
>
> Not sure if perhaps there is a bug in Virtual T or not.
>
> -George
>
> On Sun, Feb 26, 2023 at 5:08 PM Stephen Adolph 
> wrote:
>
>> thanks George.
>> I loaded it (.BA version, the .DO version won't load clean.
>>
>> Runs, but the controls are on top of the bottom half of the board.
>> but I can see it coming together!
>> cheers and thanks
>> Steve
>>
>> On Sun, Feb 26, 2023 at 4:41 PM grima...@gmail.com 
>> wrote:
>>
>>> Hi Steve,
>>>
>>> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1
>>>
>>> I just put together a pre-release of 2.5.1, which I have tested against
>>> the original DVI hardware and it works now in both 40 col and 80 col mode.
>>> Feel free to check it out with your DVI Work Alike solution, and let me
>>> know what you think.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph 
>>> wrote:
>>>
 [image: ResizerImage574X765.jpg]
 yes,
 I have done a lot of work on making an external 80column video solution
 that is a  "DVI work alike" accessible without actually having a DVI.

 First you need some driver software on the M100.
 1) VT100 driver - found here -->
 https://bitchin100.com/wiki/index.php?title=VT100
 or
 2) via REX#/REXCPM.

 To actually show video on an external monitor, the driver software
 treats Screen1 as RS-232 and Screen2 as serial via a hardware hack to the
 BCR port.   So, an external serial terminal can be used to show the video
 info.

 Then you need a solution for serial terminal.
 There are 2
 1)  MVT100 video adapter, based on the Geoff VT100 serial terminal
 board --> https://bitchin100.com/wiki/index.php?title=VT100
 or
 2) the MVT100 windows application found here -->
 http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;

 Anyhow, I find external video quite nice to have but I never
 appreciated the DVI much myself.  Had 2, sold them both.




 On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
 wrote:

> I see, when you say your DVI software do you mean the software that
> emulates the DVI itself?
>
> Modifying the print statements is definitely doable, and I can add
> that to my TODOs.
>
> However, as someone who uses the DVI, I personally do like the 40
> column mode. Being able to switch between 40 and 80 col on demand is 
> useful
> in my opinion. Very similar to how the Apple II works: 40col is just more
> legible in a lot of situations.
>
> -George
>
> On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
> wrote:
>
>> my stuff doesn't support 40 columns.  that's why I was asking!
>> To me, 40 column mode on the DVI seems silly, but that's just me.
>>
>> Anyways, if you don't want to adapt the print@ statements, I get it.
>> thanks anyways.
>>
>>
>> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com <
>> grima...@gmail.com> wrote:
>>
>>> I think the way I would prefer to handle it would be to check the
>>> initial setting of 40/80 when the program starts, switch the screen to 
>>> 40,
>>> and then switch back on exit.
>>>
>>> Do you know is there a way to switch to 40 columns mode without
>>> calling WIDTH? I assume if I use any keywords exclusive to Disk Basic it
>>> will break compatibility with regular Basic.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
>>> wrote:
>>>
 George,
 I think it would be fine to use only 40 columns.
 just make it tolerate 80 cols wide.
 (all of my DVI software assumes 80 columns).
 thoughts?
 Steve



 On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com <
 grima...@gmail.com> wrote:

> Hi Steve,
>
> As of right now, it’s supporting only 40col mode.
>
> Currently, the way I am taking advantage of the DVI and T200
> larger displays are to have the Controls/Help screen displayed below 
> the
> game 

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

Thank you!  Can't test until later tonight.

When I transfer the .do file to my m100 it has some strange line
terminators.

I use mComm to transfer.  I'll check it out more closely later.

Steve

On Sunday, February 26, 2023, grima...@gmail.com  wrote:

> Hi Steve,
>
> I updated it again. I think I accidentally uploaded the wrong file
> initially.
>
> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.2
>
> https://imgur.com/a/JyLsAdX
>
> I’ve linked photos of how it renders on a real DVI. The above is how I
> have intended it to look.
>
> Let me know if you’re getting the same results with your program.
>
> Re: ASCII not loading cleanly. I’ve been experiencing issues when loading
> the ASCII as .BA in Virtual T. However, if I load it as .DO first and then
> use BASIC to tokenize it (either in Virtual T or real hardware), it works
> fine.
>
> Not sure if perhaps there is a bug in Virtual T or not.
>
> -George
>
> On Sun, Feb 26, 2023 at 5:08 PM Stephen Adolph 
> wrote:
>
>> thanks George.
>> I loaded it (.BA version, the .DO version won't load clean.
>>
>> Runs, but the controls are on top of the bottom half of the board.
>> but I can see it coming together!
>> cheers and thanks
>> Steve
>>
>> On Sun, Feb 26, 2023 at 4:41 PM grima...@gmail.com 
>> wrote:
>>
>>> Hi Steve,
>>>
>>> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1
>>>
>>> I just put together a pre-release of 2.5.1, which I have tested against
>>> the original DVI hardware and it works now in both 40 col and 80 col mode.
>>> Feel free to check it out with your DVI Work Alike solution, and let me
>>> know what you think.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph 
>>> wrote:
>>>
 [image: ResizerImage574X765.jpg]
 yes,
 I have done a lot of work on making an external 80column video solution
 that is a  "DVI work alike" accessible without actually having a DVI.

 First you need some driver software on the M100.
 1) VT100 driver - found here --> https://bitchin100.com/wiki/
 index.php?title=VT100
 or
 2) via REX#/REXCPM.

 To actually show video on an external monitor, the driver software
 treats Screen1 as RS-232 and Screen2 as serial via a hardware hack to the
 BCR port.   So, an external serial terminal can be used to show the video
 info.

 Then you need a solution for serial terminal.
 There are 2
 1)  MVT100 video adapter, based on the Geoff VT100 serial terminal
 board --> https://bitchin100.com/wiki/index.php?title=VT100
 or
 2) the MVT100 windows application found here -->
 http://club100.org/memfiles/index.php?direction==;
 directory=Steve%20Adolph/MVT100%20for%20PC&

 Anyhow, I find external video quite nice to have but I never
 appreciated the DVI much myself.  Had 2, sold them both.




 On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
 wrote:

> I see, when you say your DVI software do you mean the software that
> emulates the DVI itself?
>
> Modifying the print statements is definitely doable, and I can add
> that to my TODOs.
>
> However, as someone who uses the DVI, I personally do like the 40
> column mode. Being able to switch between 40 and 80 col on demand is 
> useful
> in my opinion. Very similar to how the Apple II works: 40col is just more
> legible in a lot of situations.
>
> -George
>
> On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
> wrote:
>
>> my stuff doesn't support 40 columns.  that's why I was asking!
>> To me, 40 column mode on the DVI seems silly, but that's just me.
>>
>> Anyways, if you don't want to adapt the print@ statements, I get it.
>> thanks anyways.
>>
>>
>> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com <
>> grima...@gmail.com> wrote:
>>
>>> I think the way I would prefer to handle it would be to check the
>>> initial setting of 40/80 when the program starts, switch the screen to 
>>> 40,
>>> and then switch back on exit.
>>>
>>> Do you know is there a way to switch to 40 columns mode without
>>> calling WIDTH? I assume if I use any keywords exclusive to Disk Basic it
>>> will break compatibility with regular Basic.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
>>> wrote:
>>>
 George,
 I think it would be fine to use only 40 columns.
 just make it tolerate 80 cols wide.
 (all of my DVI software assumes 80 columns).
 thoughts?
 Steve



 On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com <
 grima...@gmail.com> wrote:

> Hi Steve,
>
> As of right now, it’s supporting only 40col mode.
>
> Currently, the way I am taking advantage of the DVI and T200
> larger 

Re: [M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

Hi Steve,

I updated it again. I think I accidentally uploaded the wrong file
initially.

https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.2

https://imgur.com/a/JyLsAdX

I’ve linked photos of how it renders on a real DVI. The above is how I have
intended it to look.

Let me know if you’re getting the same results with your program.

Re: ASCII not loading cleanly. I’ve been experiencing issues when loading
the ASCII as .BA in Virtual T. However, if I load it as .DO first and then
use BASIC to tokenize it (either in Virtual T or real hardware), it works
fine.

Not sure if perhaps there is a bug in Virtual T or not.

-George

On Sun, Feb 26, 2023 at 5:08 PM Stephen Adolph  wrote:

> thanks George.
> I loaded it (.BA version, the .DO version won't load clean.
>
> Runs, but the controls are on top of the bottom half of the board.
> but I can see it coming together!
> cheers and thanks
> Steve
>
> On Sun, Feb 26, 2023 at 4:41 PM grima...@gmail.com 
> wrote:
>
>> Hi Steve,
>>
>> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1
>>
>> I just put together a pre-release of 2.5.1, which I have tested against
>> the original DVI hardware and it works now in both 40 col and 80 col mode.
>> Feel free to check it out with your DVI Work Alike solution, and let me
>> know what you think.
>>
>> Best,
>> George
>>
>> On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph 
>> wrote:
>>
>>> [image: ResizerImage574X765.jpg]
>>> yes,
>>> I have done a lot of work on making an external 80column video solution
>>> that is a  "DVI work alike" accessible without actually having a DVI.
>>>
>>> First you need some driver software on the M100.
>>> 1) VT100 driver - found here -->
>>> https://bitchin100.com/wiki/index.php?title=VT100
>>> or
>>> 2) via REX#/REXCPM.
>>>
>>> To actually show video on an external monitor, the driver software
>>> treats Screen1 as RS-232 and Screen2 as serial via a hardware hack to the
>>> BCR port.   So, an external serial terminal can be used to show the video
>>> info.
>>>
>>> Then you need a solution for serial terminal.
>>> There are 2
>>> 1)  MVT100 video adapter, based on the Geoff VT100 serial terminal board
>>> --> https://bitchin100.com/wiki/index.php?title=VT100
>>> or
>>> 2) the MVT100 windows application found here -->
>>> http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;
>>>
>>> Anyhow, I find external video quite nice to have but I never appreciated
>>> the DVI much myself.  Had 2, sold them both.
>>>
>>>
>>>
>>>
>>> On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
>>> wrote:
>>>
 I see, when you say your DVI software do you mean the software that
 emulates the DVI itself?

 Modifying the print statements is definitely doable, and I can add that
 to my TODOs.

 However, as someone who uses the DVI, I personally do like the 40
 column mode. Being able to switch between 40 and 80 col on demand is useful
 in my opinion. Very similar to how the Apple II works: 40col is just more
 legible in a lot of situations.

 -George

 On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
 wrote:

> my stuff doesn't support 40 columns.  that's why I was asking!
> To me, 40 column mode on the DVI seems silly, but that's just me.
>
> Anyways, if you don't want to adapt the print@ statements, I get it.
> thanks anyways.
>
>
> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
> wrote:
>
>> I think the way I would prefer to handle it would be to check the
>> initial setting of 40/80 when the program starts, switch the screen to 
>> 40,
>> and then switch back on exit.
>>
>> Do you know is there a way to switch to 40 columns mode without
>> calling WIDTH? I assume if I use any keywords exclusive to Disk Basic it
>> will break compatibility with regular Basic.
>>
>> Best,
>> George
>>
>> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
>> wrote:
>>
>>> George,
>>> I think it would be fine to use only 40 columns.
>>> just make it tolerate 80 cols wide.
>>> (all of my DVI software assumes 80 columns).
>>> thoughts?
>>> Steve
>>>
>>>
>>>
>>> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com <
>>> grima...@gmail.com> wrote:
>>>
 Hi Steve,

 As of right now, it’s supporting only 40col mode.

 Currently, the way I am taking advantage of the DVI and T200 larger
 displays are to have the Controls/Help screen displayed below the game
 screen (preventing the need to switch between the two)

 As others have mentioned, I could allow for an actual larger
 minefield. However, at this time, I don’t have plans for that.

 My primary goals in the short terms are to improve the base game
 experience, which in my mind is oriented around the M100, as well as to
 

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

thanks George.
I loaded it (.BA version, the .DO version won't load clean.

Runs, but the controls are on top of the bottom half of the board.
but I can see it coming together!
cheers and thanks
Steve

On Sun, Feb 26, 2023 at 4:41 PM grima...@gmail.com 
wrote:

> Hi Steve,
>
> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1
>
> I just put together a pre-release of 2.5.1, which I have tested against
> the original DVI hardware and it works now in both 40 col and 80 col mode.
> Feel free to check it out with your DVI Work Alike solution, and let me
> know what you think.
>
> Best,
> George
>
> On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph 
> wrote:
>
>> [image: ResizerImage574X765.jpg]
>> yes,
>> I have done a lot of work on making an external 80column video solution
>> that is a  "DVI work alike" accessible without actually having a DVI.
>>
>> First you need some driver software on the M100.
>> 1) VT100 driver - found here -->
>> https://bitchin100.com/wiki/index.php?title=VT100
>> or
>> 2) via REX#/REXCPM.
>>
>> To actually show video on an external monitor, the driver software treats
>> Screen1 as RS-232 and Screen2 as serial via a hardware hack to the BCR
>> port.   So, an external serial terminal can be used to show the video info.
>>
>> Then you need a solution for serial terminal.
>> There are 2
>> 1)  MVT100 video adapter, based on the Geoff VT100 serial terminal board
>> --> https://bitchin100.com/wiki/index.php?title=VT100
>> or
>> 2) the MVT100 windows application found here -->
>> http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;
>>
>> Anyhow, I find external video quite nice to have but I never appreciated
>> the DVI much myself.  Had 2, sold them both.
>>
>>
>>
>>
>> On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
>> wrote:
>>
>>> I see, when you say your DVI software do you mean the software that
>>> emulates the DVI itself?
>>>
>>> Modifying the print statements is definitely doable, and I can add that
>>> to my TODOs.
>>>
>>> However, as someone who uses the DVI, I personally do like the 40 column
>>> mode. Being able to switch between 40 and 80 col on demand is useful in my
>>> opinion. Very similar to how the Apple II works: 40col is just more legible
>>> in a lot of situations.
>>>
>>> -George
>>>
>>> On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
>>> wrote:
>>>
 my stuff doesn't support 40 columns.  that's why I was asking!
 To me, 40 column mode on the DVI seems silly, but that's just me.

 Anyways, if you don't want to adapt the print@ statements, I get it.
 thanks anyways.


 On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
 wrote:

> I think the way I would prefer to handle it would be to check the
> initial setting of 40/80 when the program starts, switch the screen to 40,
> and then switch back on exit.
>
> Do you know is there a way to switch to 40 columns mode without
> calling WIDTH? I assume if I use any keywords exclusive to Disk Basic it
> will break compatibility with regular Basic.
>
> Best,
> George
>
> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
> wrote:
>
>> George,
>> I think it would be fine to use only 40 columns.
>> just make it tolerate 80 cols wide.
>> (all of my DVI software assumes 80 columns).
>> thoughts?
>> Steve
>>
>>
>>
>> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com <
>> grima...@gmail.com> wrote:
>>
>>> Hi Steve,
>>>
>>> As of right now, it’s supporting only 40col mode.
>>>
>>> Currently, the way I am taking advantage of the DVI and T200 larger
>>> displays are to have the Controls/Help screen displayed below the game
>>> screen (preventing the need to switch between the two)
>>>
>>> As others have mentioned, I could allow for an actual larger
>>> minefield. However, at this time, I don’t have plans for that.
>>>
>>> My primary goals in the short terms are to improve the base game
>>> experience, which in my mind is oriented around the M100, as well as to
>>> ensure that same experience is achieved on the T200 and DVI.
>>>
>>> If I were to support 80-col mode at this time, I would basically
>>> just end up leaving the right hand 40 columns empty.
>>>
>>> The next few things I’m working on:
>>> 1. Reduce size of TSWEEP.BA in memory
>>> 2. Compact some of the array vars I’m using to require less RAM.
>>> 3. Add a few different pre-canned difficulty level aside from the
>>> Standard/Custom I have today.
>>> 4. Increase performance of the screen redrawing routine.
>>> 5. Increase overall performance of the DFS algorithm when revealing
>>> mines.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
>>> wrote:
>>>
 George,
 for DVI use, is that intended for 40 columns?
 

Re: [M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

Hi Steve,

https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1

I just put together a pre-release of 2.5.1, which I have tested against the
original DVI hardware and it works now in both 40 col and 80 col mode. Feel
free to check it out with your DVI Work Alike solution, and let me know
what you think.

Best,
George

On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph  wrote:

> [image: ResizerImage574X765.jpg]
> yes,
> I have done a lot of work on making an external 80column video solution
> that is a  "DVI work alike" accessible without actually having a DVI.
>
> First you need some driver software on the M100.
> 1) VT100 driver - found here -->
> https://bitchin100.com/wiki/index.php?title=VT100
> or
> 2) via REX#/REXCPM.
>
> To actually show video on an external monitor, the driver software treats
> Screen1 as RS-232 and Screen2 as serial via a hardware hack to the BCR
> port.   So, an external serial terminal can be used to show the video info.
>
> Then you need a solution for serial terminal.
> There are 2
> 1)  MVT100 video adapter, based on the Geoff VT100 serial terminal board
> --> https://bitchin100.com/wiki/index.php?title=VT100
> or
> 2) the MVT100 windows application found here -->
> http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;
>
> Anyhow, I find external video quite nice to have but I never appreciated
> the DVI much myself.  Had 2, sold them both.
>
>
>
>
> On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
> wrote:
>
>> I see, when you say your DVI software do you mean the software that
>> emulates the DVI itself?
>>
>> Modifying the print statements is definitely doable, and I can add that
>> to my TODOs.
>>
>> However, as someone who uses the DVI, I personally do like the 40 column
>> mode. Being able to switch between 40 and 80 col on demand is useful in my
>> opinion. Very similar to how the Apple II works: 40col is just more legible
>> in a lot of situations.
>>
>> -George
>>
>> On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
>> wrote:
>>
>>> my stuff doesn't support 40 columns.  that's why I was asking!
>>> To me, 40 column mode on the DVI seems silly, but that's just me.
>>>
>>> Anyways, if you don't want to adapt the print@ statements, I get it.
>>> thanks anyways.
>>>
>>>
>>> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
>>> wrote:
>>>
 I think the way I would prefer to handle it would be to check the
 initial setting of 40/80 when the program starts, switch the screen to 40,
 and then switch back on exit.

 Do you know is there a way to switch to 40 columns mode without calling
 WIDTH? I assume if I use any keywords exclusive to Disk Basic it will break
 compatibility with regular Basic.

 Best,
 George

 On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
 wrote:

> George,
> I think it would be fine to use only 40 columns.
> just make it tolerate 80 cols wide.
> (all of my DVI software assumes 80 columns).
> thoughts?
> Steve
>
>
>
> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
> wrote:
>
>> Hi Steve,
>>
>> As of right now, it’s supporting only 40col mode.
>>
>> Currently, the way I am taking advantage of the DVI and T200 larger
>> displays are to have the Controls/Help screen displayed below the game
>> screen (preventing the need to switch between the two)
>>
>> As others have mentioned, I could allow for an actual larger
>> minefield. However, at this time, I don’t have plans for that.
>>
>> My primary goals in the short terms are to improve the base game
>> experience, which in my mind is oriented around the M100, as well as to
>> ensure that same experience is achieved on the T200 and DVI.
>>
>> If I were to support 80-col mode at this time, I would basically just
>> end up leaving the right hand 40 columns empty.
>>
>> The next few things I’m working on:
>> 1. Reduce size of TSWEEP.BA in memory
>> 2. Compact some of the array vars I’m using to require less RAM.
>> 3. Add a few different pre-canned difficulty level aside from the
>> Standard/Custom I have today.
>> 4. Increase performance of the screen redrawing routine.
>> 5. Increase overall performance of the DFS algorithm when revealing
>> mines.
>>
>> Best,
>> George
>>
>> On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
>> wrote:
>>
>>> George,
>>> for DVI use, is that intended for 40 columns?
>>> Is there a way you could put in a switch to enable 80 column mode?
>>>
>>> thx
>>> steve
>>>
>>> On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com <
>>> grima...@gmail.com> wrote:
>>>
 Hi all,

 As previously mentioned, I have been working on Text Sweeper again.
 I've made a bunch of changed behind the scenes, but the things that 
 will be
 

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

[image: ResizerImage574X765.jpg]
yes,
I have done a lot of work on making an external 80column video solution
that is a  "DVI work alike" accessible without actually having a DVI.

First you need some driver software on the M100.
1) VT100 driver - found here -->
https://bitchin100.com/wiki/index.php?title=VT100
or
2) via REX#/REXCPM.

To actually show video on an external monitor, the driver software treats
Screen1 as RS-232 and Screen2 as serial via a hardware hack to the BCR
port.   So, an external serial terminal can be used to show the video info.

Then you need a solution for serial terminal.
There are 2
1)  MVT100 video adapter, based on the Geoff VT100 serial terminal board
--> https://bitchin100.com/wiki/index.php?title=VT100
or
2) the MVT100 windows application found here -->
http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;

Anyhow, I find external video quite nice to have but I never appreciated
the DVI much myself.  Had 2, sold them both.




On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
wrote:

> I see, when you say your DVI software do you mean the software that
> emulates the DVI itself?
>
> Modifying the print statements is definitely doable, and I can add that to
> my TODOs.
>
> However, as someone who uses the DVI, I personally do like the 40 column
> mode. Being able to switch between 40 and 80 col on demand is useful in my
> opinion. Very similar to how the Apple II works: 40col is just more legible
> in a lot of situations.
>
> -George
>
> On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
> wrote:
>
>> my stuff doesn't support 40 columns.  that's why I was asking!
>> To me, 40 column mode on the DVI seems silly, but that's just me.
>>
>> Anyways, if you don't want to adapt the print@ statements, I get it.
>> thanks anyways.
>>
>>
>> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
>> wrote:
>>
>>> I think the way I would prefer to handle it would be to check the
>>> initial setting of 40/80 when the program starts, switch the screen to 40,
>>> and then switch back on exit.
>>>
>>> Do you know is there a way to switch to 40 columns mode without calling
>>> WIDTH? I assume if I use any keywords exclusive to Disk Basic it will break
>>> compatibility with regular Basic.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
>>> wrote:
>>>
 George,
 I think it would be fine to use only 40 columns.
 just make it tolerate 80 cols wide.
 (all of my DVI software assumes 80 columns).
 thoughts?
 Steve



 On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
 wrote:

> Hi Steve,
>
> As of right now, it’s supporting only 40col mode.
>
> Currently, the way I am taking advantage of the DVI and T200 larger
> displays are to have the Controls/Help screen displayed below the game
> screen (preventing the need to switch between the two)
>
> As others have mentioned, I could allow for an actual larger
> minefield. However, at this time, I don’t have plans for that.
>
> My primary goals in the short terms are to improve the base game
> experience, which in my mind is oriented around the M100, as well as to
> ensure that same experience is achieved on the T200 and DVI.
>
> If I were to support 80-col mode at this time, I would basically just
> end up leaving the right hand 40 columns empty.
>
> The next few things I’m working on:
> 1. Reduce size of TSWEEP.BA in memory
> 2. Compact some of the array vars I’m using to require less RAM.
> 3. Add a few different pre-canned difficulty level aside from the
> Standard/Custom I have today.
> 4. Increase performance of the screen redrawing routine.
> 5. Increase overall performance of the DFS algorithm when revealing
> mines.
>
> Best,
> George
>
> On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
> wrote:
>
>> George,
>> for DVI use, is that intended for 40 columns?
>> Is there a way you could put in a switch to enable 80 column mode?
>>
>> thx
>> steve
>>
>> On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com <
>> grima...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> As previously mentioned, I have been working on Text Sweeper again.
>>> I've made a bunch of changed behind the scenes, but the things that 
>>> will be
>>> noticeable to you:
>>>
>>>
>>>- Slight graphical changes.
>>>- Better mine generation for denser minefield.
>>>- Controls can be seen by pressing H
>>>- WASD is supported as an alternative to the arrow keys.
>>>- You cannot accidentally click a flagged cell.
>>>- If you click a cell with a Number. If the flags surrounding
>>>that cell equal the number, it will open the non flagged cells (Be 
>>> careful
>>>:D )
>>>- If you accidentally press LABEL, the screen will 

Re: [M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

I see, when you say your DVI software do you mean the software that
emulates the DVI itself?

Modifying the print statements is definitely doable, and I can add that to
my TODOs.

However, as someone who uses the DVI, I personally do like the 40 column
mode. Being able to switch between 40 and 80 col on demand is useful in my
opinion. Very similar to how the Apple II works: 40col is just more legible
in a lot of situations.

-George

On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph  wrote:

> my stuff doesn't support 40 columns.  that's why I was asking!
> To me, 40 column mode on the DVI seems silly, but that's just me.
>
> Anyways, if you don't want to adapt the print@ statements, I get it.
> thanks anyways.
>
>
> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
> wrote:
>
>> I think the way I would prefer to handle it would be to check the initial
>> setting of 40/80 when the program starts, switch the screen to 40, and then
>> switch back on exit.
>>
>> Do you know is there a way to switch to 40 columns mode without calling
>> WIDTH? I assume if I use any keywords exclusive to Disk Basic it will break
>> compatibility with regular Basic.
>>
>> Best,
>> George
>>
>> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
>> wrote:
>>
>>> George,
>>> I think it would be fine to use only 40 columns.
>>> just make it tolerate 80 cols wide.
>>> (all of my DVI software assumes 80 columns).
>>> thoughts?
>>> Steve
>>>
>>>
>>>
>>> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
>>> wrote:
>>>
 Hi Steve,

 As of right now, it’s supporting only 40col mode.

 Currently, the way I am taking advantage of the DVI and T200 larger
 displays are to have the Controls/Help screen displayed below the game
 screen (preventing the need to switch between the two)

 As others have mentioned, I could allow for an actual larger minefield.
 However, at this time, I don’t have plans for that.

 My primary goals in the short terms are to improve the base game
 experience, which in my mind is oriented around the M100, as well as to
 ensure that same experience is achieved on the T200 and DVI.

 If I were to support 80-col mode at this time, I would basically just
 end up leaving the right hand 40 columns empty.

 The next few things I’m working on:
 1. Reduce size of TSWEEP.BA in memory
 2. Compact some of the array vars I’m using to require less RAM.
 3. Add a few different pre-canned difficulty level aside from the
 Standard/Custom I have today.
 4. Increase performance of the screen redrawing routine.
 5. Increase overall performance of the DFS algorithm when revealing
 mines.

 Best,
 George

 On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
 wrote:

> George,
> for DVI use, is that intended for 40 columns?
> Is there a way you could put in a switch to enable 80 column mode?
>
> thx
> steve
>
> On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
> wrote:
>
>> Hi all,
>>
>> As previously mentioned, I have been working on Text Sweeper again.
>> I've made a bunch of changed behind the scenes, but the things that will 
>> be
>> noticeable to you:
>>
>>
>>- Slight graphical changes.
>>- Better mine generation for denser minefield.
>>- Controls can be seen by pressing H
>>- WASD is supported as an alternative to the arrow keys.
>>- You cannot accidentally click a flagged cell.
>>- If you click a cell with a Number. If the flags surrounding
>>that cell equal the number, it will open the non flagged cells (Be 
>> careful
>>:D )
>>- If you accidentally press LABEL, the screen will fix itself
>>
>> Everything is on github.
>> https://github.com/Grimakis/TextSweeper
>>
>> There are probably still a ton of bugs I didn't find, so let me know
>> if you find any.
>>
>> Enjoy,
>> George
>>
>

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

Textsweeper was going to be my fun to use test case to make sure my DVI
emulator code for windows was working well.

Since the only drivers that send video data over serial are my own 2
programs (1 = VT100 driver for M100 or 2 = REX#/REXCPM) and since those
adaptations of the Disk Video Interface driver code ignores the 40 column
mode, there is no matching need on the "terminal" end of the serial link to
support 40 column mode either.

On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph  wrote:

> my stuff doesn't support 40 columns.  that's why I was asking!
> To me, 40 column mode on the DVI seems silly, but that's just me.
>
> Anyways, if you don't want to adapt the print@ statements, I get it.
> thanks anyways.
>
>
> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
> wrote:
>
>> I think the way I would prefer to handle it would be to check the initial
>> setting of 40/80 when the program starts, switch the screen to 40, and then
>> switch back on exit.
>>
>> Do you know is there a way to switch to 40 columns mode without calling
>> WIDTH? I assume if I use any keywords exclusive to Disk Basic it will break
>> compatibility with regular Basic.
>>
>> Best,
>> George
>>
>> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
>> wrote:
>>
>>> George,
>>> I think it would be fine to use only 40 columns.
>>> just make it tolerate 80 cols wide.
>>> (all of my DVI software assumes 80 columns).
>>> thoughts?
>>> Steve
>>>
>>>
>>>
>>> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
>>> wrote:
>>>
 Hi Steve,

 As of right now, it’s supporting only 40col mode.

 Currently, the way I am taking advantage of the DVI and T200 larger
 displays are to have the Controls/Help screen displayed below the game
 screen (preventing the need to switch between the two)

 As others have mentioned, I could allow for an actual larger minefield.
 However, at this time, I don’t have plans for that.

 My primary goals in the short terms are to improve the base game
 experience, which in my mind is oriented around the M100, as well as to
 ensure that same experience is achieved on the T200 and DVI.

 If I were to support 80-col mode at this time, I would basically just
 end up leaving the right hand 40 columns empty.

 The next few things I’m working on:
 1. Reduce size of TSWEEP.BA in memory
 2. Compact some of the array vars I’m using to require less RAM.
 3. Add a few different pre-canned difficulty level aside from the
 Standard/Custom I have today.
 4. Increase performance of the screen redrawing routine.
 5. Increase overall performance of the DFS algorithm when revealing
 mines.

 Best,
 George

 On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
 wrote:

> George,
> for DVI use, is that intended for 40 columns?
> Is there a way you could put in a switch to enable 80 column mode?
>
> thx
> steve
>
> On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
> wrote:
>
>> Hi all,
>>
>> As previously mentioned, I have been working on Text Sweeper again.
>> I've made a bunch of changed behind the scenes, but the things that will 
>> be
>> noticeable to you:
>>
>>
>>- Slight graphical changes.
>>- Better mine generation for denser minefield.
>>- Controls can be seen by pressing H
>>- WASD is supported as an alternative to the arrow keys.
>>- You cannot accidentally click a flagged cell.
>>- If you click a cell with a Number. If the flags surrounding
>>that cell equal the number, it will open the non flagged cells (Be 
>> careful
>>:D )
>>- If you accidentally press LABEL, the screen will fix itself
>>
>> Everything is on github.
>> https://github.com/Grimakis/TextSweeper
>>
>> There are probably still a ton of bugs I didn't find, so let me know
>> if you find any.
>>
>> Enjoy,
>> George
>>
>

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

my stuff doesn't support 40 columns.  that's why I was asking!
To me, 40 column mode on the DVI seems silly, but that's just me.

Anyways, if you don't want to adapt the print@ statements, I get it.
thanks anyways.


On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
wrote:

> I think the way I would prefer to handle it would be to check the initial
> setting of 40/80 when the program starts, switch the screen to 40, and then
> switch back on exit.
>
> Do you know is there a way to switch to 40 columns mode without calling
> WIDTH? I assume if I use any keywords exclusive to Disk Basic it will break
> compatibility with regular Basic.
>
> Best,
> George
>
> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
> wrote:
>
>> George,
>> I think it would be fine to use only 40 columns.
>> just make it tolerate 80 cols wide.
>> (all of my DVI software assumes 80 columns).
>> thoughts?
>> Steve
>>
>>
>>
>> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
>> wrote:
>>
>>> Hi Steve,
>>>
>>> As of right now, it’s supporting only 40col mode.
>>>
>>> Currently, the way I am taking advantage of the DVI and T200 larger
>>> displays are to have the Controls/Help screen displayed below the game
>>> screen (preventing the need to switch between the two)
>>>
>>> As others have mentioned, I could allow for an actual larger minefield.
>>> However, at this time, I don’t have plans for that.
>>>
>>> My primary goals in the short terms are to improve the base game
>>> experience, which in my mind is oriented around the M100, as well as to
>>> ensure that same experience is achieved on the T200 and DVI.
>>>
>>> If I were to support 80-col mode at this time, I would basically just
>>> end up leaving the right hand 40 columns empty.
>>>
>>> The next few things I’m working on:
>>> 1. Reduce size of TSWEEP.BA in memory
>>> 2. Compact some of the array vars I’m using to require less RAM.
>>> 3. Add a few different pre-canned difficulty level aside from the
>>> Standard/Custom I have today.
>>> 4. Increase performance of the screen redrawing routine.
>>> 5. Increase overall performance of the DFS algorithm when revealing
>>> mines.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
>>> wrote:
>>>
 George,
 for DVI use, is that intended for 40 columns?
 Is there a way you could put in a switch to enable 80 column mode?

 thx
 steve

 On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
 wrote:

> Hi all,
>
> As previously mentioned, I have been working on Text Sweeper again.
> I've made a bunch of changed behind the scenes, but the things that will 
> be
> noticeable to you:
>
>
>- Slight graphical changes.
>- Better mine generation for denser minefield.
>- Controls can be seen by pressing H
>- WASD is supported as an alternative to the arrow keys.
>- You cannot accidentally click a flagged cell.
>- If you click a cell with a Number. If the flags surrounding that
>cell equal the number, it will open the non flagged cells (Be careful 
> :D )
>- If you accidentally press LABEL, the screen will fix itself
>
> Everything is on github.
> https://github.com/Grimakis/TextSweeper
>
> There are probably still a ton of bugs I didn't find, so let me know
> if you find any.
>
> Enjoy,
> George
>

Re: [M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

I think the way I would prefer to handle it would be to check the initial
setting of 40/80 when the program starts, switch the screen to 40, and then
switch back on exit.

Do you know is there a way to switch to 40 columns mode without calling
WIDTH? I assume if I use any keywords exclusive to Disk Basic it will break
compatibility with regular Basic.

Best,
George

On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph  wrote:

> George,
> I think it would be fine to use only 40 columns.
> just make it tolerate 80 cols wide.
> (all of my DVI software assumes 80 columns).
> thoughts?
> Steve
>
>
>
> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
> wrote:
>
>> Hi Steve,
>>
>> As of right now, it’s supporting only 40col mode.
>>
>> Currently, the way I am taking advantage of the DVI and T200 larger
>> displays are to have the Controls/Help screen displayed below the game
>> screen (preventing the need to switch between the two)
>>
>> As others have mentioned, I could allow for an actual larger minefield.
>> However, at this time, I don’t have plans for that.
>>
>> My primary goals in the short terms are to improve the base game
>> experience, which in my mind is oriented around the M100, as well as to
>> ensure that same experience is achieved on the T200 and DVI.
>>
>> If I were to support 80-col mode at this time, I would basically just end
>> up leaving the right hand 40 columns empty.
>>
>> The next few things I’m working on:
>> 1. Reduce size of TSWEEP.BA in memory
>> 2. Compact some of the array vars I’m using to require less RAM.
>> 3. Add a few different pre-canned difficulty level aside from the
>> Standard/Custom I have today.
>> 4. Increase performance of the screen redrawing routine.
>> 5. Increase overall performance of the DFS algorithm when revealing mines.
>>
>> Best,
>> George
>>
>> On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
>> wrote:
>>
>>> George,
>>> for DVI use, is that intended for 40 columns?
>>> Is there a way you could put in a switch to enable 80 column mode?
>>>
>>> thx
>>> steve
>>>
>>> On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
>>> wrote:
>>>
 Hi all,

 As previously mentioned, I have been working on Text Sweeper again.
 I've made a bunch of changed behind the scenes, but the things that will be
 noticeable to you:


- Slight graphical changes.
- Better mine generation for denser minefield.
- Controls can be seen by pressing H
- WASD is supported as an alternative to the arrow keys.
- You cannot accidentally click a flagged cell.
- If you click a cell with a Number. If the flags surrounding that
cell equal the number, it will open the non flagged cells (Be careful 
 :D )
- If you accidentally press LABEL, the screen will fix itself

 Everything is on github.
 https://github.com/Grimakis/TextSweeper

 There are probably still a ton of bugs I didn't find, so let me know if
 you find any.

 Enjoy,
 George

>>>

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

George,
I think it would be fine to use only 40 columns.
just make it tolerate 80 cols wide.
(all of my DVI software assumes 80 columns).
thoughts?
Steve



On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
wrote:

> Hi Steve,
>
> As of right now, it’s supporting only 40col mode.
>
> Currently, the way I am taking advantage of the DVI and T200 larger
> displays are to have the Controls/Help screen displayed below the game
> screen (preventing the need to switch between the two)
>
> As others have mentioned, I could allow for an actual larger minefield.
> However, at this time, I don’t have plans for that.
>
> My primary goals in the short terms are to improve the base game
> experience, which in my mind is oriented around the M100, as well as to
> ensure that same experience is achieved on the T200 and DVI.
>
> If I were to support 80-col mode at this time, I would basically just end
> up leaving the right hand 40 columns empty.
>
> The next few things I’m working on:
> 1. Reduce size of TSWEEP.BA in memory
> 2. Compact some of the array vars I’m using to require less RAM.
> 3. Add a few different pre-canned difficulty level aside from the
> Standard/Custom I have today.
> 4. Increase performance of the screen redrawing routine.
> 5. Increase overall performance of the DFS algorithm when revealing mines.
>
> Best,
> George
>
> On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
> wrote:
>
>> George,
>> for DVI use, is that intended for 40 columns?
>> Is there a way you could put in a switch to enable 80 column mode?
>>
>> thx
>> steve
>>
>> On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
>> wrote:
>>
>>> Hi all,
>>>
>>> As previously mentioned, I have been working on Text Sweeper again. I've
>>> made a bunch of changed behind the scenes, but the things that will be
>>> noticeable to you:
>>>
>>>
>>>- Slight graphical changes.
>>>- Better mine generation for denser minefield.
>>>- Controls can be seen by pressing H
>>>- WASD is supported as an alternative to the arrow keys.
>>>- You cannot accidentally click a flagged cell.
>>>- If you click a cell with a Number. If the flags surrounding that
>>>cell equal the number, it will open the non flagged cells (Be careful :D 
>>> )
>>>- If you accidentally press LABEL, the screen will fix itself
>>>
>>> Everything is on github.
>>> https://github.com/Grimakis/TextSweeper
>>>
>>> There are probably still a ton of bugs I didn't find, so let me know if
>>> you find any.
>>>
>>> Enjoy,
>>> George
>>>
>>

Re: [M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

Hi Steve,

As of right now, it’s supporting only 40col mode.

Currently, the way I am taking advantage of the DVI and T200 larger
displays are to have the Controls/Help screen displayed below the game
screen (preventing the need to switch between the two)

As others have mentioned, I could allow for an actual larger minefield.
However, at this time, I don’t have plans for that.

My primary goals in the short terms are to improve the base game
experience, which in my mind is oriented around the M100, as well as to
ensure that same experience is achieved on the T200 and DVI.

If I were to support 80-col mode at this time, I would basically just end
up leaving the right hand 40 columns empty.

The next few things I’m working on:
1. Reduce size of TSWEEP.BA in memory
2. Compact some of the array vars I’m using to require less RAM.
3. Add a few different pre-canned difficulty level aside from the
Standard/Custom I have today.
4. Increase performance of the screen redrawing routine.
5. Increase overall performance of the DFS algorithm when revealing mines.

Best,
George

On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph  wrote:

> George,
> for DVI use, is that intended for 40 columns?
> Is there a way you could put in a switch to enable 80 column mode?
>
> thx
> steve
>
> On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
> wrote:
>
>> Hi all,
>>
>> As previously mentioned, I have been working on Text Sweeper again. I've
>> made a bunch of changed behind the scenes, but the things that will be
>> noticeable to you:
>>
>>
>>- Slight graphical changes.
>>- Better mine generation for denser minefield.
>>- Controls can be seen by pressing H
>>- WASD is supported as an alternative to the arrow keys.
>>- You cannot accidentally click a flagged cell.
>>- If you click a cell with a Number. If the flags surrounding that
>>cell equal the number, it will open the non flagged cells (Be careful :D )
>>- If you accidentally press LABEL, the screen will fix itself
>>
>> Everything is on github.
>> https://github.com/Grimakis/TextSweeper
>>
>> There are probably still a ton of bugs I didn't find, so let me know if
>> you find any.
>>
>> Enjoy,
>> George
>>
>

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

George,
for DVI use, is that intended for 40 columns?
Is there a way you could put in a switch to enable 80 column mode?

thx
steve

On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
wrote:

> Hi all,
>
> As previously mentioned, I have been working on Text Sweeper again. I've
> made a bunch of changed behind the scenes, but the things that will be
> noticeable to you:
>
>
>- Slight graphical changes.
>- Better mine generation for denser minefield.
>- Controls can be seen by pressing H
>- WASD is supported as an alternative to the arrow keys.
>- You cannot accidentally click a flagged cell.
>- If you click a cell with a Number. If the flags surrounding that
>cell equal the number, it will open the non flagged cells (Be careful :D )
>- If you accidentally press LABEL, the screen will fix itself
>
> Everything is on github.
> https://github.com/Grimakis/TextSweeper
>
> There are probably still a ton of bugs I didn't find, so let me know if
> you find any.
>
> Enjoy,
> George
>

[M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

Hi all,

As previously mentioned, I have been working on Text Sweeper again. I've
made a bunch of changed behind the scenes, but the things that will be
noticeable to you:


   - Slight graphical changes.
   - Better mine generation for denser minefield.
   - Controls can be seen by pressing H
   - WASD is supported as an alternative to the arrow keys.
   - You cannot accidentally click a flagged cell.
   - If you click a cell with a Number. If the flags surrounding that cell
   equal the number, it will open the non flagged cells (Be careful :D )
   - If you accidentally press LABEL, the screen will fix itself

Everything is on github.
https://github.com/Grimakis/TextSweeper

There are probably still a ton of bugs I didn't find, so let me know if you
find any.

Enjoy,
George