[M100] VT100 Emulation and DVi

[grima...@gmail.com]

Hi all,

I recently decided to take my main battle-station (apple iie) out of
service, so I can dedicate more space to my Tandy 102.

What I have found though, is that the Model 100 isn’t quite ideal for
BBSing, even with the DVI. A lot of systems assume VT100 emulation, which
Apple did have.

I tried using VTEMUL, but it assume you are using the the built in screen,
so it doesn’t work properly with the DVI.

The creator of VTEMUL was looking to adapt the program to the DVI according
to this post.

https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-03-TELCOM/VTEMUL.THD

Anyone know if the DVI compatible version exists?

-George

Re: [M100] Text Sweeper 2.7.3

[grima...@gmail.com]

I assumed Josh was referring to all “computers” not just personal computers.

iPhones run iOS which based on Unix(BSD), and Android is based on Linux.

Most Smart TVs and Streaming boxes are running Linux.



On Sat, Nov 25, 2023 at 12:29 PM Walt Perko  wrote:

> Hi,
>
>
>
> The vast number of UNIX/Linux systems is actually servers, not desktop
> computers.
>
>
>
> As for desktop computers, MS Windows is the top of the heap, no other
> platform even comes close to those numbers.
>
>
>
>
>
>
>
>
>
>
> ==
> C U L8r,  °|°  Walt Perko  °|°"Kids ... teach them the good stuff,
> and they still learn the bad stuff on their own."
>
> http://www.R2Pv1.com/   *RoboGuts™ Intelligent
> content for 3D printing making S.T.E.A.M. education better, easier and more
> affordable  *
>
>
>
> Experiments to learn how to use various Electronic Components, Structured
> Computer Programming, Phonemes for Speech  in any language, and Art.
>
>
>  "The World Needs a New Economic Model"
>
> ==
>
> [image: BillyBotAvatar-2centsStamp-c]
>
> Sent from the Cyber7
>
>
>
>
>
> *From:* M100 *On Behalf Of *Joshua O'Keefe
> *Sent:* Saturday, November 25, 2023 9:10 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Text Sweeper 2.7.3
>
>
>
> On Nov 25, 2023, at 6:24 AM, ho collo  wrote:
>
>
>
> Yes Ken — A majority of the world still uses windows. What would make you
> think otherwise?
>
>
>
> The vast majority of the planet runs on Unix-like platforms.  Windows is
> pretty much only popular on desktops, which are a tiny fraction of the
> computers people own or use on a daily basis in the modern world.
>
>
>
> John was kind enough to create CloudT (see http://bitchin100.com/CloudT )
> for the convenience of people who don't want to compile and install
> VirtualT for their platform, or who wish to access an emulated system
> quickly and easily.
>
>
>
> I'm happy to report that Text Sweeper 2.7.3 seems to run like a dream on
> it!
>

[M100] Text Sweeper 2.7.3

[grima...@gmail.com]

Hi all,

Happy Thanksgiving to all those who may be located in the US and celebrated!

I just wanted to share that since last year, I have done a bit more work on
Text Sweeper (Model 100 Minesweeper Clone), and have published a new
release to GitHub.

https://github.com/Grimakis/TextSweeper/releases/tag/2.7.3

I have added a few changes since I last posted to the list, but the major
ones are:
1. Using an ML subroutine to switch between the game screen and help
screen. (way faster than the prior version)
2. Requiring less memory to run(approx 1KB less), by using ALTLCD as my
stack space for the search algorithm, switching to LIFO, and changing the
XY coordinate data structure from 4 bytes to 2 bytes.

As a reminder, the game is compatible with the M100, T102, T200, and the
DVI in both 40 and 80 col mode.

-George

P.S. Has anyone had issues with Virtual T on Windows 10? the Memory Viewer
window no longer appears for me. It's made a little harder to debug whilst
coding. If anyone has any ideas, let me know.

Re: [M100] Adding Gotek to T100 Disk Video Interface

[grima...@gmail.com]

You beat me to it!

I was just setting up a git repo of the files I used and got working.

https://github.com/Grimakis/Tandy-DVI-Gotek/tree/main

One thing I will note, without adding a cskew=1 in my IMG file, I did not
get it to work.



On Mon, May 8, 2023 at 7:09 AM Josh Malone  wrote:

> I recently converted a DVI for Tandy collector. There was a fellow on this
> list (I think) who had compatible images but in the end, the collector I
> was doing the conversion for supplied working images on a drive. I've
> posted it here:
>
>
> https://drive.google.com/file/d/1cfH6ro03RoDosoi5P2CNwRaErn-vftOV/view?usp=share_link
>
> The image, however, is only part of the trick: you also need lines in
> FF.CFG and IMG.CFG (You are running "FlashFloppy" on your Gotek, right?)
>
> FF.CFG:
>
> interface = ibmpc
> host = unspecified
> pin02 = nc
> pin34 = nc
>
>
> And IMG.CFG:
> [m100dvi]
> cyls=40
> heads=1
> secs=18
> bps=256
> h=0
>
> Then make sure all your DVI images use filenames ".m100dvi.img"
> so that they pick up the geometry from IMG.CFG.
>
> Good luck!
>
> -Josh
>
>
> On Mon, May 8, 2023 at 6:50 AM Gary Wilkinson 
> wrote:
>
>> Hi, This is the first time I've used a mailing list, so appologies if
>> I've not done it correctly! I've been trying and failing to add a gotek to
>> a DVI. Has anyone achieved this, and if so could you give me some pointers?
>> I think one of the main issues is that I don't have a disk image. I tried
>> to convert the DVI.TD0 disk image on the Club 100 library to a .IMG file
>> without success.
>>
>

Re: [M100] Self Modifying Machine Language in BASIC

[grima...@gmail.com]

Something like this:

 PUSH H ; Save HL from BASIC
 CALL HH ; Call HideyHole Routine


 LXI H, 2020H ; First JMP Address to Update
 MVI A, 10H; offset to accumulator
 ADD E ; add CALL address to offset
 MOV M, A ; save lower byte new address
 INX H
 MVI A, 0 ; get rdy to add carry bit
 ACI D ; add carry bit
 MOV M, A ; save upper byte new address



 ; Repeat for as many jump addresses
 ; that you have in the remainder

 POP H ; retrieve original HL value

; Rest of program goes here


   ; stored in your hidey hole
HH: DAD SP
   MOV E,L
   MOV D,H
   RET

On Tue, Mar 7, 2023 at 10:16 AM grima...@gmail.com 
wrote:

> Thanks for the info Ken.
>
> That does seem more expensive as you will be executing the relative jump
> routine every time you want to JMP. In my case, I will likely be using JMP
> as a way to loop. so it would likely impact performance.
>
> My initial thought was rather than do a relative jump in the program
> itself, have the first step of the program modify all of the JMP addresses
> used in that program specifically. Is that something you have tried at all?
>
> -George
>
> On Tue, Mar 7, 2023 at 9:42 AM Kenneth Pettit  wrote:
>
>> Hi George,
>>
>> Yes, using CALL is the way to perform relative jumps in your ML
>> program.  The idea is this:
>>
>> Poke a helper function into a hidey hole (on M100 there is a nice 52
>> byte location you can use for this that I will explain).  So the way to
>> do a relative jump is to add your jump distance as a data byte after the
>> CALL:
>>
>> CALL myRelJump ; Relative jump the distance in the next two
>> bytes (or one if you want)
>> DW  0xFFE5 ; Jump -27 (signed jump)
>>
>> Then at myRelJump you would do something like (not tested, you will have
>> to play with it):
>>
>> PUSH H ; Save HL.  Also modifies SP
>> PUSH D ; Save DE.
>> PUSH B
>> LXI  H,FFFAH   ; Load HL with -8
>> DAD SP ; HL now has the Stack location of the return address
>> (i.e. points to your relative jump distance)
>> MOV E,L; Save stack location in DE
>> MOV D,H
>> LHLX   ; Undocumented opcode to load HL from (DE) ... HL now
>> points to your ML program
>> MOV C,M; Get LSB of the relative jump distance
>> INX H  ; Point to MSB
>> MOV B,M; Get MSB of relative jump distance
>> DAD B  ; Add the offset to the PC location (in HL) of the
>> program
>> SHLX   ; Undocumentd opcode to save HL at (DE) ... save new
>> return address to stack
>> POP B
>> POP D
>> POP H
>> RET; This now returns to the new location you just
>> calculated
>>
>> Note that is will be SLOWER ... you are executing 17 opcodes for each
>> jump instead of one!!
>>
>> The hidey hole I was talking about is an array used only by the TEXT
>> application.  It saves 26 2-byte pointers (one for each line of the LCD
>> / DVI, plus an extra containing 0x) to indicate the location in the
>> edited .DO file of the start of that line.  I call it the "line starts
>> array".  When runing BASIC, this memory region is unused and can be
>> poked with any ML you want.  On M100, this is at address F6EBH.
>>
>> Hope this helps.  Again, this is UNTESTED code, but should give you the
>> idea.
>> Ken
>>
>> On 3/7/23 4:44 AM, grima...@gmail.com wrote:
>> > Hi all,
>> >
>> > One of the things I struggled with in trying to build 8085 subroutines
>> > for BASIC program was the lack of a relative jump command.
>> >
>> > So far, the approach I have taken to embed ML programs into BASIC has
>> > been to poke them into arrays, thus allowing BASIC to manage the
>> > routines within memory. However, I then have to use BASIC to get
>> > VARPTR of the array and update all JMP locations before calling the
>> > subroutine, just in case BASIC has moved the array.
>> >
>> > The other thought I had was, can I have the ML program modify itself
>> > when it runs? I was racking my brain reading the Inten 8085
>> > documentation, and as far as I can tell there is no easy way to read
>> > the program counter into any of the register pairs, which I would want
>> > to do in order to calculate offsets and update JMP locations.
>> >
>> > However I had one thought. It seems that both CALL and RST
>> > instructions push the program counter onto the stack. Is it possible
>> > to leverage either of these and then RET to return to my program, and
>> > then immediately decrement the stack pointer and to retrieve the
>> > previous value.
>> >
>> > Then I can use that value to calculate all the offsets and update the
>> > JMP locations.
>> >
>> > Does anyone have any constructive input here?
>> >
>> > -George
>>
>>

Re: [M100] Self Modifying Machine Language in BASIC

[grima...@gmail.com]

Thanks for the info Ken.

That does seem more expensive as you will be executing the relative jump
routine every time you want to JMP. In my case, I will likely be using JMP
as a way to loop. so it would likely impact performance.

My initial thought was rather than do a relative jump in the program
itself, have the first step of the program modify all of the JMP addresses
used in that program specifically. Is that something you have tried at all?

-George

On Tue, Mar 7, 2023 at 9:42 AM Kenneth Pettit  wrote:

> Hi George,
>
> Yes, using CALL is the way to perform relative jumps in your ML
> program.  The idea is this:
>
> Poke a helper function into a hidey hole (on M100 there is a nice 52
> byte location you can use for this that I will explain).  So the way to
> do a relative jump is to add your jump distance as a data byte after the
> CALL:
>
> CALL myRelJump ; Relative jump the distance in the next two
> bytes (or one if you want)
> DW  0xFFE5 ; Jump -27 (signed jump)
>
> Then at myRelJump you would do something like (not tested, you will have
> to play with it):
>
> PUSH H ; Save HL.  Also modifies SP
> PUSH D ; Save DE.
> PUSH B
> LXI  H,FFFAH   ; Load HL with -8
> DAD SP ; HL now has the Stack location of the return address
> (i.e. points to your relative jump distance)
> MOV E,L; Save stack location in DE
> MOV D,H
> LHLX   ; Undocumented opcode to load HL from (DE) ... HL now
> points to your ML program
> MOV C,M; Get LSB of the relative jump distance
> INX H  ; Point to MSB
> MOV B,M; Get MSB of relative jump distance
> DAD B  ; Add the offset to the PC location (in HL) of the
> program
> SHLX   ; Undocumentd opcode to save HL at (DE) ... save new
> return address to stack
> POP B
> POP D
> POP H
> RET; This now returns to the new location you just
> calculated
>
> Note that is will be SLOWER ... you are executing 17 opcodes for each
> jump instead of one!!
>
> The hidey hole I was talking about is an array used only by the TEXT
> application.  It saves 26 2-byte pointers (one for each line of the LCD
> / DVI, plus an extra containing 0x) to indicate the location in the
> edited .DO file of the start of that line.  I call it the "line starts
> array".  When runing BASIC, this memory region is unused and can be
> poked with any ML you want.  On M100, this is at address F6EBH.
>
> Hope this helps.  Again, this is UNTESTED code, but should give you the
> idea.
> Ken
>
> On 3/7/23 4:44 AM, grima...@gmail.com wrote:
> > Hi all,
> >
> > One of the things I struggled with in trying to build 8085 subroutines
> > for BASIC program was the lack of a relative jump command.
> >
> > So far, the approach I have taken to embed ML programs into BASIC has
> > been to poke them into arrays, thus allowing BASIC to manage the
> > routines within memory. However, I then have to use BASIC to get
> > VARPTR of the array and update all JMP locations before calling the
> > subroutine, just in case BASIC has moved the array.
> >
> > The other thought I had was, can I have the ML program modify itself
> > when it runs? I was racking my brain reading the Inten 8085
> > documentation, and as far as I can tell there is no easy way to read
> > the program counter into any of the register pairs, which I would want
> > to do in order to calculate offsets and update JMP locations.
> >
> > However I had one thought. It seems that both CALL and RST
> > instructions push the program counter onto the stack. Is it possible
> > to leverage either of these and then RET to return to my program, and
> > then immediately decrement the stack pointer and to retrieve the
> > previous value.
> >
> > Then I can use that value to calculate all the offsets and update the
> > JMP locations.
> >
> > Does anyone have any constructive input here?
> >
> > -George
>
>

[M100] Self Modifying Machine Language in BASIC

[grima...@gmail.com]

Hi all,

One of the things I struggled with in trying to build 8085 subroutines for
BASIC program was the lack of a relative jump command.

So far, the approach I have taken to embed ML programs into BASIC has been
to poke them into arrays, thus allowing BASIC to manage the routines within
memory. However, I then have to use BASIC to get VARPTR of the array and
update all JMP locations before calling the subroutine, just in case BASIC
has moved the array.

The other thought I had was, can I have the ML program modify itself when
it runs? I was racking my brain reading the Inten 8085 documentation, and
as far as I can tell there is no easy way to read the program counter into
any of the register pairs, which I would want to do in order to calculate
offsets and update JMP locations.

However I had one thought. It seems that both CALL and RST instructions
push the program counter onto the stack. Is it possible to leverage either
of these and then RET to return to my program, and then immediately
decrement the stack pointer and to retrieve the previous value.

Then I can use that value to calculate all the offsets and update the JMP
locations.

Does anyone have any constructive input here?

-George

Re: [M100] Removing DVI Disk Basic

[grima...@gmail.com]

Just tried out BOOT.BA and it works pretty well. Only thing I don't love
about it, is that you need to re-enter the Time/Date after removing
Disk-BASIC.

I think I'm going to modify it to store the current date/time in ALTLCD
before clearing the ram, as I think that location ought to be protected.

-George

On Thu, Mar 2, 2023 at 9:48 AM Brian K. White  wrote:

> I never noticed that, but I just tried it and you're right, the dvi
> needs the system disk on every power-on, not just for installation.
>
> --
> bkw
>
> On 3/2/23 09:20, grima...@gmail.com wrote:
> > I guess the need to pack the Disk BASIC away is pretty limited, since
> > when the DVI starts up, it loads software into it's RAM from the system
> > disk, the same disk which you can use to load Disk BASIC to the M100. So
> > even if you were to pack and reload Disk BASIC, the DVI will be useless
> > without the system disk. (unless there is a way to load the DVI software
> > into the DVI from the System Bus connector of the M100.)
> >
> > That would be great if possible, you could bootstrap a DVI without the
> > original disk.
> >
> > -George
> >
> > On Thu, Mar 2, 2023 at 9:11 AM Brian K. White  > <mailto:b.kenyo...@gmail.com>> wrote:
> >
> > On 3/2/23 07:37, grima...@gmail.com <mailto:grima...@gmail.com>
> wrote:
> >  > Hi Brian,
> >  >
> >  > Just reading the descriptions in your link and they seem to be
> > exactly
> >  > what I need.
> >
> > Looks like also D100.BA <http://D100.BA> and DISABL.DVI
> >
> > I would have sworn I saw directions in the user manual, but I don't
> see
> > anything like that now.
> >
> > There may be yet other programs or texts elsewhere in the m100sig
> > besides these too.
> >
> > I thought I saw some that don't just unload the dvi software but pack
> > it away for restoring later, and did the same for other dosses like
> for
> > chipmunk or tpdd, and let you flip back & forth between them.
> >
> > Here's something cool, search the entire m100sig using the search
> > box on
> > github:
> >
> >
> https://github.com/LivingM100SIG/Living_M100SIG/search?q=Disk%2FVideo <
> https://github.com/LivingM100SIG/Living_M100SIG/search?q=Disk%2FVideo>
> >
> > Whoa Nelly!
> >
> > --
> > bkw
> >
>
> --
> bkw
>
>

Re: [M100] Removing DVI Disk Basic

[grima...@gmail.com]

I guess the need to pack the Disk BASIC away is pretty limited, since when
the DVI starts up, it loads software into it's RAM from the system disk,
the same disk which you can use to load Disk BASIC to the M100. So even if
you were to pack and reload Disk BASIC, the DVI will be useless without the
system disk. (unless there is a way to load the DVI software into the DVI
from the System Bus connector of the M100.)

That would be great if possible, you could bootstrap a DVI without the
original disk.

-George

On Thu, Mar 2, 2023 at 9:11 AM Brian K. White  wrote:

> On 3/2/23 07:37, grima...@gmail.com wrote:
> > Hi Brian,
> >
> > Just reading the descriptions in your link and they seem to be exactly
> > what I need.
>
> Looks like also D100.BA and DISABL.DVI
>
> I would have sworn I saw directions in the user manual, but I don't see
> anything like that now.
>
> There may be yet other programs or texts elsewhere in the m100sig
> besides these too.
>
> I thought I saw some that don't just unload the dvi software but pack
> it away for restoring later, and did the same for other dosses like for
> chipmunk or tpdd, and let you flip back & forth between them.
>
> Here's something cool, search the entire m100sig using the search box on
> github:
>
> https://github.com/LivingM100SIG/Living_M100SIG/search?q=Disk%2FVideo
>
> Whoa Nelly!
>
> --
> bkw
>
>

Re: [M100] Removing DVI Disk Basic

[grima...@gmail.com]

Hi Brian,

Just reading the descriptions in your link and they seem to be exactly what
I need.

Thank you very much!

Best,
George

On Thu, Mar 2, 2023 at 7:05 AM Brian K. White  wrote:

> On 3/1/23 22:17, grima...@gmail.com wrote:
> > Hi all,
> >
> > The linked document explains how to remove Disk BASIC from memory on a
> T200.
> >
> > https://archive.org/details/DVI263806Notice
> > <https://archive.org/details/DVI263806Notice>
> >
> > Does anyone have the procedure to remove Disk BASIC from an M100?
> >
> > -George
>
>
>
> https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-09-PERIFERALS/DVI.CAT
>
> See at least BOOT.BA and DVI.100
>
>
> https://github.com/LivingM100SIG/Living_M100SIG/tree/main/M100SIG/Lib-09-PERIFERALS
>
>
> --
> bkw
>
>

[M100] Removing DVI Disk Basic

[grima...@gmail.com]

Hi all,

The linked document explains how to remove Disk BASIC from memory on a T200.

https://archive.org/details/DVI263806Notice

Does anyone have the procedure to remove Disk BASIC from an M100?

-George

Re: [M100] DVI + Floppy Emulation

[grima...@gmail.com]

I just want to say, I finally replicated your project Jerry!

Everything works great! The only modification I made was to set cskew=1.
Formatting and writing to disk didn’t work correctly until I did that.

After I got that working, I too switched the drive jumpers and got the DVI
to boot off of the Gotek.

Very happy with the results.

Best,
George

On Mon, May 24, 2021 at 6:14 PM Jeffrey Birt  wrote:

> Great info Jerry!
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Jerry
> Davis
> *Sent:* Monday, May 24, 2021 11:32 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] DVI + Floppy Emulation
>
>
>
> Yes.  I attached one to my DVI a few weeks ago.
>
>
>
> I purchased a Gotek SFR1M44-U100 from Amazon.  The Gotek is a 3.5" drive
> format.  To mount the Gotek into the 5.25" drive bay that the DVI has I
> also purchased the following:
>
>
>
> (1) Startek 3.5" to 5.25" front bay adapter (Amazon)
>
> (1) Kentek 6" adapter from 4-Pin Male Molex 5.25" drive power connector to
> 4-pin Female 3.5" drive power connector (Amazon)
>
> (1) 34-Pin Card Edge to IDC Connector Adapter - 5.25" to 3.5" Floppy Cable
> (eBay)
>
> (1) Gigastone Z90 32GB USB 3.1 Flash Drive (Amazon)
>
>
>
> The flash drive I purchased is very short.  I didn't want a USB drive
> sticking way out from the front because it gets in the way.  32GB is
> massive overkill in terms of space for disk images but that's what was
> available in a small package for a good price.
>
>
>
> I installed the latest version of "flashfloppy" by Keir Fraser (and many
> other contributors) onto the Gotek using the instructions on the
> flashfloppy Githib Wiki.  The Gotek I received had the Artery chip
> installed which required a special build at first but I believe is now
> supported on the newest builds.  I saw a note on the flashfloppy discussion
> board that folks were having fewer problems with Artery-based Gotek drives
> when using flash drives supporting USB 3.1.  That's why I made sure I
> bought a USB drive with USB 3.1.  That may be the standard today so getting
> USB 3.1 may be unavoidable.
>
>
>
> I loaded the flashfloppy software onto the Gotek using the instructions
> and Youtube links contained in the flashfloppy Github Wiki.  Some Gotek
> hardware versions have to be programmed with a USB-to-TTL cable attached to
> header pins you soldered to the Gotek board, other hardware versions could
> be programmed using only a USB-to-USB cable.  The Gotek hardware is subject
> to change so be sure to check the Wiki for the hardware version you
> receive.  There is a lot of information on Gotek programming and hardware
> upgrades that will help get you going on Youtube.
>
>
>
> To start, I kept the original 180K floppy installed as Drive 0 and the
> Gotek installed as Drive 1.  I copied the DOS system disk over to the Gotek
> and then reversed the drives.  My DVI now boots from the Gotek, and the
> physical floppy drive is available for creating floppy images from physical
> media.  Switching between the system disk and an application disk is done
> by pushing the image selector buttons and cycling through the images on the
> flash drive.
>
>
>
> The hardware upgrades available for the Gotek include adding an LCD
> display and a rotary encoder.  I didn't do any of these as I wanted to make
> sure I could get the stock Gotek running before attempting any
> modifications.  I may go back to these at a later date.
>
>
>
> My FF.CFG which configures flashfloppy features is mostly stock and
> contains the following entries:
>
>
>
> interface = ibmpc
> host = unspecified
> pin02 = nc
> pin34 = nc
> write-protect = no
> side-select-glitch-filter = 0
> track-change = instant
> write-drain = instant
> index-suppression = yes
> head-settle-ms = 12
> motor-delay = ignore
> chgrst = step
> ejected-on-startup = no
> image-on-startup = last
> display-probe-ms = 3000
> autoselect-file-secs = 2
> autoselect-folder-secs = 2
> folder-sort = always
> sort-priority = folders
> nav-mode = default
> nav-loop = yes
> twobutton-action = zero
> rotary = none
> indexed-prefix = "DSKA"
> display-type = auto
> oled-font = 6x13
> oled-contrast = 143
> display-order = default
> display-off-secs = 60
> display-on-activity = yes
> display-scroll-rate = 200
> display-scroll-pause = 2000
> nav-scroll-rate = 80
> nav-scroll-pause = 300
> step-volume = 10
> da-report-version = ""
> extend-image = yes
>
>
>
> My IMG.CFG file which defines the cylinders, heads, and sectors for the
> 180K disk format used by the DVI looks like:
>
>
>
> [*.m100dvi.img]
> cyls=40
> heads=1
> secs=18
> bps=256
> h=0
>
>
>
> The configuration above works for me but could probably be tuned for
> better performance.  I was able to format virtual disk images, write files
> to the images, and read files from the images with no issues.  The DVI DOS
> copy and backup utilities all worked as expected.
>
>
>
> Hope this helps you.
>
>
>
> Jerry
>
>
>
>
>
> On Sun, May 23, 2021, 7:21 AM Dan Eicher  wrote:
>
> Anyone using 

