I don't see how turning off the label line would help? You can turn off the label line. But the problem is when someone presses the label key, the line comes on, and it messes up your display.
What is needed is a way to disable the label key feature while the program runs. There might be a poke or command for that. I don't know. Maybe another listmember knows. -- John. On Wed, Feb 15, 2023, 5:36 AM grima...@gmail.com <grima...@gmail.com> wrote: > 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 <b.kenyo...@gmail.com> 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 <hacke...@gmail.com> wrote: >> >>> On Tue, Feb 14, 2023 at 6:00 AM grima...@gmail.com <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 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. >>>> >>> >>>> - Improve speed when switching between Game and Help. >>>> >>>> I like that you are adding builtin instructions and it sounds like a >>> fun optimization to make it faster. If you're using the TELCOM back page >>> (ALTLCD) to store an actual page of text, maybe investigate how TELCOM is >>> able to switch so fast between the two pages. I suspect it is doing >>> something more clever than simply copying the data. >>> >>> >>>> >>>> - Improve speed of mine revealing algorithm. >>>> >>>> If it's still the same speed as TSWEEP 2.0, improving that would >>> certainly help playability. >>> >>> >>>> - 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. >>>> >>>> >>> It would be fabulous if TextSweeper allowed for different size screens. >>> The Tandy 200 has 16 rows, which should make for a more fun game of >>> minesweeper. >>> >>> If you plug your Model 100 into the DVI monitor >>> <http://tandy.wiki/Disk/Video_Interface> you mentioned, you get an >>> additional screen with 80 (or 40) columns by 25 rows. I do not believe the >>> DVI provides an ALTLCD area for TELCOM, but you can show the help screen on >>> the LCD and switch to the CRT for the actual game. >>> >>> —b9 >>> >>> P.S. Just for fun, I wrote a little BASIC routine that should be able to >>> detect the screen size: >>> >>> 1 REM Test detecting screen size 2 REM for M100, T200, DVI, etc. >>> >>> 10 E$=CHR$(27)20 CLS30 PRINT "Detecting screen size"100 PRINT " with >>> labels on: ";110 SCREEN,1120 GOSUB 500130 PRINT CO "x" RO200 PRINT " >>> with labels off:";210 SCREEN,0220 GOSUB 500230 PRINT CO "x" RO499 END >>> 500 REM Return number of rows in RO501 REM and columns in CO.505 >>> AR=CSRLIN: AC=POS(0)509 REM Go to furthest screen address.510 PRINT >>> E$"Y~~";520 RO=CSRLIN+1: CO=POS(0)+1530 PRINT >>> E$"Y"CHR$(32+AR)CHR$(32+AC);540 RETURN >>> >>>
