EdwardianDuck

It probably isn't much help, but beacon-light.com was archived by the Internet Archive at https://web.archive.org/web/20050915000000*/http://beacon-light.com. The later captures don't seem to work, but the one in 2005 and some earlier ones do. Nothing Atari Portfolio specific though, the site only mentions their (at the time) current products. There is a page of contact details, you might get lucky. Jeremy

Here is the latest version, v0.6. This has the following changes from v0.5 and v0.5x. I have dropped the status bar idea, IMHO it added little real value and didn't work that well. The menu has been reorganised to (hopefully) make it clearer. "Fast" mode is more clearly indicated with "(On)" and "(Off)" being appended as appropriate. Menu items which are not relevant are "greyed out" ("blued out"?) by removing the inverse video bit on the command character. When in "Edit" mode the word "Edit" is changed to "Exit" to make this a bit clearer. The fix for the "Fast/Background" problem in v0.5 and provisionally fixed in v0.5x is now formally working. There was no real change from v0.5x, but I've now had time to test it. Some of the UI code has been tidied up / tweaked a bit just to make things a little easier for me going forwards (on the assumption that there will be further enhancements). As ever, comments are always welcome. Jeremy Attachments Distribution (bootable DOS 2.5 image) Sudoku-0.6-Distribution.atr Source (ZIP) Sudoku-0.6-Source.zip Initial screen Edit mode showing disabled menu items

Here is an experimental version, v0.5x. I'm not uploading the source code this time because the changes where hurried and the code is messy. Source code will of course be made available once I'm happy with it. Also, it hasn't had much testing. Changes as follows: Fix for the Fast/Background problem (see "oops" post above). Addition of a status bar as suggested. This is just to get some feedback, I'm not convinced that it is much improvement over a redesigned menu section and I may drop it later. Mind you, I'm not claiming to have any expertise in the UI/UX field. The status bar shares the same line as the I/O error message, so after an error is shown, it remains there instead if the error until a menu action is invoked. Jeremy Sudoku-0.5-Experimental.atr

Bob, Thank you for the feedback, all valid points. In the short term... The background option isn't shown in the menu, but if you press the "B" key the player/missile background toggles on and off. When "Fast" mode is on, there is a "*" character appended to the menu item. In the original unreleased cc65 prototype, I swapped out the main menu for one which was relevant to the edit mode, but as it only had one option, I dropped it. On the other hand, the main menu is now getting crowded (which is why the "Background" option isn't visible) so a rethink of this bit is certainly overdue. Jeremy

Oops. I just noticed that there is a slight inconsistency between the "Fast" and "Background" options. That is, if "Fast" is ON and "Background" is ON then DMA doesn't get disabled when the solver runs. Should be easy enough to fix, but possibly not today. Jeremy

Here is the latest version, v0.5. This includes the following features. I added the "checkerboard" background based (very heavily) on the sample code generously provided by @pirx. I used a darker shade as this seemed to give more contrast between the text and background. Currently, the background is suspended when the "Run" and "Analyse" menu items are used. This is because (I guess) the extra DMA accesses for the players are slowing the solver down. There is a new option "B" (not actually shown on the menu) to toggle the background if you prefer not to have it. An "Analyse" option which runs the solver but doesn't show either the results or the workings. It does however show the statistics. The idea is that this can be used to determine how complex a puzzle is without showing you the solution. It can also be used to validate that the inputs represent a valid solvable puzzle (Consistent = Yes). A "Fast" option (toggle, shown with "*" if on). This just disables DMA (so no display) when solving. There isn't a lot of point to this IMHO, but I added it just so that "the World's hardest Sudoku" can be solved in under 1 minute. Added the "Trace" option to the menu. The code existed in v0.4. All this does is pause for a key press after displaying each inserted cell. I added this so I could single step through an edge case. Again, not really all that useful, especially given the way the solver works, except possibly as a hint mode. If you get stuck solving a puzzle manually, you could enter the "stuck" position, use the "Analyse" option to check if it can be solved without recursion (Depth = 0), then use the "Trace" option to see the next cell in the solution. "Trace" starts to make less sense if the solution requires recursion. ATR, source code and sample image attached. Jeremy Sudoku-0.5-Distribution.atr Sudoku-0.5-Source.zip