Re: [M100] - Backpack

[grima...@gmail.com]

When you load a file through COM, I don’t think  the file information is
passed at all. The Model 100 expects ASCII and tokenizes it on the fly.

Try sending an actual tokenized program over COM and it will fail I believe.

Could be wrong through

On Wed, Mar 1, 2023 at 9:20 AM  wrote:

> I also tried loading a .DO named as .BA through BASIC, i.e. load
> "com:98n1e" and that worked fine. Seems to me that if it were a man ROM
> issue the same problem would happen this way. Also, the TS-DOS disassembly
> shows that it changes it’s behavior based on filetype extension.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Brian
> White
> *Sent:* Wednesday, March 1, 2023 6:51 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] - Backpack
>
>
>
> I don't think it's ts-dos, it's the main rom. The main rom and all the
> tpdd clients basically have to trust the file name. If it's declared as a
> .ba, then the bytes are copied verbatim and then later interpreted
> according to the rules of parsing a .ba. If the contents are not .ba,
> kablooey.
>
> bkw
>
>
>
> On Tue, Feb 28, 2023, 8:11 PM  wrote:
>
> I did some more testing and discovered that John is absolutely correct.
> Previously when I had tried to load a .BA which was really a .DO it made it
> about 3-4 line in and then stopped. This led me to believe it was an issue
> I have seen on other computer; when loading an ASCII file over serial the
> computer will tokenize the line when the CR is encountered. Just like it
> had been typed in on the keyboard. For these systems you have to add a 2
> second or so delay after each line to allow for tokenization.
>
> TSDOS does its own thing, like John says, and really makes a mess of it.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *John R.
> Hogerhuis
> *Sent:* Saturday, February 25, 2023 7:40 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] - Backpack
>
>
>
> A side note but the reason files misnamed as BA cause a problem is that
> tsdos will load them into the BASIC program region verbatim and  treat the
> ASCII bytes as parts of binary formatted line numbers and tokens among
> other problems, ultimately causing a corrupted RAM file system.
>
>
>
> It was the convention on the old Club100 library  to name them this way
> but it's now a bad practice.
>
>
>
> -- John.
>
>
>
>
>
>
>
> On Sat, Feb 25, 2023, 5:30 PM  wrote:
>
> Yes, someone already wrote such a program and shared it. If you just got a
> Backpack Drive Plus it is already on the SD card. You can also download it
> from: https://github.com/Jeff-Birt/Backpack/tree/main/User_Programs
>
>
>
>

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
> <https://www.dabeaz.com/ply/ply.html>, 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
> <http://mailto: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 <https://github.com/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

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

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, F

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 nex

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

