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 <petti...@gmail.com> 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 it to a stand-alone .CO file. > > Also, I will document the binary format so it is no longer "Top Secret" :) > > Ken > > On 6/30/22 10:33 PM, B 9 wrote: > > If you would, I'd greatly appreciate it as reverse-engineering it and > porting it to the T200 is well beyond my abilities. > > Also, correct me if I'm wrong, but is the only documentation for the > graphics format in the source code (e.g., pbm2ap.c)? The docs I found on > club100 simply say, "TOP SECRET!" 😆 > > --b9 > > On Thu, Jun 30, 2022 at 12:59 PM Ken Pettit <petti...@gmail.com> wrote: > >> Hey b9, >> >> I would have to go back and check the T200 support. I know I had ASCPIX >> working on T200 at one point because I had a few demos of some full-screen >> images and even a screen mock-up of Mahjong tiles. >> >> Ken >> >> On 6/30/22 12:33 AM, B 9 wrote: >> >> Thank you, Tom and John! TSWEEP doesn't seem to work on my Tandy 200 when >> ASCPIX.CO is loaded. I get a syntax error in line 16000 which is the >> first call to ASCPIX that actually tries to show something: CALL A, 2, >> VARPTR(F$) >> >> Ken Petit's member page at club100 has a download for ASCPIX.CO that >> mentions the Model 100/102, but I don't see a separate version for the >> Tandy 200. The documentation for ASCPIX >> <http://www.club100.org/memfiles/index.php?action=view&filename=ap_doc.txt&directory=Ken%20Pettit/AsciiPixels&> >> says it works for both, but doesn't mention how. >> >> Perhaps I am using it wrong? There are no instructions in the TSWEEP >> program, so I'm using the brief instructions Ken Petit >> <https://www.mail-archive.com/m100@lists.bitchin100.com/msg03624.html> >> posted back in 2017. >> >> CLEAR 256, 58000 >> LOADM "ASCPIX" >> RUN "TSWEEP" >> >> —b9 >> >> >> On Sun, Jun 19, 2022 at 8:32 PM John R. Hogerhuis <jho...@pobox.com> >> wrote: >> >>> Here's some files I have in my Google drive For tsweep >>> >> >> >