Sudoku

[NE146]

I know you've been working on finalizing the display kernel, etc... But just out of curiousity, will the game have a timer?

 

Sudoku more of a "how fast can you finish" type of puzzle than anything.. so just wondering

[SeaGtGruff]

It doesn't work on my computer (I use Stella, should I get z26 or does that have nothing to do with it?)

 

The emulators don't seem to auto-detect the ROM type.

 

Unfortunately, they don't.

 

For Stella: hit TAB, select "Game Properties", change Cart Type to "E7 (16K M-Network)", then "OK", then "Exit Menu", then hit \ and select "Reload ROM".

For Z26: Start using the -g7 flag, e.g. z26 -g7 Sudoku.bas.bin

 

Chris

 

Just to be sure everyone understands, you hit TAB *after* you start the bin. Also, once you've set the game properties, Stella will save them and remember them after that-- unless the bin changes, such as if a new build is released that doesn't match the binary image of the earlier build. So once there's a final release, you can set the game properties and never have to reset them. But in the meantime, whenever I post a new build, you'll most likely need to set the game properties again.

 

Speaking of which, does anyone know some decent properties to use for PAL games? I tried the PAL build on stella, but when I set the game properties, Stella just kept exitting and shutting down when I tried to start up the Sudoku PAL build.

 

Michael Rideout

[SeaGtGruff]

I know you've been working on finalizing the display kernel, etc... But just out of curiousity, will the game have a timer?

 

Sudoku more of a "how fast can you finish" type of puzzle than anything.. so just wondering

 

Yes, I've thought about having an optional timer. The plan is to have different difficulty levels, so there ought to be variations in the game play based on difficulty, besides just the difficulty of the puzzles that are generated. For example, in the higher/est difficulty level, certain functions might not be available, such as the ability to click on a row or column and say "show me all the cells where such-and-such a digit might possibly fit" (i.e., by putting a digit in one of the cells in the extra row or column). So a timer would be a good option for the higher/est skill levels. Who knows, the final game may even be like the early 2600 games that had dozens of different variations. For example, if there were, say, 8 different selectable options, that would give 256 variations (assuming that none of the options are mutually-exclusive). I don't know how many different options I can think of, but we'll see. For example, one option might be whether the "scratch-work dots" in the available cells show which digits possibly *could* go there, or which digits could definitely *not* go there, since there seem to be people who use either method when they're solving Sudoku puzzles.

 

Michael Rideout

[+atari2600land]

Have you still been working on this game? That'd be cool. Please make the timer optional because I'm a newbie at sudoku, and I like this cool number puzzle, and I really like the fact that this can be done on the 2600 and someone is actually working on it for the 2600. The last post being July 17th is making me a little worried, especially since new build ROMs have been so frequent.

[SeaGtGruff]

Have you still been working on this game? That'd be cool. Please make the timer optional because I'm a newbie at sudoku, and I like this cool number puzzle, and I really like the fact that this can be done on the 2600 and someone is actually working on it for the 2600. The last post being July 17th is making me a little worried, especially since new build ROMs have been so frequent.

Yes, I've still been working on the game, albeit I took a little break on it for about a week. The latest NTSC build is posted below, but I have to make some major adjustments to it. As you move around the grid with the joystick, you can now press the fire button to choose a cell, then push up or down on the joystick to increase or decrease the number in that cell, then press the fire button again when you have put the desired number in the cell. However, this makes the screen flash, because of the time it takes to update the screen RAM each time you change the number in a cell (even though the only cell being updated in RAM is the one you've selected). I plan to split that routine in two, with the first part (checking the joystick and updating the zero-page RAM) taking place during overscan, and the second part (updating the screen RAM for the new number) taking place during vertical blank. And if more than one cell needs to be updated (e.g., if you put a number in the extra row or column so you can check which cells in a given row or column could possibly hold a particular number), I'm guessing the kernel will end up having to process one cell per field, or something like that. Right now there's no logic to ensure that you can't change a given cell, or to process the entries in the extra row, column, and corner cell. And I expect to have to optimize the RAM-fill routines so they're tighter as far as the timing goes-- or convert them to pure assembly so there's no redundant code as can happen with compiled bB statements. Anyway, I wasn't going to post anything new until I had done a little more on it, but then again, the idea was to show it progressing, so...

 