[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

[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] M100 LCD repair video and alternative use for unused screen RAM

[grima...@gmail.com]

Just noting here, I pushed Text Sweeper 2.5.0 yesterday.

Minor changes:
-Support for DVI Screen 1
-Exit to Menu instead of Basic.

On Sat, Feb 25, 2023 at 3:37 PM Philip Avery  wrote:

> Correct Mike, a 1950 Land Rover. This one:
>
>
>
> Philip
>
> On 26/02/2023 8:07 am, MikeS wrote:
>
> 
>
> Knowing Philip, more likely a Land Rover or a Jeep ;-)
>
> - Original Message -
> *From:* B 9 
> *To:* m...@bitchin100.com
> *Sent:* Saturday, February 25, 2023 4:01 AM
> *Subject:* Re: [M100] M100 LCD repair video and alternative use for
> unused screen RAM
>
>
> On Fri, Feb 24, 2023 at 1:21 PM Philip Avery  wrote:
>
>> My excuse is I was commissioned to
>> do a vintage vehicle restoration which has soaked up all my spare time
>> for the last 2-years.
>
>
> Vintage vehicles are fun, too. This wouldn't happen to have been a Model
> T, would it?
>
> The good news is I'm almost complete & I expect
>> within a few months to get my vintage computing time back & be able to
>> resolve any M100 CP/M issues & add new features...
>
>
> Yay!
>
> —b9
>
>
>