Issac, Solution times range from 0.4s to 69.2s between the simplest cases and what the Daily Telegraph claims is the world's hardest Sudoku. I'll hopefully be able to look at what you've produced this weekend. Jeremy

Hello Issac, Your post made me realise that I had said nothing about who can do what with my Sudoku program. Basically I wrote this purely for my own amusement and to share with the community. So, basically anyone can use the program or its source code for any purpose whatsoever. If you or anyone else wants to recycle any of the code, please feel free to do so. The only slight caveat to this is that I made use of the following code which may impose some restrictions. 1) The cursor handling code was taken from the cc65 runtime library. 2) The RLE unpack routine came from CodeBase64. Both were tweaked very slightly. But if you're only interested in the solving algorithms, neither of these are required. In theory you could repurpose the solver to check that your generated puzzles (I looked up your original thread and read your paper) are solvable once cells are blanked out. However, there are some traps along the way... I've been using the term "deterministic solution" to mean a solution that can be found by logic only, no guessing and recursion. 1) The aim of my program is to find a valid solution to the entered puzzle, not necessarily the only valid solution. It will halt as soon as it finds the first valid solution. In this respect only a deterministic solution is sure to be unique (depth = 0 in the status panel). 2) The solver is less sophisticated than a competent human solver. From time to time it will come up with a different solution. This arises when the solver gets stuck BEFORE the human solver and starts recursing. Where there are mulitple solutions from that point, the solver might not pick the same solution as the human. This is most noticable when a human solver can arrive at a deterministic solution but the solver cannot. This behaviour is less noticable in v0.4 where I added an extra algorithm, but I have seen one case in the last couple of weeks where I was able to solve it deterministically but the solver required one guess. However in this case (which I should really have made a note of) we arrived at the same solution. This extra algorithm is still only looking one step ahead, whereas a human may manage more steps. 3) Mitigating this by only accepting deterministic solutions in your program does mean that more complex puzzles will be rejected as unsolveable. You can implement this by removing the recursive section from procedure SolvePuzzle in Core.asm, which is the code from label guess: onwards. 4) I'm trading memory for speed. The program makes heavy use of lookup tables (over 2K just for the solver), which might be an issue if you are still targeting a cartridge solution. 5) The recursive solver can use a lot of memory and it does not check if it is running out. If you compare the memory used by test cases TC1.SUD and HARDEST.SUD (or get it to solve a blank grid) you'll get an idea of memory used by recursion. You could perhaps make use of the status values to rank puzzles in order of complexity. Some combination of pass count and the number of cells inserted in each pass (fewer = harder) might be a useful metric. Hopefully this is clear and of some help. Jeremy

Hello pirx, Thank you for producing this patch/example/proof of concept, that's really helpful. Such a neat idea to use PM graphics as a static background colour. I'm at the early stages of playing with PM graphics for another (potential) program and I don't think I'd have come up with this idea myself. What you have done solves the problem I was having with making the 3x3 squares more distinctive to help with alignment when entering the puzzle. I had originally done this by redefining the character set to make some of the lines thinner, but discarded it as it just looked ugly. I look forward to reading your code this evening and cross referencing with De Re Atari & Mapping the Atari to understand it. Sample image below. Jeremy

Essentially my program simulates how a human would solve a puzzle, as far as possible. The basic idea is to avoid making guesses for as long as possible, then make one guess for the cell with the least number of candidate values. Then given that guess the program reverts back to avoiding guesses until no further cells can be inserted. For typical newspaper puzzles, at most 1 or 2 guesses are required for the harder puzzles. However, I've only implemented a couple of deterministic (I think that's the right word) algorithms, so v0.4 will still resort to recursion before a human solver in some cases (but less often than v0.3). So running the 17 Clue Puzzle, as you point out, only takes 2.4 seconds, primarily because it doesn't need to make any guesses at all (Depth = 0). In fact this puzzle should be straightforward for a human to solve even through it looks hard. Compare and contrast HARDEST.SUD on the ATR, which was designed to be really hard to solve (apparently). I must confess that I have spent a ridiculous amount of time improving the performance of this program, just for my own amusement really. Jeremy