I made more changes to the 2600basic.h file, to add some more "alphabet" style variables (aa, bb, cc, etc.), so I'm posting that file again. The other includes are unchanged, so I'm not reposting them.

 

Michael Rideout

 

Sudoku.bas

Sudoku.bas.bin

2600basic.zip

[+atari2600land]

Very very very nice!

The fire button still needs some tweaking to know if it's been pressed or not (i don't know if that's possible, i'm just saying if i press it, it might not know that it's been pressed and will allow me to change the number.), although the up/down arrows to change the numbers work fine. Is it possible (Is there enough memory) to include a random puzzle generator?

[SeaGtGruff]

Very very very nice!

[elvis_voice]

Thank you very much!

[/elvis_voice]

 

The fire button still needs some tweaking to know if it's been pressed or not (i don't know if that's possible, i'm just saying if i press it, it might not know that it's been pressed and will allow me to change the number.), although the up/down arrows to change the numbers work fine.

I know, the joystick-reading routine needs a lot of work. I really haven't done much with it, except that I'd added a "debounce" counter in an earlier build to keep the joystick from "sticking"-- e.g., if you press the fire button, but don't let up quickly enough, the game might process it as pressing the fire button several times in a row, so you might end up in "change the number" mode, or you might end up in "move the cursor" mode-- or, if you want to move to the left one cell, you might push left on the joystick and find yourself ending up four cells to the left instead of only one cell to the left. The "debounce" logic is pretty simplistic right now, not nearly what it needs to be, but I was working on other things and leaving it for later to tweak the "debounce" logic.

 

Is it possible (Is there enough memory) to include a random puzzle generator?

Yes, there will definitely be a random puzzle generator. For the time being I'm going to just leave the predetermined puzzle in the game while I work on the game-play logic. Then, once I have the main game functions working-- meaning the ability to put numbers in the cells, look for possible cell values using the extra row and column and corner cell, clearing the grid (except for the givens) so you can start over from scratch, checking the moves to be sure they're valid, etc.-- then I'll start working on the random puzzle generator. The final phase will be things like adding music or whatever, adding the ability to customize the colors or fonts, etc.-- but that stuff is still a long way down the road.

 

Michael Rideout

[jbanes]

I know, the joystick-reading routine needs a lot of work. I really haven't done much with it, except that I'd added a "debounce" counter in an earlier build to keep the joystick from "sticking"-- e.g., if you press the fire button, but don't let up quickly enough, the game might process it as pressing the fire button several times in a row, so you might end up in "change the number" mode, or you might end up in "move the cursor" mode-- or, if you want to move to the left one cell, you might push left on the joystick and find yourself ending up four cells to the left instead of only one cell to the left. The "debounce" logic is pretty simplistic right now, not nearly what it needs to be, but I was working on other things and leaving it for later to tweak the "debounce" logic.

I think it would work better if you changed the controls to increment the value when the fire button is pressed. This would probably be a bit easier than the modal interface you have now.

 

In psuedo-logic:

 

let pressed = 0

if joy0fire AND pressed == 0 then IncrementValue 
if joy0fire then pressed = 1
if !joy0fire then pressed = 0

 

That should cause the value to only be incremented when the fire button is first pressed, then ignored on subsequent frames. It will also allow the player to increment the value as fast as he can press the fire button.

 

Alternatively, you could allow taps of the joystick to do the same thing while the fire button is held down. This would allow the value to be incremented or decremented, rather than forcing it to move only one direction.

[SeaGtGruff]

I think it would work better if you changed the controls to increment the value when the fire button is pressed. This would probably be a bit easier than the modal interface you have now.

 