Re: [M100] Possible BBS launch

[grima...@gmail.com]

Hi Jesse,

Do you happen to have any more details on your setup?

I suppose in an ideal world, I’d like a setup that I can dial out from my
rotary phone, and a second line that I could dial in to a modem.

How difficult does that sound? I tried to use MagicJack previously but the
compression codex they use doesn’t play well with data transfer.

On Sun, Feb 26, 2023 at 8:11 AM Jesse Lafleur  wrote:

> I can provide bell 103 compatible 100% online dial-in access to linux
> servers/services using voip/asterisk/etc. I use my m100 to dial into my
> local home pbx server, and ive even tried it over the web!
>
> On Sun, Feb 26, 2023 at 7:44 AM grima...@gmail.com 
> wrote:
>
>> What are the odds that any of these BBSes would allow dialing in from a
>> real phone line?
>>
>> There is a Commodore 64 BBS out there called BorderlineBBS that has a
>> hybrid Telnet/Dial-Up interface.
>>
>> I managed to use the acoustic couplers to dial in once from the Model T,
>> but ever since switching to VOIP I wasn’t able to get it to work.
>>
>> I really always loved BBSing, so I would be in full support of using a
>> Model T focused BBS.
>>
>> -George
>>
>> On Sun, Feb 26, 2023 at 7:30 AM Ben Strewens  wrote:
>>
>>> On 2023-02-26 4:50 a.m., Daniel L wrote:
>>>
>>> I'm considering a specialized launch of a BBS catering to the modelT
>>> community. Any good boards out there already doing this that I can peruse?
>>>
>>> Daniel
>>>
>>> I'm currently working on one that will support multiple systems,
>>> including the model 100. I'm aiming for going all the way down to the Epson
>>> HX-20, but we'll see how that pans out. It won't be up and running for a
>>> while yet. We're supposed to get a new ISP here this year. The one who
>>> bought out the company I was with closed all my ports and had no clue how
>>> to re-open them, so my BBS got shut down. In the meantime, I figured I'd
>>> work on one that caters to the vintage computer community. I still have
>>> lots of work ahead of me.
>>>
>>

Re: [M100] Possible BBS launch

[grima...@gmail.com]

What are the odds that any of these BBSes would allow dialing in from a
real phone line?

There is a Commodore 64 BBS out there called BorderlineBBS that has a
hybrid Telnet/Dial-Up interface.

I managed to use the acoustic couplers to dial in once from the Model T,
but ever since switching to VOIP I wasn’t able to get it to work.

I really always loved BBSing, so I would be in full support of using a
Model T focused BBS.

-George

On Sun, Feb 26, 2023 at 7:30 AM Ben Strewens  wrote:

> On 2023-02-26 4:50 a.m., Daniel L wrote:
>
> I'm considering a specialized launch of a BBS catering to the modelT
> community. Any good boards out there already doing this that I can peruse?
>
> Daniel
>
> I'm currently working on one that will support multiple systems, including
> the model 100. I'm aiming for going all the way down to the Epson HX-20,
> but we'll see how that pans out. It won't be up and running for a while
> yet. We're supposed to get a new ISP here this year. The one who bought out
> the company I was with closed all my ports and had no clue how to re-open
> them, so my BBS got shut down. In the meantime, I figured I'd work on one
> that caters to the vintage computer community. I still have lots of work
> ahead of me.
>

Re: [M100] - Backpack

[grima...@gmail.com]

Thanks Gary!

Mike - I have TS-DOS in ROM thanks to REX. So after a cold start, I just
need to activate TS-DOS, copy RTC from Backpack, and run it.

Best,
George

On Sat, Feb 25, 2023 at 9:21 PM Gary Weber  wrote:

> Hi George,
>
> Yes you can configure the way the date is represented by your backpack
> sending commands to it when it is in regular serial mode:
> It's on page 37 of the User Manual, and here's a summary:
>
> To switch between 24-hour and 12-hour time format:
> set time 24
> set time ampm
>
> To switch between date formats:
> set date mdy
> set date dmy
> set date ymd
>
> Cheers,
> Gary
>
>
> On Sat, Feb 25, 2023 at 7:16 PM grima...@gmail.com 
> wrote:
>
>> Thank you!
>>
>> I typed it in from GitHub. what I found is my Backpack is setup to reply
>> with dd/mm/.
>>
>> However, Tandy BASIC appears to want the date in mm/dd/. The RTC.BA
>> program seems to assume the date will come back in the correct format.
>>
>> Does the Backpack have a way to configure the output format?
>>
>> In the meantime i altered the program and it works fine!
>>
>> Best,
>> George
>>
>> On Sat, Feb 25, 2023 at 8:30 PM  wrote:
>>
>>> Yes, someone already wrote such a program and shared it. If you just got
>>> a Backpack Drive Plus it is already on the SD card. You can also download
>>> it from: https://github.com/Jeff-Birt/Backpack/tree/main/User_Programs
>>>
>>>
>>>
>>> There is an MT version and NEC version. Note that while these have a .BA
>>> extension they are really text files, a.k.a. .DO files. It has been the
>>> convention to give BASIC programs shared as text files the .BA extension
>>> but if you try to load such a file as is BASIC will try to parse it on the
>>> fly and it can’t do so fast enough. The file extension needs to be changed
>>> to .DO. Load it into RAM, go to BASIC and do: LOAD”FILE.DO”. After it loads
>>> do: SAVE”FILE.BA” and it is now a tokenized BASIC file.
>>>
>>> I’ll get these renamed and include the tokenized version in the future
>>> to avoid such confusion.
>>>
>>>
>>>
>>> Jeff Birt
>>>
>>>
>>>
>>> *From:* M100  *On Behalf Of *
>>> grima...@gmail.com
>>> *Sent:* Saturday, February 25, 2023 7:19 PM
>>> *To:* m...@bitchin100.com
>>> *Subject:* Re: [M100] - Backpack
>>>
>>>
>>>
>>> Random question - Does a BASIC program already exist to interface with
>>> the Backpack to set the clock?
>>>
>>>
>>>
>>> I find myself having to Cold start the machine often, but this handy
>>> Backpack has a real time clock in it.
>>>
>>>
>>>
>>> Would be great to run a quick program that interfaces with the Backpack
>>> over serial, issues the TIME, DATE and DAY commands, queries the current
>>> system time and date, calculates the delta and then resets the system clock.
>>>
>>>
>>>
>>> I started to write the program in BASIC, but I admit I don’t know much
>>> about serial communication. I managed to open the COM buffer for output,
>>> send the four CR to wake it. However, I then PRINT “TIME”+chr$(13) after
>>> that, close the buffer, reopen it for input and then try to get the result.
>>>
>>>
>>>
>>> However I only end up with:
>>>
>>>
>>>
>>> C
>>>
>>> #
>>>
>>> T
>>>
>>>
>>>
>>> As if the second PRINT never went through.
>>>
>>>
>>>
>>> So rather than continue to rack my brain, I figured I’d ask if it
>>> already exists.
>>>
>>>
>>>
>>> -George
>>>
>>>
>>>
>>> On Fri, Feb 17, 2023 at 4:44 PM Mike Stein  wrote:
>>>
>>> It might not be that straightforward; the printer port is partially
>>> shared with the keyboard.
>>>
>>>
>>>
>>> On Fri, Feb 17, 2023 at 10:58 AM Alex ... 
>>> wrote:
>>>
>>> Wire a R2R DAC to the printer port and have the M100 play music Covox
>>> style. 
>>>
>>>
>>>
>>> On Wed, Feb 15, 2023, 14:21 Fisher  wrote:
>>>
>>> All it needs in its next version is an 8mm stereo jack, an mp3 player
>>> and some jukebox software for the laptop!
>>>
>>> Too much to wish for? No matter, it’s already a great piece of kit. :-)
>>>
&