Thank you all for your kind and encouraging comments. I'm currently working on another slight revision which will add an "analysis" mode (basically solve the puzzle without showing you the solution). The idea is that you can look at the status panel to get a rough idea about how complex the puzzle is without seeing the solution (number of passes, recursion depth etc) and more importantly whether the inputs represent a valid puzzle (consistent = "Yes"). It might be useful for "manual" puzzle solvers. The other new feature will be an option to disable Antic DMA (SMDCTL= 0) during the solve just to speed things up. In terms of the lack of a directory listing, that's a fair point and is something I'll add to the wish list (no promises though). Originally I wasn't going to bother with loading and saving options at all, but added them when it became clear that I'd need to put quite a lot of test cases through the solver in order to test it properly. Jeremy

I only glanced at the iPlayer link, but it seems only a couple of episodes are available there. Below are some links to the Internet Archive with more episodes of the referenced series. From memory (I've watched all the videos in the first two linked sections below), video quality is patchy in places, but certainly watchable on a tablet/phone size screen. https://archive.org/details/computer-programme https://archive.org/details/makingmostmicro https://archive.org/details/microlive Only series 1 of MicroLive it seems. The parent page looks to have some other interesting stuff as well. https://archive.org/details/computersandtechvideos Jeremy

I've updated this program to version 0.4, adding an additional check to improve the chance of the program generating the same solution as a human solver. I noticed that one test case (PROBLEM.SUD) on the distribution ATR version 0.3 gave a different solution to the one I'd arrived at by hand. Version 0.3 did not allow for the case when despite not being able to place a value N within a 3x3 square precisely it was clear that N had to be placed in either a row or column of 3 cells within the 3x3 square. Given this knowledge a human solver is able to eliminate N from other cells in the grid and perhaps find a value to insert somewhere. Version 0.4 now includes this additional test and is able to proceed further before starting to make guesses. As a result of this change, runtime is slightly increased in most test cases (TC*.SUD on the distribution ATR). However, the time to solve what the Telegraph describes as "the world's hardest Sudoku" (HARDEST.SUD on the distribution ATR) is reduced from 107.5 seconds to 69.2 seconds (Altirra v2.60, PAL). The distribution ATR now auto-runs the program (AUTORUN.SYS is a copy of SUDOKU.XEX) and, for comparison, version 0.3 (SUDOKU03.XEX) is also present. As before, this has been tested under emulation only. Jeremy Sudoku-0.4-Distribution.atr.zipSudoku-0.4-Source.zip

Also, thanks to Rob from the excellent Player/Missle podcast for featuring this as a listener written program in the latest episode (#12). Jeremy

Here is a link to a little program I wrote recently for the Atari 8 bit line. http://duckology.co.uk/code/01/index.html An ATR containing the program and a few test cases is available for download, as is the 6502 source code (MADS syntax). I've also (hopefully) managed to attach them to this post. For documentation, please use the link above. One word of warning / apology; I neither own nor have access to real hardware, so it has only been tested under emulation. Jeremy Sudoku-0.3-Source.zip Sudoku-0.3-Distribution.atr.zip

I don't have access to my Mac right now, but from memory the process I used was more or less what is in the documentation, as follows: Extract the downloaded archive to a directory. Change to that directory, then issue commands below make sudo mkdir /usr/local/bin (if /usr/local/bin does not already exist) sudo make avail I didn't have to specify the compiler to use, the make process just defaulted to gcc (I guess). The third command will just make symbolic links in /usr/local/bin, but will fail unless /usr/local/bin already exists, which it did not on my clean install of Mavericks. Jeremy (used CC65 to prototype one project!)

I had a similar problem building cc65 on a clean install of Mavericks, but it worked on an upgrade from Snow Leopard. In the end I noticed that /usr/local/bin was missing despite being referenced in the path. I created the directory using "sudo mkdir /usr/local/bin" and the build/install then worked. I also noticed that the HTML documentation did not build because of a missing package. So I just extracted the HTML documentation from the prebuilt Windows package. Jeremy