In psuedo-logic:

 

let pressed = 0

if joy0fire AND pressed == 0 then IncrementValue 
if joy0fire then pressed = 1
if !joy0fire then pressed = 0

 

That should cause the value to only be incremented when the fire button is first pressed, then ignored on subsequent frames. It will also allow the player to increment the value as fast as he can press the fire button.

 

Alternatively, you could allow taps of the joystick to do the same thing while the fire button is held down. This would allow the value to be incremented or decremented, rather than forcing it to move only one direction.

Thanks for the ideas! I was thinking of saving the joystick's last value, and comparing the current value to the last value to see if it changed before doing any "debounce" logic, but your way looks cleaner.

 

Also, I think you may have missed something about incrementing or decrementing the numbers, as you can already do that. Up = increment, and down = decrement. I thought of doing the same thing with left and right (left = decrement, right = increment), but then I decided I didn't want to worry about situations where there would be a conflict-- i.e., left+up or down+right, which would conflict (should it increment or decrement the number?).

 

I'm definitely going to keep a modal interface, as far as there being a "move the cursor" mode and a "change the number" mode. In fact, I'm expecting to add more modes or states, for when the program needs to change an entire row or column of cells one after the other, such as turning the dots on or off in the cells to indicate whether a given digit could potentially be placed inside each of the cells in that row or column. I think the program is going to have to process one cell per field, or maybe a couple of cells per field, because otherwise the time required to update the screen RAM is probably going to exceed the overscan or vertical blank time period (as is already happening now when changing just one cell per field-- although I'll be the first to admit that the code can certainly be tightened up where updating the screen RAM is concerned).

 

Michael Rideout

[jbanes]

Also, I think you may have missed something about incrementing or decrementing the numbers, as you can already do that. Up = increment, and down = decrement. I thought of doing the same thing with left and right (left = decrement, right = increment), but then I decided I didn't want to worry about situations where there would be a conflict-- i.e., left+up or down+right, which would conflict (should it increment or decrement the number?).

No, I understood. My alternative suggestion was to be in the number switch mode ONLY while the fire button was pressed. i.e. If I tap the button, nothing happens. If I move the joystick, the cursor moves. If I hold the fire button and press up on the stick, the number increments. If I hold the fire button and press down on the stick, the number decrements. The moment I let go of the button, the stick again moves the cursor.

 

This differs from what you're doing right now. When it works, your current code locks the user into either number changing mode or cursor mode. A tap of the fire button is required to change modes. In my suggestion, you would have to hold the button instead.

[SeaGtGruff]

No, I understood. My alternative suggestion was to be in the number switch mode ONLY while the fire button was pressed. i.e. If I tap the button, nothing happens. If I move the joystick, the cursor moves. If I hold the fire button and press up on the stick, the number increments. If I hold the fire button and press down on the stick, the number decrements. The moment I let go of the button, the stick again moves the cursor.

Oh, okay, I understand you now.

 

I don't know, I'm kind of fond of the modal approach. For one thing, I'm planning on processing the changes in the extra row and column only after the player has "locked in" the digit by pressing the fire button. That is, if you position the cursor in the extra row, then press the fire button to enter the "choose a digit" mode, you can scroll through the digits until you get the one you want, without the kernel going crazy trying to update the screen RAM with dots for each digit that you scroll past. Then, when you have the digit you want to check for, you press the fire button to tell the game "I'm done with my selection, you can check the board now and show me which cells could potentially have this digit in them."

 

Here's another build, basically identical to the last one, except this one lets you pick between NTSC (262 lines) or PAL/SECAM (312 lines), based on the TV switch. Color chooses NTSC, whereas B&W chooses PAL/SECAM. The palette doesn't change yet, so trying this on an actual PAL Atari is likely to give you some ugly colors. I'm thinking of changing the default palette based on the TV switch, but I haven't tried to do that yet, since the palette is going to (eventually) be user-selectable anyway.

 

By the way, can anyone tell me about the SECAM Atari? Isn't it basically the same as the PAL Atari, except that the Color/B&W switch is permanently wired into the B&W position, or something like that? I'm hoping that's right, since I want to use that switch to control the number of lines per screen.

 

Michael Rideout

Sudoku.bas

Sudoku.bas.bin

Edited July 27, 2006 by SeaGtGruff

[+atari2600land]

It's been about a month. Please tell me you're still working on this game.

[SeaGtGruff]

It's been about a month. Please tell me you're still working on this game.

Yes I am, but no I haven't been. Or vice versa? What I mean is, it's still alive, but I reached a point where I felt I had to resolve a certain issue, namely where tasks need to be performed but they take longer than the overscan period, or longer than the vertical blank period, which means they cause the screen to roll. How to handle that? I had thought about trying to break the tasks up into discrete portions, and have one portion run during overscan, the next portion runs during vertical blank, the next portion runs during the next overscan, then the next vertical blank, etc., until all portions have been performed. This would mean that the whole task takes a lot longer to execute, but the game stays on the screen and stays updated as the task is being performed-- for example, put a 7 in the extra cell in the upper left corner, and boom, you get to see 7s being put into all the cells of the extra row and extra column, then boom, you get to see the dot that represents 7 get added (or removed, as appropriate) from each individual available cell in the grid, one after the other. The alternative is to just "turn off" the screen display, perform the task all at once as quickly as possible, then turn the screen back. This is actually a reasonably common trick in computer programs where you can get more processor speed (or processor time) by turning off the screen, then doing whatever calculations you are needing to do, then turning the screen back on when you're done. Obviously, there are times you would *NOT* want that to happen-- like in the middle of Millipede, you wouldn't want the screen to go blank for a fraction of a second, or maybe even for a second or two, while the Atari plots out all the updated positions and graphical shapes of the bugs on the screen. But in a game like Sudoko (or chess, or checkers, or something like that), it's not too horrendous to turn off the screen for, say, a tenth of a second so you can do a bunch of intensive calculations or RAM-filling stuff. I mean, the screen will "blink" or something like that, which is annoying if it happens all the time. But if it happens only once in a while, and usually lasts for no longer than a sixtieth or thirtieth of a second, it's probably going to be a lot more bearable. So that's where I am/was right now-- trying to work out the way that I want that to work, and then trying to make it work that way! But in the middle of scratching my head over that, I also wanted to get back into my bB tutorial, and then some fiendishly villainous devil suggested Millipede for the High Score Club-- one of my favorite Atari 2600 games of all time, and one that I can't stop playing once I start-- so that pretty much tied me up for that whole week! Anyway, I have been planning to post a new bB tutorial entry this week, then post some progress on Sudoku this weekend-- plus I am working on a text kernel for someone, and I want to get back into Reventure again, all in that order. And that is in addition to my "real" life.

 

MR

[supercat]

Yes I am, but no I haven't been. Or vice versa? What I mean is, it's still alive, but I reached a point where I felt I had to resolve a certain issue, namely where tasks need to be performed but they take longer than the overscan period, or longer than the vertical blank period, which means they cause the screen to roll. How to handle that?

 

The approach I use in SDI and Strat-O-Gems is to load TIM64 with a value 125 greater than the number of ticks I want. During my computations, I have many instances of:

hcheck_loop: ; Check for horizontal groups of gems
 bit INTIM
 bmi hcheck_nokernel
 jsr kernel
hcheck_nokernel:
 ...

My kernel routine (which handles both vsync and the main screen) waits for INTIM to count down to 125 (in some versions, it puts up an error display if INTIM is already below 125 when the kernel is invoked). In this way, I don't have to particularly worry about trying to partition tasks into vsync-sized pieces. I just ensure that I check INTIM at least once every 128 cycles. The overhead is significant, but hardly crippling, and it means I don't have to worry about pieces of code that take variable amounts of time to execute.

Edited August 23, 2006 by supercat

[SeaGtGruff]

The approach I use in SDI and Strat-O-Gems is to load TIM64 with a value 125 greater than the number of ticks I want. During my computations, I have many instances of:

hcheck_loop:; Check for horizontal groups of gems
 bit INTIM
 bmi hcheck_nokernel
 jsr kernel
hcheck_nokernel:
 ...

My kernel routine (which handles both vsync and the main screen) waits for INTIM to count down to 125 (in some versions, it puts up an error display if INTIM is already below 125 when the kernel is invoked). In this way, I don't have to particularly worry about trying to partition tasks into vsync-sized pieces. I just ensure that I check INTIM at least once every 128 cycles. The overhead is significant, but hardly crippling, and it means I don't have to worry about pieces of code that take variable amounts of time to execute.

I had read a comment you posted in some other thread-- I think it was in the Ladybug thread?-- in which you referred to something like that, and I thought it was very interesting, because I'd already been thinking of trying something like that in Sudoku, but I wasn't sure how to go about it. I must admit that I haven't fully digested your explanations yet, but I think that's the sort of approach I'll need to use in Sudoku.

 

At present, I've allowed for two or three sections of time when housekeeping can be performed-- the "overscan" (or vertical front porch), the "vertical blank" (or vertical back porch), and to a much lesser extent the vertical sync (although I'm going to restrict vertical sync routines to brief tasks like polling the console switches or incrementing the field/frame counter). However, I've been planning to add another section of time for the active scan lines between the extra row and the top of the grid, because those scan lines don't have anything on them (unless I add a timer display there), hence I could be using that time to do various things. Right now I'm just using WSYNC to display a certain number of empty lines, but I could set the timer instead.

 