Re: [M100] - Backpack

[grima...@gmail.com]

Thank you!

I typed it in from GitHub. what I found is my Backpack is setup to reply
with dd/mm/.

However, Tandy BASIC appears to want the date in mm/dd/. The RTC.BA
program seems to assume the date will come back in the correct format.

Does the Backpack have a way to configure the output format?

In the meantime i altered the program and it works fine!

Best,
George

On Sat, Feb 25, 2023 at 8:30 PM  wrote:

> Yes, someone already wrote such a program and shared it. If you just got a
> Backpack Drive Plus it is already on the SD card. You can also download it
> from: https://github.com/Jeff-Birt/Backpack/tree/main/User_Programs
>
>
>
> There is an MT version and NEC version. Note that while these have a .BA
> extension they are really text files, a.k.a. .DO files. It has been the
> convention to give BASIC programs shared as text files the .BA extension
> but if you try to load such a file as is BASIC will try to parse it on the
> fly and it can’t do so fast enough. The file extension needs to be changed
> to .DO. Load it into RAM, go to BASIC and do: LOAD”FILE.DO”. After it loads
> do: SAVE”FILE.BA” and it is now a tokenized BASIC file.
>
> I’ll get these renamed and include the tokenized version in the future to
> avoid such confusion.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *
> grima...@gmail.com
> *Sent:* Saturday, February 25, 2023 7:19 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] - Backpack
>
>
>
> Random question - Does a BASIC program already exist to interface with the
> Backpack to set the clock?
>
>
>
> I find myself having to Cold start the machine often, but this handy
> Backpack has a real time clock in it.
>
>
>
> Would be great to run a quick program that interfaces with the Backpack
> over serial, issues the TIME, DATE and DAY commands, queries the current
> system time and date, calculates the delta and then resets the system clock.
>
>
>
> I started to write the program in BASIC, but I admit I don’t know much
> about serial communication. I managed to open the COM buffer for output,
> send the four CR to wake it. However, I then PRINT “TIME”+chr$(13) after
> that, close the buffer, reopen it for input and then try to get the result.
>
>
>
> However I only end up with:
>
>
>
> C
>
> #
>
> T
>
>
>
> As if the second PRINT never went through.
>
>
>
> So rather than continue to rack my brain, I figured I’d ask if it already
> exists.
>
>
>
> -George
>
>
>
> On Fri, Feb 17, 2023 at 4:44 PM Mike Stein  wrote:
>
> It might not be that straightforward; the printer port is partially shared
> with the keyboard.
>
>
>
> On Fri, Feb 17, 2023 at 10:58 AM Alex ... 
> wrote:
>
> Wire a R2R DAC to the printer port and have the M100 play music Covox
> style. 
>
>
>
> On Wed, Feb 15, 2023, 14:21 Fisher  wrote:
>
> All it needs in its next version is an 8mm stereo jack, an mp3 player and
> some jukebox software for the laptop!
>
> Too much to wish for? No matter, it’s already a great piece of kit. :-)
>
>
>
> Sean
>
>
>
>
>
> On Feb 14, 2023, at 8:08 PM,  <
> bir...@soigeneris.com> wrote:
>
>
>
> The Backpack was designed by a friend of mine who wishes to remain
> private. He sent me one and I thought it was great and encouraged him to
> make more offering my help. My only part of the design was the case.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *
> grima...@gmail.com
> *Sent:* Tuesday, February 14, 2023 1:15 PM
> *To:* Model 100 Discussion 
> *Subject:* [M100] - Backpack
>
>
>
> Just received my Backpack from Soigeneris. All I have to say, is that I
> really like the design of it all. It’s relatively compact, it matches the
> design of the M100, and it runs on a single AA cell.
>
>
>
> I immediately plugged it in, and got it to work. Pretty much zero
> configuration needed. I’ve already got REX installed so I was able to load
> up TS-DOS and be off to the races.
>
>
>
> Shout out to Soigeneris and to whomever designed and built this device!
>
>
>
> Best,
>
> George
>
>
>
>

Re: [M100] - Backpack

[grima...@gmail.com]

Random question - Does a BASIC program already exist to interface with the
Backpack to set the clock?

I find myself having to Cold start the machine often, but this handy
Backpack has a real time clock in it.

Would be great to run a quick program that interfaces with the Backpack
over serial, issues the TIME, DATE and DAY commands, queries the current
system time and date, calculates the delta and then resets the system clock.

I started to write the program in BASIC, but I admit I don’t know much
about serial communication. I managed to open the COM buffer for output,
send the four CR to wake it. However, I then PRINT “TIME”+chr$(13) after
that, close the buffer, reopen it for input and then try to get the result.

However I only end up with:

C
#
T

As if the second PRINT never went through.

So rather than continue to rack my brain, I figured I’d ask if it already
exists.

-George

On Fri, Feb 17, 2023 at 4:44 PM Mike Stein  wrote:

> It might not be that straightforward; the printer port is partially shared
> with the keyboard.
>
> On Fri, Feb 17, 2023 at 10:58 AM Alex ... 
> wrote:
>
>> Wire a R2R DAC to the printer port and have the M100 play music Covox
>> style. 
>>
>> On Wed, Feb 15, 2023, 14:21 Fisher  wrote:
>>
>>> All it needs in its next version is an 8mm stereo jack, an mp3 player
>>> and some jukebox software for the laptop!
>>> Too much to wish for? No matter, it’s already a great piece of kit. :-)
>>>
>>> Sean
>>>
>>>
>>> On Feb 14, 2023, at 8:08 PM,  <
>>> bir...@soigeneris.com> wrote:
>>>
>>> The Backpack was designed by a friend of mine who wishes to remain
>>> private. He sent me one and I thought it was great and encouraged him to
>>> make more offering my help. My only part of the design was the case.
>>>
>>> Jeff Birt
>>>
>>> *From:* M100  *On Behalf Of *
>>> grima...@gmail.com
>>> *Sent:* Tuesday, February 14, 2023 1:15 PM
>>> *To:* Model 100 Discussion 
>>> *Subject:* [M100] - Backpack
>>>
>>> Just received my Backpack from Soigeneris. All I have to say, is that I
>>> really like the design of it all. It’s relatively compact, it matches the
>>> design of the M100, and it runs on a single AA cell.
>>>
>>> I immediately plugged it in, and got it to work. Pretty much zero
>>> configuration needed. I’ve already got REX installed so I was able to load
>>> up TS-DOS and be off to the races.
>>>
>>> Shout out to Soigeneris and to whomever designed and built this device!
>>>
>>> Best,
>>> George
>>>
>>>
>>>

Re: [M100] DVI character set

[grima...@gmail.com]

Thanks Ken, worked like a charm!

On Sat, Feb 25, 2023 at 5:29 AM B 9  wrote:

> On Fri, Feb 24, 2023 at 12:10 PM Kenneth Pettit 
> wrote:
>
> Or you can look at the active ROWs, COLs addresses
>>
>> M100:
>>ROWS: F63Bh   will be 8 or 25
>>COLS: F63Ch   will be 40 or 80
>>
>> T200:
>>ROWS: EF08H   will be 16 or 25
>>COLS: EF09H   will be 40 or 80
>>
> Ken, that is pretty nifty! Do you know if any other values are ever
> assigned to ROWS or COLS? For example, did the “VIEW 80” Option ROM (which
> showed 60 columns on a Model 100) change COLS to 60?
>
> Also, I’m curious whether that BASIC routine I shared earlier for
> detecting the screen size (?CHR$(27)"Y~~"; : RO=CSRLIN+1: CO=POS(0)+1)
> would have any benefit compared to just reading the values directly.
> Perhaps it might be more portable, but I seem to recall the PC-8201A may
> have had a different name for CSRLIN.
>
> —b9
>

Re: [M100] DVI character set

[grima...@gmail.com]

Random questions.

1. Is there an easy way to identify from BASIC, a computer which is
connected to a DVI.
2. Is there a range of memory that I can access from BASIC that mirrors the
DVI screen contents?

Basically, I've updated Text Sweeper to properly ID the model 200 and check
the right LCD memory locations, but now I am facing a similar issue with
the DVI system.

-George

On Fri, Feb 24, 2023 at 11:04 AM Brian K. White 
wrote:

