In order to learn a little about BBC programming, I thought I'd port my Sudoku solver program from the Atari 8bit series to the Model B/Master 128. That will be a quick getting started exercise, or so I thought before going down the rabbit holes of experimenting with different assemblers and reworking the solver part to be more efficient. Now, several months later, it is just about robust enough to show.

Attached are two (zipped) SSD files, one for the Model B and one for the Master 128. The main difference is that the Model B version needs to run in MODE 4 (unless running on a 2nd processor, in which case you can use MODE 1). The Master 128 version can run in either MODE 129 or MODE 132. The Model B version uses only legal/documented NMOS 6502 instructions, the Master 128 version uses some CMOS 65c02 instructions as well.

The pictures below show what the Daily Telegraph claimed to be the world's hardest Sudoku which can be solved in ~21 seconds, if you want to watch it trying. The picture shows ~20 seconds (BeebEm) compared to ~21 seconds on a real Master 128, so perhaps there is a timing issue here. Solving this one in "Fast" mode (in which there is no progress shown until the end) gives more consistent timing. This isn't an area I've really looked into yet.

pic1.png (1.8 KiB) Viewed 1030 times

pic2.png (2.58 KiB) Viewed 1030 times

Typical newspaper puzzles should be solved in ~1 second.

Both versions should run on their respective 2nd (6502/65c02) processors. Running the example above on a PI Zero reduces the run time to ~0.2 seconds.

There are two test cases on the disk images, T.HARDEST and T.17CELLS, which can be loaded using the "L" option. To enter a puzzle, use the "N" option, digits 1-9 to enter known values, arrow keys to navigate around, delete to erase (backwards) and space to overwrite (forwards). Press escape to exit edit mode. Escape will also exit the program. For more information, please refer to the link above.

Known issues.

1) The time display is missing a zero when <0.1 seconds.2) If the puzzle cannot be solved (initial state is inconsistent), the last solution is displayed.

But as these are just cosmetic I didn't want to hold back from an initial release.

Very nice, and I'm reassured to see that a Beeb can do it a lot faster than an Atari (I'm guessing this is a 2MHz vs 1MHz effect). Does the extra memory on a Master help? And also, do you plan to implement the memory use and other stats from the Atari version?

Well the Atari is ~1.73Mhz not 1Mhz but ANTIC DMA steals ~30% of the cycles. So given that v0.6 on the Atari takes ~69 seconds with the display active, if all things are equal, the BBC should take 69*1.73*(1-0.3)/2.0 or ~41.8 seconds. I don't have the exact figure to hand, but ~41.8 seconds sounds about right for the time when I did the initial quick port of the v0.6 algorithm to the BBC. It was certainly over 40 seconds. This calculation will be distorted by the fact that one can write to a GRAPHICS 0 (text) screen on the Atari much faster than using the BBC MOS.

The rest of the performance improvements are mostly down to improved implementations of the algorithms in the solver routine, plus a little from general improvements to loop efficiency, loop unrolling and so on.

v0.7 is somewhat faster for puzzles which can be solved without recursion. The 17Cells example takes ~2.4 seconds on the Atari running v0.6 compared with ~0.4 seconds on the BBC (which would be ~1.4 seconds in v0.6 using the calculation above).

The shadow RAM on the Master allows the program to run in MODE 129 (1) rather than MODE 4 on the Model B. While this allows for some colour, it actually slows the program down as it takes more effort for the MOS to write the screen in MODE 129.

I guess I could implement the other three statistics, they were slightly useful during development, although "Inserted" is a rather meaningless number now given the changes in the solver.

The next step is to port the improvements back to the Atari version and to some extent build both versions off the same code base. That should keep me amused for a while.

I did briefly ponder MODE 7, but I couldn't see that I could get some sort of line draw characters (block graphics) and numbers at the same time. Having said that I am a complete BBC neophyte (this is my first BBC program) so I could easily be mistaken.

If anyone wants to mock up a MODE 7 screen for me and show me how it's done, please feel free.

Thank you, I can see where you're coming from now. Leverage the fact that I'd have to use a space for the colour change to space out the grid. I was over-thinking the problem of how to represent the grid, where the simplest answer is not to bother.

Interesting, both are a lot harder than "the World's Hardest Sudoku", at least for some value of "hard". I did notice that the first one at least causes the pass counter to wrap round, I'll have to change the switch in the source to turn that back into a word and rebuild.

True, and I can replicate the problem in BeebEm 3. However given that this comes from a thread where it appears they are discussing puzzles designed to break Sudoku solvers on fast modern hardware, I'm not too worried about that.

EdwardianDuck wrote:Attached are updated versions with PASS set to be a word so that the count doesn't wrap for the hard puzzles above (but no other improvements).

Jeremy

Would that affect its ability to solve a puzzle, or just a display issue?If I fill in 1-9 in the top left 9 squares, it solves quite quickly.Put in 123, 789, 456 in the same squares, runs for hours (still hasn't finished)

works because it arrives at a solution without needing to use 9 as a trial value (or so I infer). Also solving a blank grid works.

Now the good news, it works fine on v0.6 on an (emulated, Altirra) A8, so basically I've introduced a bug while improving the solver performance. That's something I can fix, although probably not before the weekend.

BigEd wrote:Here's something interesting - the solver gives up on this one:

Eliminating one of the deterministic algorithms from the solver allows both problem cases to complete successfully, if somewhat more slowly (+70% for T.HARDEST for comparison). This is one of the routines which was rewritten for v0.7, although I haven't been able to determine what the problem is this evening.

After a couple of evening's staring at the offending algorithm, I've finally managed to spot the error, one CLC missing! I did feel a bit of a twit when I found that.

Attached are updated disk images which fix the two problem cases mentioned earlier. (The non-trivial example is T.BIGED on the image to save typing).

What is slightly interesting is that T.HARDEST now takes an additional two passes to solve. This is due to the earlier error causing the solver to accidentally find the correct value for one cell earlier in the process. Now that it works properly, it takes a little longer.

I'm relieved that's fixed, I'll have time to experiment with MODE 7 at the weekend.

The link that I posted to edit.tf is a website that is a Teletext editor, the page is the URL, so to save a page, just bookmark it.There are also several editors that run on the beeb (or emulator) including one by JGH.