I'm currently processing the joystick and updating the RAM bitmap for the selected cell during the vertical back porch, but the screen rolls because the RAM update takes too long. Two things I can do are to move the joystick processing into the vertical front porch, and then do the RAM update during the vertical back porch, as well as to rewrite the RAM update routines to use pure 6502 assembly code rather than bB statements, which should help optimize the timing a lot more. So it isn't really the updating of a single cell that's got me stuck.

 

Rather, it's the tasks which will involve a lot of cells, such as checking all of the cells in a given column to see which ones could potentially contain a given value, or checking the value which the user has set a cell to, to see if that value is acceptable for that cell (i.e., has it already been used in the given column, or in the given row, or in the given 3x3 zone?). For those sorts of tasks, it might be best to temporarily turn off the screen display, so that all of the processing time can be devoted to performing the task as quickly as possible. I haven't decided how I want to handle that sort of thing yet, so I've sort of let Sudoku percolate on the back burner for several weeks until I come up with a clear plan of attack.

 

I've actually been thinking of going ahead and starting on programming the more sophisticated routines without worrying about timing issues, just to bang out the initial logic before settling on a final approach, and let the screen roll or blink or do the watusi for now. For example, I haven't even tried to think about random puzzle generation yet, and in fact I'll probably code a puzzle input mode first, for entering a puzzle from a newspaper or magazine. Having random puzzles is a must, but a large part of what I want to accomplish is having the game serve as a kind of scratchpad for solving puzzles from newspapers, magazines, or books, since working a puzzle on paper can get messy, and it would be so much nicer to set the puzzle up on the 2600 to work on it.

 