> nuthin toit
>
> On 2/24/23 09:27, Stephen Adolph wrote:
> > Brian thanks again for posting the ROMs.
> > They dropped directly into my new project unmodified!
> >
> > On Thu, Feb 23, 2023 at 8:36 PM Stephen Adolph  > > wrote:
> >
> > I'm back at this.
> > In the emulator I am working on. Ow, I have to redo the fonts.  I'm
> > free to use whatever I want.
> >
> > So, which one of these fonts is actually used by the dvi?  The 8x8
> > or the 7x8?
> >
> >
> >
> > On Thursday, January 28, 2021, Tom Wilson  > > wrote:
> >
> > Ooh! There are actually two fonts in the 4K ROM
> >
> > Here's the second one
> > image.png
> >
> > This is the same font, but with only 7 bits used. I'm betting
> > this is the same as the internal font on the M100 itself. Here's
> > one of the characters (255) for comparison:
> >
> > Bank 0:
> > image.png
> >
> > Bank 1:
> > image.png
> >
> >
> > Tom Wilson
> > wilso...@gmail.com 
> > (619)940-6311
> >
> >
> >
> > On Thu, Jan 28, 2021 at 4:09 PM Tom Wilson  > > wrote:
> >
> > Hey, the file works with my Commodore font editor!  =)  I'm
> > totally going to add this as an optional font in my terminal
> > emulator.
> >
> > image.png
> >
> >
> >
> > Tom Wilson
> > wilso...@gmail.com 
> > (619)940-6311
> >
> >
> >
> > On Thu, Jan 28, 2021 at 1:53 PM Jim Anderson
> > mailto:jim.ander...@kpu.ca>> wrote:
> >
> >  > -Original Message-
> >  > If you're going to do that much, then I will grab
> > some more pics with a
> >  > better camera and a tripod so my hand isn't moving,
> > and manual focus.
> >  > Maybe even a good straight-on centered shot without
> > glare from the room
> >  > lights. Maybe with manual controls I can get a shot
> > in the dark without
> >  > the text blooming.
> >
> > You know what, I realize that I went straight to that
> > screen photo image because I was looking for a clear
> > image that had my XX pattern in 80-column mode...
> > and it's really not so blurry, but the capture in
> > "Snapshot_20210127_233755.jpg" is sharper and does have
> > the full character set showing.  Even though they're
> > flanked by square brackets I think I can work with it.
> > (the square brackets don't go to the full left and right
> > extent of the character cell, that's why I used X.)
> > Don't worry about going to any trouble for a sharper
> > screen photo.  For my cleanup/rescaling of the original
> > font I've been working off a handheld iphone photo of my
> > monitor.
> >
> > I also whipped something up to display the ROM data as
> > large block pixels for an absolute reference to the
> > original intended shapes so I think I've got everything
> > I need (except time) :)
> >
> >
> >
> >
> >
> >
> >
> >  jim
> >
>
> --
> bkw
>
>

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[grima...@gmail.com]

>
> Is the plan for TSWEEPER to eventually take advantage of the larger
> playing field on the Tandy 200 (and other Model Ts)?
>
Well, I think that definitely would be a great feature, although it's not
something I've started thinking about yet. If I were to go that route, I'd
potentially also want to support the DVI, as it has a very large display to
take advantage of. (and I have one)

Nice. That works much better. I suggest having F8 exit to the Menu since
> that is more typical.
>
> By the way, when the game is over, the screen still says "Exit to
> BASIC [F8]". However, F8 doesn't work at that point.
>
> Also, if one hits "Y" to play again, it takes them to the title screen
> instead of directly playing the game again.
>
I'll look into these for the next version. Should be simple to fix.

 The only change I think would make a huge difference for most people would
> be automatically flagging squares when a player presses space bar on a
> number and it is obvious that all the remaining squares must be flagged.

This one I'm not so sure about. Aside from it not being a feature of
Minesweeper I am not familiar with in other implementations, it potentially
creates some ambiguity for the user about what happens when you click a
number cell. I'd like to think about this one more.

-George


On Fri, Feb 24, 2023 at 4:33 AM B 9  wrote:

> Thanks, Philip. It could be useful for showing digits (and flags) for
> minesweeper! Also, it might be possible to port Sudoku to the Tandy 200.
>
> —b9
>
> On Fri, Feb 24, 2023 at 1:18 AM Philip Avery  wrote:
>
>> Yes, I'm still around. I've uploaded to the Personal Library on
>> Club100.org the source for Sudoku display - SUDISP.DO. I don't know how
>> much use this would be for you as all I was doing was displaying a 9x9 grid
>> on the M100/T102 8-line display. I just rolled my own font for digits 1-9.
>>
>> I've also uploaded the source for HW scroll demo - scroll.asm
>>
>> Philip
>>
>> On 24/02/2023 8:40 pm, B 9 wrote:
>>
>> On Sun, Feb 19, 2023 at 4:06 PM Mike Stein  wrote:
>>
>>> You might also get inspired by Philip Avery's Sudoku program in his
>>> Club100 upload folder.
>>>
>>
>> Unfortunately, it doesn't work at all on my Tandy 200. (I tried both
>> version 3.1 and 4.1).
>>
>> Maybe he'll publish the source...
>>>
>>
>> That'd be nice. Is he still around? It looks like he has a few nifty
>> utilities (like the HW scrolling demo) which are worth archiving somewhere,
>> if he's willing to release the source.
>>
>> —b9
>>
>>
>>

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[grima...@gmail.com]

Just an update for B9.

I changed a few things with Text Sweeper. Not only did I fix the bug where
the T200 won’t stop redrawing the screen, but I officially added support
for the larger screen size.

The bottom half of the screen is used for the controls menu.

The the F8 exit screen now utilizes the right hand pane only, to avoid an
entire redraw of the screen if you select No and return to the game.

The next feature I plan to work on, is three different difficulty settings
to choose from, instead of just the default / custom setting.

On Sun, Feb 19, 2023 at 7:06 PM Mike Stein  wrote:

> You might also get inspired by Philip Avery's Sudoku program in his
> Club100 upload folder.
>
> Maybe he'll publish the source...
>
> m
>
> On Sun, Feb 19, 2023 at 10:16 AM Joshua O'Keefe 
> wrote:
>
>> > On Feb 19, 2023, at 6:58 AM, B 9  wrote:
>> >
>> > TextSweeper could benefit from more rows, which ROM-View 80 doesn't do.
>> Does anyone know if there is a ROM to do that?
>>
>> Ultrascreen100 can do this.  I found my copy in Gary Weber's member
>> upload area.  At 10 lines the font is not beautiful for text, but for a
>> game or a program without close reading on the part of the user it might
>> work out pretty nicely.
>
>

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[grima...@gmail.com]

>
> There is one minor bug, though. You can't win if your last move uses that
> technique.
>
Thank you, will test that again! Seems like a pretty bad bug.

 I figured the behaviour was so weird there had to be a good reason. While
> it may be more complicated to move the mines around after the initial
> click, it might be worth it to avoid giving the user a long hiccup in game
> play.

One of the big changes I made was to precalculate all the mine adjacency
counts immediately after the minefield. So when you see "placing mines",
that's how long it takes to generate the minefield. Then "calculating" is
the step of looping over the mines and generating adjacency counts. This is
why now during the mine revealing process, it's quite faster when you
reveal a number. The heavy lifting was done during the calculation step.
Initial wait for users is higher, but lower wait during play.

The reason I have done it the way I have so far, is it minimizes the
overall wait time for the users. If you generate the mines upfront, you
still have the same wait time for the minefield placement, then you will
have some wait time on first click(to move, likely a few seconds. Then the
calculation step would be much more complex, as I have several
optimizations in the code. Right now, I track each mine's coordinates in a
separate array. This optimization allows for two things. 1) Faster mine
reveal on loss. 2) Faster calculation of Adjacency Counts.

The final reason I'd like to keep the algorithms relatively linear is that
it will be easier for me to rewrite them in assembly and call them from
BASIC. I think I can really decrease the time of some of these still.

 But if the concern is that someone might accidentally hit LABEL, why not
