Hello! In my digital electronics class, I am working on creating Minesweeper in Multisim version 14.0 as a side project. I have run into an issue on how to count the number of adjacent mines to a certain tile. (I number the places where the adjacent mines should be like the number pad; 5 being the tile you are going to click and every number around the 5 being a position for a mine)

At the start, for a prototype of a corner tile where only three mines max could be adjacent, I just used lots AND gates. For checking if two mines were adjacent, I used 3 input AND gates .One input for clicking the tile, and the other two were signals from adjacent tiles about whether there was a mine there or not. I used three of those as well as three 2 input AND gates for checking if one bomb was adjacent and one 4 input AND gate if all 3 tiles had a mine. Quickly I realized that for a tile that could have eight adjacent bombs that this is clearly the most inefficient solution.

Also, I have tried cascading half adders, but if the mines that are active aren't all one after the other in numerical order, the number given back is wrong. For example, let's say the mines where 1, 2, and 4 are on the numpad were on. Rather than getting back 00000100, I would get back a 00001010. (These numbers do not represent a binary number, rather just the number of mines that are adjacent).

So essentially what I think is the best solution is a circuit that can count the number of 1s in an 8 bit number ( a bit representing each adjacent tile). I'd prefer to use just full adders and half adders since I know them well. If I have to though, I will try other components/circuits. The answer can be a binary number showing how many mines are adjacent or an 8 bit number where only one bit is a 1, with each bit representing 1, 2, 3... through 8 mines adjacent (like my attempt with cascading half adders). Any help is appreciated. Thanks!

 

If you copycat the microsoft mine sweeper then they have and for diagonal proximity R.d=√2 and orthogonal proximity R.o=1 a very same "Field/Signal strength" 1 -- as -- a row of mines scanned in parallel to that row from distance 1 gives you 111 , 1221 , 12321 , 123321 , ... , prev*10+111
while in real life it'd be something F=Const/R² e.g. F.R.o=1/1² and F.R.d=1/(√2)² = 0.5 to avoid floating point ortogonal = 2 = 2·1/1² and diagonal mine = 1 = 2·1/(√2)² -- your row would sum then 121 , (1210+121=)1331 , (13310+121=)13431 , ... but this goes too complex for average player
ok whatever method you use you have max 8 mines to spot/nest where you can display the field strength . . . -- just perhaps using 8 parallel/stacked 2D-bit-planes -- giving each nest an input of 8 directions (from surrounding field) -- might be the first setup i attempted

 

If you copycat the microsoft mine sweeper then they have and for diagonal proximity R.d=√2 and orthogonal proximity R.o=1 a very same "Field/Signal strength" 1 -- as -- a row of mines scanned in parallel to that row from distance 1 gives you 111 , 1221 , 12321 , 123321 , ... , prev*10+111
while in real life it'd be something F=Const/R² e.g. F.R.o=1/1² and F.R.d=1/(√2)² = 0.5 to avoid floating point ortogonal = 2 = 2·1/1² and diagonal mine = 1 = 2·1/(√2)² -- your row would sum then 121 , (1210+121=)1331 , (13310+121=)13431 , ... but this goes too complex for average player
ok whatever method you use you have max 8 mines to spot/nest where you can display the field strength . . . -- just perhaps using 8 parallel/stacked 2D-bit-planes -- giving each nest an input of 8 directions (from surrounding field) -- might be the first setup i attempted

This is a very interesting idea. My only concern is how I would implement this into Multisim version 14.0. I'm new to the program as my classes just started a month and a half ago. Also, I'm not sure I fully understand what you mean when you talk about "a row of mines scanned in parallel to that row from distance 1 gives you 111, 1221, 12321..." Could you go more in depth about what you mean? I do understand diagonal and orthogonal distance and the idea of using bit planes though. Thanks for the response!

 

you learn new programs programming languages by
confirming that what you do (program) is what you intended to do (envisioned it to be)
is (checking adjusting) what the program actually does (limitations and alternate ways to get your stuff done) -- step at the time (with enough comments or minimal documentation log of steps done in timeline by topic)