MR

[SeaGtGruff]

plus I am working on a text kernel for someone

As I said, I'm tinkering with a text kernel for someone. I had hoped to use flickering venetian blinds for that, by shifting the players left 8 and then right 8 on alternating scan lines (and on alternating fields), to get a 24-column text area akin to Dark Mage or Stellar Track (where a "column" equals the width of a playfield pixel, or 4 color clocks). However, I wanted to center the text area on the screen, and based on my preliminary attempts, I don't think that's doable; it looks like the only way to do it is to have the text area on the left side of the screen (as in DM and ST). As far as I've been able to tell so far, a centered text area would have to use the same kind of flickering as I'm using in Sudoku-- flickering columns, rather than flickering venetian blinds.

 

My text kernel will use bitmapped text, rather than character-based text, since the characters will be between 2 and 6 pixels wide (counting the blank pixels between letters), rather than 8 pixels wide. This will use more ROM, and will require indirect Y addressing, but will permit more attractive letters with proportional spacing rather than fixed spacing. For example, "AtariAge" might look as follows:

 

 

MR

[supercat]

Rather, it's the tasks which will involve a lot of cells, such as checking all of the cells in a given column to see which ones could potentially contain a given value, or checking the value which the user has set a cell to, to see if that value is acceptable for that cell (i.e., has it already been used in the given column, or in the given row, or in the given 3x3 zone?). For those sorts of tasks, it might be best to temporarily turn off the screen display, so that all of the processing time can be devoted to performing the task as quickly as possible. I haven't decided how I want to handle that sort of thing yet, so I've sort of let Sudoku percolate on the back burner for several weeks until I come up with a clear plan of attack.

 