> just send the escape sequence to turn labels off?
>
I tried this, and what would happen is the first time you press LABEL,
it would clear the bottom row, but not print labels. The second time, it
will print the labels. So, I think I'd have to constantly be printing that
control char to disable LABEL, and still need to account for redrawing the
last row(which in fairness would be fast still. Maybe I'm just doing it
wrong.

-George

On Wed, Feb 15, 2023 at 2:34 AM Brian White  wrote:

> There are also font replacements that make more rows & columns on the
> existing lcd by making the glyphs smaller. I forget the name but I think
> one of the option roms has one.
>
> bkw
>
> On Tue, Feb 14, 2023, 8:29 PM B 9  wrote:
>
>> On Tue, Feb 14, 2023 at 6:00 AM grima...@gmail.com 
>> wrote:
>>
>>> If someone wants to branch my repo and mod it to add graphics, I suppose
>>> they could. However, I would advise against it. I plan to do
>>> continuous development on Text Sweeper for a while, and will be releasing
>>> updates more frequently. Additionally, I can't guarantee that my changes to
>>> how things are done behind the scenes will work with those modifications.
>>> In fact, I suspect that as I make changes to how the screen gets drawn, it
>>> will not work with ASCII PIXELS as it did before.
>>>
>>
>> Thanks for clarifying that.
>>
>>
>> I have a new feature(implemented in BASIC) that detects if the screen
>>> isn't drawn properly, and I do it by checking the LCD RAM location for
>>> specific characters. If they aren't there, it redraws the screen. This is
>>> to try and prevent a situation where someone presses LABEL. and eliminates
>>> the bottom row of the screen. I'm guessing either the RAM layout is
>>> different for the T200.
>>>
>>
>> Yup. The Tandy 200's memory layout is different. But if the concern is
>> that someone might accidentally hit LABEL, why not just send the escape
>> sequence to turn labels off?
>>
>> PRINT CHR$(27)"U"
>>
>> or (less portably),
>>
>> SCREEN ,0
>>
>>
>>
>>> Is there any quick way to detect T200 ROM vs M100/T102 ROM?
>>>
>>
>> PEEK(1)
>> <https://github.com/bgri/m100LE/issues/40#issuecomment-1302636101> will
>> usually work. Here's a table I made for various Model-T machines when I was
>> trying figure out the address of the RAM Directory:
>>
>> Model PEEK(1) RAM Directory Address SAVEM bug? KB Count Address
>> Kyocera Kyotronic-85 225 63849 Yes 65387
>> TRS-80 Model 100 51 63842 No 65450
>> Tandy 102 167 63842 No 65450
>> Tandy 102 (UK) 167 63842 No 65450
>> Tandy 200 171 62034 No 64799
>> NEC PC-8201 148 63567 Yes 65128
>> NEC PC-8201A 148 63567 Yes 65128
>> NEC PC-8300 148 63567 Yes 65128
>> Olivetti M10 (Italy) 35 63849 Yes 65389
>> Olivetti M10 (US) 125 ? ? ?
>>
>>
>>
>>> I cur

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[grima...@gmail.com]

Wow! 2.0 was a long time ago! I think in 2.1, I made some the change to the
way the minefield generation works.

To make a long story short, one of the features I incorporated was that no
mine can be present in any cell surrounding initial click. In essence, the
cell you click will always be a zero. This is how Microsoft’s version works
as well.

If you set up the minefield prior to clicking, you need to do some checks
on initial click and move mines around.

By waiting for the user to click, it ensures we can do the minefield
generation all in one go, which is just a bit simpler.

Re: the Flag. I’ve gone back and forth on it. Myself and a few others were
having trouble distinguishing an ASCII character from the surrounding
numbers at a quick glance.

Personally I found the checkerboard a bit more readable. Better yet would
be an inverted ASCII but I haven’t managed to work on that yet.

Make sure to check out what happens when you click a number cell, and it
has the appropriate number of flags around it.

-George


On Tue, Feb 14, 2023 at 9:22 PM B 9  wrote:

> Just note, I already put together a 2.3.1 release, which significantly
>> increases cursor responsiveness. Try it out if you have time.
>
> Works great on my Model 200 once I commented out line 3010. (Until I hit
> the 'H' key, anyhow).
>
> I like that you are using asterisks ✳ for the mines now. That makes more
> sense to me than capital "M"s.
>
> I did find the new flag character (checkerboard, ﮕ) confusing, but maybe
> I'll get used to it. I think I'd prefer something that looks more like the
> official minesweeper flag. Perhaps a capital 'P' or a question mark? Either
> of those would also have the benefit of being ASCII text, so TSWEEP would
> be portable to the international "Model T"s by Kyocera, Olivetti, and NEC.
>
> Out of curiosity, why can the user now move the cursor and pick a square
> before the mines are placed?
>
> —b9
>
>
>
>

[M100] - Backpack

[grima...@gmail.com]

Just received my Backpack from Soigeneris. All I have to say, is that I
really like the design of it all. It’s relatively compact, it matches the
design of the M100, and it runs on a single AA cell.

I immediately plugged it in, and got it to work. Pretty much zero
configuration needed. I’ve already got REX installed so I was able to load
up TS-DOS and be off to the races.

Shout out to Soigeneris and to whomever designed and built this device!

Best,
George

Re: [M100] Conflict with Backpack SD drive

[grima...@gmail.com]

Do you need DOS and Multiplan concurrently? If you have a REX, you probably
can switch between Multiplan and the ROM version of TS-DOS as needed!

-George

On Tue, Feb 14, 2023 at 11:12 AM  wrote:

> Talking to friend who created Backpack and he suggested trying Teeny.co as
> it does not hook into anything. You could use the CLI to change directories
> if needed. Let us know if it works.
>
>
>
> Jeff Birt
>
>
>
> *From:* bir...@soigeneris.com 
> *Sent:* Tuesday, February 14, 2023 8:27 AM
> *To:* 'm...@bitchin100.com' 
> *Subject:* RE: [M100] Conflict with Backpack SD drive
>
>
>
> I don’t know if they will behave differently or not. It would not hurt
> anything to try.
>
>
>
> Jeff
>
>
>
> *From:* M100  *On Behalf Of *Comcast
> *Sent:* Tuesday, February 14, 2023 8:02 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Conflict with Backpack SD drive
>
>
>
> Thanks, will do!
>
>
>
> Did you see my note/question on if the other (non TS-DOS) disk managers
> listed in your manual might also be worth trying?
>
>
>
> Mike
>
> Sent from my iPhone
>
>
>
> On Feb 14, 2023, at 7:56 AM, bir...@soigeneris.com wrote:
>
> 
>
> The bootstrap program is just a bit of BASIC that loads TSDOS, it does
> nothing else and does not stay resident/running so there is nothing to
> uninstall.
>
> It might be that part of TS-DOS is being installed in high memory and this
> is conflicting with Multiplan? Go to:
> http://club100.org/library/libdoc.html  , look on the right center of
> page and download TSDOS.PDF ‘The Best On’. There are a lot of TSDOS tips
> and tricks in there including how to uninstall it.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Comcast
> *Sent:* Tuesday, February 14, 2023 7:28 AM
> *To:* m...@bitchin100.com
> *Cc:* M100 
> *Subject:* Re: [M100] Conflict with Backpack SD drive
>
>
>
> Thanks Jeff,
>
>
>
> I tried that - nope
>
>
>
> Do the other disk manager softwares you speak of install differently,
> worth trying?
>
>
>
> What is the method to “uninstall” the bootstrap? Couldn’t find that
> anywhere, so just did a cold reset
>
>
>
> Mike
>
> Sent from my iPhone
>
>
>
> On Feb 14, 2023, at 7:22 AM, bir...@soigeneris.com wrote:
>
> 
>
> I’m just guessing here but suspect that TS-DOS is hooking into some of the
> same resources that Multiplan tries to hook into. You might try the ‘DOS
> OFF’ button before trying to run Multiplan.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Comcast
> *Sent:* Monday, February 13, 2023 11:15 PM
> *To:* m...@bitchin100.com
> *Cc:* M100 
> *Subject:* [M100] Conflict with Backpack SD drive
>
>
>
> All, just when I thought I was over my challenges with my MS multiplan ROM.
>
>
>
> As was explained to me in great detail (thanks you!) that this ROM does
> have some atypical characteristics, like forcing a cold reset upon install
> or removal.
>
>
>
> I was excited to just purchase and receive one of the backpack SD card
> units that simulates a TPDD. IT works great but….
>
>
>
> Here is where I need help from the experts, something about its bootstrap
> installation of TS-DOS, which By the way I cannot seem to find any
> instruction, manual or otherwise on how to uninstall this bootstrap!  But
> regardless, it does something in RAM that now conflicts with my multiplan
> ROM ☹
>
>
>
> Multiplan will not run if the TS-DOS is installed per the instructions for
> the backpack, if I cold reset, then multiplan will run fine, but as soon as
> I install the SD card  bootstrap, when I enter multiplan it just returns me
> to the menu
>
>
>
> Thanks in advance for any assistance, I am hoping I can identify the
> conflict and load the TS-DOS in a different location ?!?
>
>
>
> Model 102  BTW
>
>
>
> mike
>
>

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[grima...@gmail.com]

>
> I love text as the base setting and can understand why you'd want to stay
> true to the pure text spirit. Would you object if someone made a mod that
> allowed for both text and graphics? Would it help if it was named something
> else to avoid confusion with TSWEEP?

If someone wants to branch my repo and mod it to add graphics, I suppose
they could. However, I would advise against it. I plan to do
continuous development on Text Sweeper for a while, and will be releasing
updates more frequently. Additionally, I can't guarantee that my changes to
how things are done behind the scenes will work with those modifications.
In fact, I suspect that as I make changes to how the screen gets drawn, it
will not work with ASCII PIXELS as it did before.

Is there a version of the more efficient algorithm done in BASIC? I don't
> have a Model 100. My Tandy 200 ran TSWEEP 2.0 just fine, but 2.3 repeatedly
> draws the black background one row at a time, clears the screen, and starts
> again. I'm guessing the machine language isn't portable.
>
I don't think the ML subroutine is the issue. I have a new
feature(implemented in BASIC) that detects if the screen isn't drawn
properly, and I do it by checking the LCD RAM location for specific
characters. If they aren't there, it redraws the screen. This is to try and
prevent a situation where someone presses LABEL. and eliminates the bottom
row of the screen. I'm guessing either the RAM layout is different for the
T200.

Is there any quick way to detect T200 ROM vs M100/T102 ROM? If that's the
case, I could detect the model at startup, and check the correct memory
location. I currently also redraw the minefield the same way when switching
between the Game screen and the Help screen. This is relatively slow, as I
need to calculate the display value of every tile, concatenate into a
string to represent a row, since it isn't stored. This is mostly so that I
minimize the amount of times I call PRINT. My plans here are to Copy LCD to
ALTLCD when switching, and then print ALTLCD back to the screen when
switching back. Then I will update my redraw routine to just populate
ALTLCD via POKE, and invoke the ML subroutine the draws prints ALTLCD.
Still a work in progress however.

Do you know the keys from the "vi" text editor? While not laid out in a
> physically intuitive way, personally I'd be happier with those keys plus
> the nethack extensions for diagonal movement:
>
On the cursor controls, I will take a look. Diagonal movement would be
nice, but I think it'd probably lower on the feature backlog.

I think as of right now, based on your feedback, and my general user
experience.

   1. Restore compatibility with T200.
   2. Improve speed when switching between Game and Help.
   3. Improve speed of mine revealing algorithm.
   4. Decrease memory footprint of program, both program size, and memory
   usage.
   5. More control options.
   6. Support larger displays of both T200 and DVI (might be a stretch). In
   my mind, I would have the Help screen permanently displayed beneath the
   game screen. Alternatively, I could make a larger minefield and option, but
   that would break a lot of assumptions in the code today, and require a ton
   of rework.

Just note, I already put together a 2.3.1 release, which significantly
increases cursor responsiveness. Try it out if you have time.

Best,
George




On Mon, Feb 13, 2023 at 11:40 PM B 9  wrote:

> On Mon, Feb 6, 2023 at 2:16 PM grima...@gmail.com 
> wrote:
>
>> 1. I am still alive and well, not that anyone seemed overly concerned
>> there :D
>>
>
> Yay!
>
>
>> Updates coming soon.
>>
>>- I started managing the codebase through a Private git repository. I
>>will opt to just make this Public for posterity's sake when I release the
>>next updated version.
>>
>> That's awesome. I found your repository at
> https://github.com/Grimakis/TextSweeper.
>
>
>>
>>- I have removed the AsciiPixels integration. While it was nifty, I
>>think it went against the spirit of the game, which was intended to be an
>>entirely text-based Minesweeper clone.
>>
>> I love text as the base setting and can understand why you'd want to stay
> true to the pure text spirit. Would you object if someone made a mod that
> allowed for both text and graphics? Would it help if it was named something
> else to avoid confusion with TSWEEP?
>
>
>>
>>- This has a theoretically infinite upper bound, as RND could
>>generate invalid spaces forever. This is noticeably slow when running
>>denser minefields
>>
>> Yup! Mine generation was the biggest problem with the 2.0 version of
> TSWEEP.
>
>
>>
>>- I replaced it with an algorithm that will always select a space
>>that is valid.
>>

[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

Re: [M100] Video RAM, Ram Buffer, and LABEL

[grima...@gmail.com]

Thank you for the info!. Is it safe to say that ALTLCD can be used for
whatever I need to use it for, within a basic program?

Best,
George


On Fri, Feb 10, 2023 at 10:58 PM Stephen Adolph 
wrote:

>
> https://bitchin100.com/wiki/index.php?title=VT100#Comments_about_VT100_Terminal_support_for_Model_100
>
> Have a read at the bottom.  You want to lock line 8.
> Hope that helps.
>
> Altlcd starts at FCC0 hex and is 320 characters long.
>
> The lcd buffer keeps track of characters only.  You need to call the
> printing routines to actually modify the screen.
>
> Cheers
> Steve
>
>
> On Friday, February 10, 2023, grima...@gmail.com 
> wrote:
>
>> Hi all,
>>
>> I've got a few questions for you all.
>>
>> 1. Is there any way to disable the LABEL button in a BASIC program? I
>> have found that if you press it during my game (Text Sweeper), it will
>> shift the entire minefield up by one row and print the Function Key defs.
>> Of course this renders the game into a pretty much irrecoverable state at
>> the moment. I don't store the graphical representation of the board
>> anywhere, so to recover from this is a bit of a pain, although doable.
>> However, if I can avoid this scenario entirely, that'd be great.
>>
>> 2. I read at one point there is a location in memory reserved for storing
>> the LCD character contents in memory when switching to TELCOM. Where is
>> this, and can I use that range of memory for the same purpose in my case (I
>> kind of want to add an instructions screen you can flip back and forth
>> between)
>>
>> 3. Does writing to video RAM locations cause the LCD to update directly?
>> Or is there a print subroutine that basically needs to be called?
>>
>> Best,
>> George
>>
>

[M100] Video RAM, Ram Buffer, and LABEL

[grima...@gmail.com]

Hi all,

I've got a few questions for you all.

1. Is there any way to disable the LABEL button in a BASIC program? I have
found that if you press it during my game (Text Sweeper), it will shift the
entire minefield up by one row and print the Function Key defs. Of course
this renders the game into a pretty much irrecoverable state at the moment.
I don't store the graphical representation of the board anywhere, so to
recover from this is a bit of a pain, although doable. However, if I can
avoid this scenario entirely, that'd be great.

2. I read at one point there is a location in memory reserved for storing
the LCD character contents in memory when switching to TELCOM. Where is
this, and can I use that range of memory for the same purpose in my case (I
kind of want to add an instructions screen you can flip back and forth
between)

3. Does writing to video RAM locations cause the LCD to update directly? Or
is there a print subroutine that basically needs to be called?

Best,
George

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[grima...@gmail.com]

Hi all,

I did just see this thread, and I want to provide a few updates.

1. I am still alive and well, not that anyone seemed overly concerned there
:D
2. My website is down because I accidentally kicked out the network cable
for my raspberry pi, and I didn't notice. I will be fixing this shortly.
3. I have been diligently working on Text Sweeper for the last week, and I
have some updates to share.

Updates coming soon.

   1. I started managing the codebase through a Private git repository. I
   will opt to just make this Public for posterity's sake when I release the
   next updated version.
   2. I have removed the AsciiPixels integration. While it was nifty, I
   think it went against the spirit of the game, which was intended to be an
   entirely text-based Minesweeper clone.
   3. I have modified a significant amount of the codebase. I have
   rewritten a large portion of the mine generation, and some of the other
   common subroutines.
  1. Mine generation algorithms used to be naive. I would pick a spot
  to put the mine, check if it isn't within the initial 3x3 area
of the first
  click, and check if it wasn't already a mine.
 1. This has a theoretically infinite upper bound, as RND could
 generate invalid spaces forever. This is noticeably slow when running
 denser minefields
 2. I replaced it with an algorithm that will always select a space
 that is valid.
1. Accomplished by generating the array of all spaces
upfront.(done in ML for performance reasons) And then
removing the 4-9
invalid spaces around X,Y
2. After selecting a space, it's value will be set to -1 in the
initial array
3. Next, I use RND to generate a value(I%) between 0 and
256-SpacedAlreadySelected
4. Finally, I loop over the spaces in the array, and increment
the array index(I%) for each -1 in the array. This yields
a new I%, which
is the Nth non-negative position in the array. (done in ML
for performance)
 3. This means that each loop in BASIC generates a valid position,
 and the loop runs MN% number of times, where MN% is the
number of mines we
 have to generate. Previously, it would run anywhere from MN%
to infinity.
  2. Mine adjacency counts were done at the time of checking the cell.
  I moved this to happen immediately after the generation of the
minefield. I
  also have an ML routine that generates the upper and lower bounds for
  checking a cell.
  3. Using that same ML routine as above, to generate the bounds when
  checking the mines.
 1. So far there is about a 20-30% measured improvement on the mine
 checking of the first move. (benchmarked using a 100 count minefield)
  4. I replaced most of the GOTOs with FOR loops where applicable.
  5. Refactored a lot of the code to just remove duplication where
  unneeded.
  6. The way I inserted ML into the program.
 1. I dimensioned INT arrays for each subroutine.
 2. I poked in my code from Data Statements.
 3. I limited absolute addressing and jumps as much as possible.
1. In the case where I need to do JMP operations, I have BASIC
modify the ML addresses prior to execution.
 4. I'm not an expert, but as I understand it, this should mean
 that the ML code won't conflict with any other programs in
memory, as long
 as you have the free space for BASIC to DIM the arrays. If
not, it will
 fail safely.
  4. Flagged mines must be unflagged before selecting them. Prevents
   accidentally setting off a flagged mine.
   5. Other features I want to add:
  1. Selecting a space where the Number in the cell == Flags in
  surrounding cells will open all adjacent cells. This is a common
feature in
  other versions.
  2. Additional controls for L/R/U/D. I developed this mostly using
  VirtualT to test. The arrow keys kind of stink as the interface on an
  actual M100.
  3. Rewrite some additional pieces in ML if possible, to improve the
  speed at which means are revealed. This part is slow and makes the game
  less fun.
  4. Add some instructions into the game itself.

After all this is complete, I will make the github public, which will
include the assembly code as well.

Please let me know your feedback on any of the above, and if you have any
suggestions. Please bear with me, I just taught myself assembly over the
weekend so it's been a bit of a trial by fire. :D

Best,
George

On Wed, Jul 6, 2022 at 7:17 PM Ken Pettit  wrote:

> Hi All,
>
> Sorry, didn't reply to this for quite some time ... the family caught
> Covid-19 last week and I was still recovering (I was taking care of
> everyone and then was the last to get it).
>
> I will look into my T200 AciiPixels implementation to see if I ever (or
> can still) get