------------------------------------------▲go up by 111 , then left 44321[◄][ ] the mines are in horizontal row
the field strength is listed by the numbers at distance 1 cell(/square) from the mines (at above them in this case)
if there were no mine above first 4 of 44321[ ][ ] the each next mine would add 111 to above it - thus 111 , 1221 , 12321 e,c

[7][8][1] ◄ a directions matrix for the cell of interest "[?]" the numbers are directions' indexes (indexes for cells that sum their field at "[?]")
[6][?][2] ◄ if all the numbers/direction(inexes) were containing mines then
[5][4][3] ◄ you'd had a total field strength of "8" listed in a game while sqaure opened by user click on cell "[?]"
or (other) if you click on coordinates(a memory address of [?] your system returns bits 1 to 8 - if there is mine at that direction the bit is set -- while the user(/player) sees only the sum of these bits (as a number value) at "address [?]")

. . . bit planes or other node structure is how you "hardware implement" your game

what i don't realize here is if you build something a "minesweeper game pad" where player presses buttons or touches screen - that results in screen(/game's mine field coordinates AND an action or no on theses coordinates)
or you build a "minesweeper playing robot" where you "load" a "game(a particular mine field)" for the robot (a finite automaton in this case) to play

 

you learn new programs programming languages by
confirming that what you do (program) is what you intended to do (envisioned it to be)
is (checking adjusting) what the program actually does (limitations and alternate ways to get your stuff done) -- step at the time (with enough comments or minimal documentation log of steps done in timeline by topic)

------------------------------------------▲go up by 111 , then left 44321[◄][ ] the mines are in horizontal row
the field strength is listed by the numbers at distance 1 cell(/square) from the mines (at above them in this case)
if there were no mine above first 4 of 44321[ ][ ] the each next mine would add 111 to above it - thus 111 , 1221 , 12321 e,c

[7][8][1] ◄ a directions matrix for the cell of interest "[?]" the numbers are directions' indexes (indexes for cells that sum their field at "[?]")
[6][?][2] ◄ if all the numbers/direction(inexes) were containing mines then
[5][4][3] ◄ you'd had a total field strength of "8" listed in a game while sqaure opened by user click on cell "[?]"
or (other) if you click on coordinates(a memory address of [?] your system returns bits 1 to 8 - if there is mine at that direction the bit is set -- while the user(/player) sees only the sum of these bits (as a number value) at "address [?]")

. . . bit planes or other node structure is how you "hardware implement" your game

what i don't realize here is if you build something a "minesweeper game pad" where player presses buttons or touches screen - that results in screen(/game's mine field coordinates AND an action or no on theses coordinates)
or you build a "minesweeper playing robot" where you "load" a "game(a particular mine field)" for the robot (a finite automaton in this case) to play

Thank you for further explaining what you mean. It makes sense to me now. After making a few truth tables and filling a few pages of notebook paper, I was able to accomplish what I needed with 11 adders. For the sake of speed though, I will be sure to take your ideas into consideration. Thanks for the help!

 

? speed . . . i once explored a FlagRegisters Matrix that should'have been a part of a OS Core(/Kernel) where misc system states would be "simplified" to 1 bit flags to test the condition true takes reading a bit by/trough mask from DIV Reg.length() indexed Reg . . . ← if ← such were hardware implemented it'd be reading a bit value from X by Y bit memory - that you could also use for mine field - addressing your bits to check/add/compare/toggle by relative_addresses_matrix decoder (for area ((near user L/R "Click" e.g. open/mark)) ) then push/connect the matrix to games ALU , then write output bits to their status XYmatrixes

simply -- suppose you need to check 9 game_fields content for ????((((3-bit flags as mine.set(true,false)×mine.status(undiscovered,right-marked,exploded,revealed) )))) and form an game ALU output by what's there
then the relative adress matrix decorer adresses "XY-bit-RAM" bits (X-1,Y-1)to(X+1,Y+1) for 3 Status registers
"feeding" to gameALU 3x9 bits , as soon as output fixes the 3x9 source block can be updated to new values
▲here▲ the best speed is achieved if your port_width to 3×(X+2)×(Y+2) bit ram is that of the gameALU input e.g. 3x9 source block = 27bits

 

why you pay your taxes for https://educationusa.state.gov/find-advising-center