Strat-O-Gems has to do a lot of processing to search for matches--more than I would expect Sudoku to be doing for anything except puzzle-creation or depth-first solving, and yet things happen plenty fast. Dropping Vsync while you're computing is really ugly on a real system; blanking the screen while keeping Vsync isn't quite as bad, but it's still not pretty.

 

Maybe I need to clean up my "starting skeleton" code and post that; that should make things much clearer.

[Tom]

However, I wanted to center the text area on the screen, and based on my preliminary attempts, I don't think that's doable; it looks like the only way to do it is to have the text area on the left side of the screen (as in DM and ST).

 

Nah, it's definitely possible. Proof: http://www.pouet.net/prod.php?which=13900.

Can't seem to find the source. Feel free to disassemble the binary. Locating sixchar routines (which is what a 12char basically is) is generally simple, just look for code that bashes the GRPx registers.

 

Btw, the Stellar Track kernel is interesting because iirc it doesn't move the sprites +/- 8 pixels. It moves +/- 7 pixels and does the missing adiditonal pixel by shifting the graphics data before writing it to the registers. This in turn works because the characters are only 7 pixel wide. You can't use this trick if you need 8 pixel wide columns, but the early HMOVE trick is way cooler anyway and not harder to implement.

[SeaGtGruff]

However, I wanted to center the text area on the screen, and based on my preliminary attempts, I don't think that's doable; it looks like the only way to do it is to have the text area on the left side of the screen (as in DM and ST).

 

Nah, it's definitely possible. Proof: http://www.pouet.net/prod.php?which=13900.

Can't seem to find the source. Feel free to disassemble the binary. Locating sixchar routines (which is what a 12char basically is) is generally simple, just look for code that bashes the GRPx registers.

 

Btw, the Stellar Track kernel is interesting because iirc it doesn't move the sprites +/- 8 pixels. It moves +/- 7 pixels and does the missing adiditonal pixel by shifting the graphics data before writing it to the registers. This in turn works because the characters are only 7 pixel wide. You can't use this trick if you need 8 pixel wide columns, but the early HMOVE trick is way cooler anyway and not harder to implement.

I tried the +/- 7 technique first, and even shifted the data for the digits *before* loading (i.e., they were stored in the ROM that way), but I ran into timing issues anyway, since I'm also displaying the missiles, ball, and playfield, so I need to update them as well. If it weren't for that, it would have worked. However, I think that was still when I was trying to use the playfield for the background of the given cells, instead of using inverse characters, so if I try again I *might* be able to do it all in the time needed. Thanks for the reminder!

 

As for my comment about not being able to center text with flickering Venetian blinds, that was while displaying characters directly from ROM, and now (in that text kernel) I'm going for moving a row of characters into RAM instead. Six 8-line tall characters require 48 bytes of RAM, which can be fit into zero-page RAM, then you just need to load the RAM between rows for the next group of characters, so centering the text there might be doable, too.

 

MR

[idavis]

Hey guys, new to the forum. As a coincidence, I have been programming a Sudoku game for the 800, on my original 800. I am using Synassembler. I have been toying with the idea of contacting Albert about working with him and making a run of carts. As of now, I have the game loop programmed, and as of last night, it's officially a working game with score and all. I need to work on a splash screen and maybe some flashier graphics, and definitely the ability to change options like difficulty. So far I am sitting a 6k, and have some code I can consolidate and remove altogether. I do have worknig 6502 code to generate a puzzle, and also have been able to store a working "complete" puzzle in 48 bytes.

 

I guess my question is, since this thread is for a 2600 version, should I start a thread for my 800 version. I want to ask some questions like: Should I just button it up and release it to the wild? Try and make a run of cartridges?

 

It's been a dream of mine since I was 12 to write a game and put it on a cart. Personally, I will be able to do this when I am satisfied with the code, as I have an eprom burner, some eproms, and a board waiting.

 

So will conversation of my game splinter this thread too much? Your thoughts.

Isaac

[SeaGtGruff]

Hey guys, new to the forum. As a coincidence, I have been programming a Sudoku game for the 800, on my original 800. I am using Synassembler. I have been toying with the idea of contacting Albert about working with him and making a run of carts. As of now, I have the game loop programmed, and as of last night, it's officially a working game with score and all. I need to work on a splash screen and maybe some flashier graphics, and definitely the ability to change options like difficulty. So far I am sitting a 6k, and have some code I can consolidate and remove altogether. I do have worknig 6502 code to generate a puzzle, and also have been able to store a working "complete" puzzle in 48 bytes.

 

I guess my question is, since this thread is for a 2600 version, should I start a thread for my 800 version. I want to ask some questions like: Should I just button it up and release it to the wild? Try and make a run of cartridges?

 

It's been a dream of mine since I was 12 to write a game and put it on a cart. Personally, I will be able to do this when I am satisfied with the code, as I have an eprom burner, some eproms, and a board waiting.

 

So will conversation of my game splinter this thread too much? Your thoughts.

Isaac

This forum is about homebrews, not 2600 homebrews, so there's no reason why you can't discuss your Sudoku game in this thread. However, you might want to start a separate thread in this forum for your game, maybe calling it "Sudoku 800." And I can rename this thread to "Sudoku 2600." That way, it will be easy for everyone to tell the threads apart.

 

I think you should have cartridges made of your finished game, but you might want to consider posting the ROM image for people to play before you do-- or maybe just release it to a few select play testers-- because they might help you uncover any bugs, or give you feedback that could lead to suggestions for more features or enhancements you might want to add before producing actual cartridges.

 

MR

[idavis]

Thanks for the quick reply. I will post up a new thread. I have spent most of my time coding in a routine to generate a working puzzle. I have it to where I can store a complete puzzle in 48 bytes, with the routine to gen up the puzzle. I have also left in the code to generate one on the fly, which is funny, since it can take anywhere from about 5 seconds to minutes to generate a 'legal' puzzle on the 800, at least using my routine. I was shocked to find that I could get 80% complete on building a puzzle, and find out that it's impossible to complete the build. When you get to where you start gen'ing up a puzzle, I can possibly help with some 6502 assembler to assist.

Thanks,

Isaac

[+atari2600land]

Mike, whatever happened to the 2600 Sudoku version you were working on? Are you still working on it?

[SeaGtGruff]

Mike, whatever happened to the 2600 Sudoku version you were working on? Are you still working on it?

It's on hold for now while I finish up the E.T. Book Cart, then I'm going back to work on Sudoku 2600 and the bB tutorial.

 

MR

[Nognir]

Is the Sudoku game still on hold?

 

ET Book Cart is finished and maybe the Tutorial also.

I would be very happy if this game would get an official Release

Edited March 14, 2007 by Nognir