Jump to content
IGNORED

Sudoku


SeaGtGruff

Recommended Posts

I was very hesitant to reveal the name of this game, because it has such a strong following, and I don't want to get everyone's hopes up unreasonably high. I was thinking of calling it "Undisclosed Atari 2600 game," but sooner or later it would have become obvious what it is, so there doesn't seem to be any real reason to be secretive about it. I'm not sure if it will get entered into the 2006 contest, but just in case, I'll post my progress on it in this thread. It's going to be developed in a mixture of batari BASIC and in-line assembly, but the final version may end up being coded in pure assembly.

 

In this first installment, all I did was create the beginnings of a custom kernel that uses flickering Venetian blinds, and try to get the players positioned more or less correctly. There's really nothing to see yet-- it isn't even colorful, just bleah. This was actually written Monday night. I didn't get to work on it last night, because I went to the 10 PM advance showing of "Superman Returns," and didn't get home until about 1 AM! :) I hope to post another installment later tonight, but it will mostly be tweaks to the basic kernel.

 

Michael Rideout

 

post-7456-1151544396_thumb.jpg

Sudoku.bas

Sudoku.bas.bin

Link to comment
Share on other sites

Okay, here is build number 2. It's still nothing much to look at, but you can at least see the grid beginning to take shape. I redid the basic kernel a bit, putting it inside the main loop, instead of calling it from a gosub. I split the kernel into two bB sections (overscan and vertical blank) and two assembly sections (vertical sync and active video). I moved the player positioning into the vertical sync section. And I'm now using INTIM to wait for the proper moment to begin the vertical sync and the active video, instead of using WSYNC for every line.

 

In these earliest builds, I'm not going to worry about any game logic per se, because the first order of business is to get the basic framework of the kernel ironed out. And I should point out that so far the kernel is strictly for NTSC, but I'll be adding PAL/SECAM support eventually-- which will be very simple, since it should mostly be a matter of sticking different values into TIM64T. Anyway, I'll try to be sure that there are visible changes in these early builds, so that you can see the board taking shape. And I expect to be using extra RAM, because I seriously doubt that 128 bytes will be enough.

 

Michael Rideout

 

post-7456-1151553272_thumb.jpg

Sudoku.bas

Sudoku.bas.bin

Link to comment
Share on other sites

Finally, a Sudoku game for 2600! How many different puzzles will be in it?

 

"Finally," nothing! :) It's got a lllloooonnnngggg way to go yet! And it still remains to be seen whether it can be achieved within the restrictions of the 2600.

 

I'm not sure about the number of puzzles. My plan includes having an "input" mode, where you can enter a puzzle from a newspaper or book and work on it, even saving games on a MemCard. And I certainly would like to have some puzzles built into it, and hopefully the ability to generate random puzzles (if I can work out a decent algorithm for that).

 

It's all still very much in the planning and experimenting stages. Right now I'm strictly focused on getting the basic display worked out.

 

Michael Rideout

Link to comment
Share on other sites

Build number 3, which is the last one for tonight. I've got the basic grid, although it still needs a lot of tweaking. Right now I'm using loops, but I'm 99% certain that I'll have to "unroll" the kernel a bit for an actual working display, and the addressing modes of the LDA instructions aren't right yet.

 

I'm including two screenshots this time, one with just empty boxes, and one with the digit "1" in all of the boxes. As you can see, the basic grid still needs a lot of work. And some of the lines are going to disappear. There will be a 9x9 grid for the actual puzzle, plus an extra row above the grid, and an extra column to the left of the grid, plus an extra box in the upper left corner. The extra row and column will be used in solving the puzzle-- i.e., if you put a "1" in one of the boxes in the extra row, then you'll be shown all of the boxes in that column of the grid which could possibly contain a "1." That may sound a little confusing, but it should become clear as the game screen continues to take shape and I can eventually post screenshots showing what a game in progress might look like.

 

Michael Rideout

 

post-7456-1151566519_thumb.jpg

 

post-7456-1151566551_thumb.jpg

Sudoku.bas

Sudoku.bas.bin

Link to comment
Share on other sites

Extremely impressive, I wouldn't even know where to begin creating a display that advanced. Proof positive that bB and asm definately do mix, and I know I'll enjoy following the development as well as the final bin.

 

So thanks for the WIP thread, and doing something besides a chase/be chased game. Also thanks for always offering help in my threads, maybe someday I'll be on a level to return the favor.

Link to comment
Share on other sites

I meant 'Finally, someone is working on a Sudoku game for the 2600.' Seeing as how you only have the grid done, I know you would have a long way to go with numbers, recognizing which go where, not repeating any in a 3x3 area or a line, etc. You do know a Sudoku grid is only 9x9, right?

Edited by atari2600land
Link to comment
Share on other sites

You do know a Sudoku grid is only 9x9, right?

 

Yep, I sure do! Here's a mockup I drew in MS Paint to show the general direction I'm headed in. There's a 9x9 grid, with some brighter/bolder lines to separate it into nine 3x3 grids. Then there's an extra row above the grid, and an extra column to the left of the grid, with an extra box in the upper left corner. The squares that are already filled in with numbers (i.e., when you first start out) will have a different background color or shade than the empty squares or squares that you've filled in, and the numbers in those "pre-filled" squares will be brighter. The squares in the extra row, extra column, and in the corner will be used to help solve the puzzle, as shown. For example, if you put a "1" in a square in the extra row at the top, then any square in that column which could possibly be filled in with a "1" will get a tiny dot in it, in the position that would represent the number "1." Or, if you put a "5" in a square in the extra column to the left, then any square in that row which could possibly be filled in with a "5" will get a tiny dot in the position that represents the number "5." The extra square in the upper left corner will be used to check all rows and all columns at the same time. And besides being able to check for individual numbers (whether in a specific row or column, or all across the board), there will be an extra symbol of nine dots, which means "check for all digits at once"-- either in a specific row or column, or all across the board. Within the actual playing grid, any dots in a particular square will indicate that those numbers could possibly go in that square, where the position of the dots within a square represents what numbers they are-- i.e., the dots will have a 3x3 arrangement, as shown in the upper left corner square in this mockup. following the same pattern as the buttons on a telephone:

 

1 2 3

4 5 6

7 8 9

 

Michael Rideout

 

post-7456-1151603609_thumb.jpg

Link to comment
Share on other sites

I don't really see why Sudoku can't be done on a 2600 - you only need 20.5 bytes to store the board.

 

Glad to see this being done! :thumbsup:

 

Did you mean to say 40.5 bytes? If there are nine digits-- but some squares are empty, so let's call it ten digits (0 for "empty"), then with BCD it would take 81 nybbles, or 40.5 bytes. And I'll have additional bytes for storing whether a particular square was pre-filled, in which case that square will have a different background color, and the number in the square will be brighter. And if I store the numbers in the extra row and column (plus in the corner), and have an eleventh value to indicate "nine dots" (for "check all nine digits at once"), then I'll need 100 nybbles (50 bytes) for the board, plus another 81 bits (10 or 11 bytes) to store the "pre-filled" indicators-- 60 or 61 bytes in all just for the grid data, and that doesn't include any other variables needed for game play or game settings. So yes, I think it can be done, but it could get scrunchy, plus the timing may be difficult. For example, right now I'm shifting the players left and right 7 pixels from one row to the next, but I may not have time to do that in the actual working kernel; I may need to do the left-right shift between frames rather than between rows.

 

Michael Rideout

Link to comment
Share on other sites

I don't really see why Sudoku can't be done on a 2600 - you only need 20.5 bytes to store the board.

 

Glad to see this being done! :thumbsup:

 

Did you mean to say 40.5 bytes? If there are nine digits-- but some squares are empty, so let's call it ten digits (0 for "empty"), then with BCD it would take 81 nybbles, or 40.5 bytes. And I'll have additional bytes for storing whether a particular square was pre-filled, in which case that square will have a different background color, and the number in the square will be brighter. And if I store the numbers in the extra row and column (plus in the corner), and have an eleventh value to indicate "nine dots" (for "check all nine digits at once"), then I'll need 100 nybbles (50 bytes) for the board, plus another 81 bits (10 or 11 bytes) to store the "pre-filled" indicators-- 60 or 61 bytes in all just for the grid data, and that doesn't include any other variables needed for game play or game settings. So yes, I think it can be done, but it could get scrunchy, plus the timing may be difficult. For example, right now I'm shifting the players left and right 7 pixels from one row to the next, but I may not have time to do that in the actual working kernel; I may need to do the left-right shift between frames rather than between rows.

 

Michael Rideout

Errr, yes, yes I did mean 40.5. :dunce:

 

And ~60 bytes is nothing, man. :)

Link to comment
Share on other sites

New build. I worked a little on reorganizing the kernel on Thursday night, but wasn't ready to post anything, then I was busy with other things on Friday and Saturday. The current build isn't really at a point yet where I feel comfortable posting it, but the idea is to show my progress on the game, so...

 

I changed the kernel so it doesn't shift the players left-right from line to line; they're stationary for each frame. I also moved the positioning of the players to just after where the title will be, since they'll be positioned differently for the title (i.e., close together, like a score display).

 

I added missiles to get the brighter lines for separating the 9x9 grid into nine 3x3 zones, but as you can see, I still need to work on that as far as the vertical divisions are concerned-- which will entail turning the missiles on and off at the appropriate times on each line.

 

I still need to remove two extra columns on the left-- i.e., if we number the columns from 1 to 12 going left to right, then columns 1 and 3 will be taken out, leaving column 2 for the "extra column" that will be used in playing the game, and leaving columns 4 through 12 for the game grid itself.

 

Plus, I haven't tried to load the data for each cell yet; I'm just displaying a particular digit all the way across on a given row. I'm still thinking about how the board data will be stored (see below), and the solution I pick is probably going to be a major determining factor in how the actual lines are coded.

 

I made the digits smaller, to leave more of a gap between the digits and the walls of the cells.

 

Furthermore, I've added a background using the playfield, but that's going to change a lot, because the idea is that only the "given" or "pre-filled" cells will have a background. The reason I'm showing the background right now is to help me see that the board is centered the way I want it.

 

So quite obviously, I still have a LONG way to go on the display kernel before I can start working on the game play logic.

 

I expect to have to split the kernel in two, so that each frame has its own kernel, because the timing of the loads and stores is going to have to be so precise on the lines, and the timing will be different for each frame. I'll have to load and store the players, missiles, playfield, and ball (the ball will be the "cursor" which moves around using the joystick, to let the player select cells or game actions).

 

I want to have a grid of dots in the unfilled cells, to indicate which digits can be placed in which cells, but if any given dot can be on or off, that is 512 combinations (2^9), which is too much to deal with using just 128 bytes of RAM. The only solution that seems feasible (other than tossing out the dots) is to put the display data in RAM, which I figure will take at least 800 bytes of RAM (8 bytes per cell, with 100 or 10x10 cells in all). So my options seem to be to use M-Network bankswitching with 2K expansion RAM, or use a newer bankswitching method that has even more RAM (like supercat's). The trouble is, I don't know how easy or feasible it will be to manufacture M-Network-style carts, and I don't think supercat's cartridges are finalized and available yet. Anyway, if I put the actual display data for each cell in RAM, and modify the RAM data as needed while the game is being played, then I can have any combination of dots and/or numerals that I want.

 

As far as game options, I'd like to have different difficulty levels, which would determine how easy or hard a random;y-generated game will be, and it may also determine whether certain functions are available (e.g., the harder difficulty levels might make you do your own "scratch work" in the free cells, rather than letting you ask the game to do it automatically). I also want to let the player pick the display colors, and possibly choose between two or more character sets for the numerals. And when I get to the point of adding background music or whatever, I'd like to let the player choose between different tunes-- although adding sound is the LAST thing on my radar right now! :)

 

Planned game actions will include "NEW" for starting a new puzzle-- hopefully generated randomly, but also with an option to enter a puzzle from a newspaper, magazine, or book-- "LOAD" to restore a saved puzzle, "SAVE" to save your progress on a puzzle (presumably using a MemCard), "CLEAR" to erase your work and restart the current puzzle from scratch, "HELP" to have the game search for and suggest the next move, and "SOLVE" to let the game try to solve the current puzzle by itself (e.g., for when you've entered a puzzle from the newspaper and want the game to auto-solve it).

 

Anyway, I hope I can pull this off, and that I don't have to make too many sacrifices in the process.

 

Michael Rideout

 

post-7456-1151869306_thumb.jpg

Sudoku.bas

Sudoku.bas.bin

Link to comment
Share on other sites

Hey, that's a nice little demo! Looks like you're on the right track. I have no doubt that rewriting the 6 sprites during drawing will be a tricky feat (hey, you have 5 cycles, right? ;)) but I have confidence that it's doable.

 

A few thoughts for you:

 

1. Have you considered using the playfield for thickening the grid on the 3x3 markers? It would make positiioning a smidge bit trickier and the edges of the sprites might touch the playfield (which may or may not be a problem), but it could give you a nice, thick border. Especially if the text and grid are slightly gray and the board is solid white. Alternatively, you could make the background white, and the sprites black.

 

2. The cursor will probably be tricky. While you could rewrite the color on the fly (very difficult considering how tight your kernel is going to be) you might consider inverting the sprite so that the non-text area is solid and the text is simply a "hole" in the sprite.

 

e.g.:

 

Regular:
XXXXXXXX
.......X
..XX...X
.X..X..X
....X..X
...X...X
..x....X
.XXXX..X
.......X
XXXXXXXX

Inverted:
XXXXXXXX
XXXXXXXX
XX..XXXX
X.XX.XXX
XXXX.XXX
XXX.XXXX
XX.XXXXX
X....XXX
XXXXXXXX
XXXXXXXX

 

Also, I don't know if it's helpful or not, but I dug up a couple of Sudoku links that you may find helpful:

 

Sudoku programming forum

Scientific Paper on generating arbitrary-sized Sudoku puzzles

 

Good luck! We're all rooting for you. :)

Link to comment
Share on other sites

Hey, that's a nice little demo!

 

Thank you, but I'm not sure I'd call it a demo yet, maybe not even a proof of concept, since right now the cells all have the same digits in them! :)

 

Looks like you're on the right track. I have no doubt that rewriting the 6 sprites during drawing will be a tricky feat (hey, you have 5 cycles, right? ;)) but I have confidence that it's doable.

 

If all I'm doing is writing the 6 players, then I kow it's doable, especially with the players positioned at medium distance. But updating the players, missiles, and playfield at the same time will be trickier.

 

A few thoughts for you:

 

1. Have you considered using the playfield for thickening the grid on the 3x3 markers? It would make positiioning a smidge bit trickier and the edges of the sprites might touch the playfield (which may or may not be a problem), but it could give you a nice, thick border. Especially if the text and grid are slightly gray and the board is solid white.

 

Do you mean using the playfield instead of the missiles? The horizontal lines aren't a problem; I can just draw two horizontal lines with the players and missiles instead of just one, and the timing won't be a problem either because on those lines I don't have to load and store the players six times! :) It's the vertical lines which are a pain, and I don't see how using the playfield will help, because the pixels will be so wide (half as wide as a cell).

 

One thing that would work would be to remove all of the grid lines except for the boundaries of the 3x3 zones. Then I wouldn't need to use the missiles at all, because I could have one set of digits without the lines, and another set of digits with the lines, and the position of the digit would dictate which character set I load that digit from. I may well end up having to go that route, but I want to try to make the missiles work first. (I'm stubborn!) :)

 

Wow, I just had an idea. I could use the missiles for the grid lines, so I wouldn't need to worry about enabling/disabling them at just the right times, and use two character sets for the digits, as described above. Then the bolder lines will be a snap! :cool:

 

Alternatively, you could make the background white, and the sprites black.

 

I'm not sure I follow you, assuming you're still speaking in reference to the 3x3 zones. But the colors for the entire game screen will be selectable in the final version.

 

2. The cursor will probably be tricky. While you could rewrite the color on the fly (very difficult considering how tight your kernel is going to be) you might consider inverting the sprite so that the non-text area is solid and the text is simply a "hole" in the sprite.

 

e.g.:

 

Regular:
XXXXXXXX
.......X
..XX...X
.X..X..X
....X..X
...X...X
..x....X
.XXXX..X
.......X
XXXXXXXX

Inverted:
XXXXXXXX
XXXXXXXX
XX..XXXX
X.XX.XXX
XXXX.XXX
XXX.XXXX
XX.XXXXX
X....XXX
XXXXXXXX
XXXXXXXX

 

I thought about doing that for the pre-filled cells, and that may be what I end up doing, but I want to try using the playfield first, because it will help make the entire screen a little more colorful.

 

As far as the cursor is concerned, I don't expect it to be a problem using the ball, because I can set its horizontal position at the top of the screen, then for its vertical position all that needs to be done is to enable it at the top of whichever row it's on, and disable it at the bottom of the row, leaving it on for the full height of the cell/row. The timing won't be a problem, because of the gaps between the horizontal lines and the digits-- i.e., it isn't necessary to separately load and store the six players on those lines, since they basically have the same shapes all the way across (other than for the first and third columns, which will be blank except for the vertical grid lines on their right edges). On the lines where I need to load and store the players, the ball will already be enabled or disabled as needed.

 

Also, I don't know if it's helpful or not, but I dug up a couple of Sudoku links that you may find helpful:

 

Sudoku programming forum

Scientific Paper on generating arbitrary-sized Sudoku puzzles

 

Thank you! I haven't looked at them yet, but I expect they'll be EXTREMELY helpful! As soon as I post this reply, I'm going to check them out and bookmark them.

 

Good luck! We're all rooting for you. :)

 

That's great to know! :) I realize how much of a following Sudoku has, which is why I was reluctant to announce this WIP, let alone attempt it. But if I fall on my face with this, at least someone else will be able to check out what I was trying to do, and either correct my mistakes or totally rewrite the basic kernel to make it workable. :)

 

One thing I did yesterday was move my work to the M-Network bankswitching format, because the only way I can come up with doing the dots for the "scratch work" is to have the board be in RAM, so I can just turn the individual dots on or off as needed for any given cell-- otherwise, I'd need to use two bytes to store the contents of each cell, since nine dots gives 512 different possibilities (2^9), and that isn't counting the other ten values for the digits and the blank cells. So if I use 4 bits for the BCD value in the cell (0 for empty, and 1 through 9 for the digits), and 9 more bits for the dots, plus maybe another bit to indicate whether the cell was pre-filled or not, that comes to 13 or 14 bits-- two bytes per cell. And there are 81 cell for the main grid, or 100 cells if we have the extra row, extra column, and extra corner cell which will be used in working on a puzzle, so that would mean 162 or 200 bytes just to store the values for the cells-- too much for the 2600. So if I'm going to have to use extra RAM anyway, I might as well store the screen as a RAM bitmap as it were. I'm uncertain about using M-Network bankswitching, because it means I probably won't be able to produce carts, but I'm hoping that once supercat's 4A50 carts are available, I can revamp the game to use 4A50 bankswitching and produce actual carts! :)

 

Michael Rideout

Link to comment
Share on other sites

Latest build, although the kernel is a bit of a mess, and some of the things I was working on are only partially done. Still, I feel I should post something to show for my time! :)

 

As I mentioned in another post, I've moved the code to the M-Network (E7) bankswitching method, so I can use the 2K extra RAM which it allows. Unfortunately, when I tried to read from the extra RAM after I'd written a sort of "bitmap" to it, the display wasn't anywhere near correct, so I must have done something horribly wrong-- probably something simple but stupid! :) Anyway, I changed that part of the kernel to read from the character set ROM instead, so I could at least work on the timing. And I did get some of the timing worked out, although I haven't applied it to all of the kernel, just to the extra row at the top, plus the line at the top of row 1. I was running out of ROM space in the upper bank, so I moved everything except the main loop down into the lower bank. After I did that, I decided to start working on the kernel again from the top down, so I went ahead and added the screen title. It turned out that it was harder than I expected, because I never fully understood the "six-digit score" technique until tonight.

 

In case anyone wants to try their hand at compiling my code with bB, I'm attaching two zip files. The "sudoku.zip" file contains a modified bB compile batch, which looks for the include files in a different directory than usual, assembles the 6502 code in a different manner, and then calls a program named "mnetwork_postprocess.exe" after DASM is finished. That program is the same one I posted last year when I first added M-Network bankswitching to bB 0.35, but I renamed it to keep it distinct from the "postprocess.exe" program that batari added to bB 0.99. The "includes.zip" file contains all of bB's include files, which I copied to a new directory so I could modify them without screwing up the official standard versions. :) I massacred some of the files to remove all of the code I'm not going to be using in Sudoku, and then added my own code, besides using additional include files for M-Network bankswitching. If anyone needs help trying to set things up to compile, let me know, and I'll give more specific instructions. Otherwise, you can just look at my code to see what I'm doing (or trying to do), if you're interested.

 

When you run the binary build on an emulator, be sure to specify that it's an M-Network E7 game (the correct switch in z26 is "-g7", and in Stella you can just press TAB to set the game properties, although you'll probably need to exit and restart Stella after doing that before it will run the ROM).

 

Michael Rideout

 

post-7456-1152071423_thumb.jpg

Sudoku.bas

Sudoku.bas.bin

Sudoku.zip

includes.zip

Link to comment
Share on other sites

It looks nice, but I am not sure how you are going to find the cycles to change the sprite data between board positions. It will definitely require self-modifying code, but even then I'm not sure it can be done easily?

 

Chris

Link to comment
Share on other sites

When you run the binary build on an emulator, be sure to specify that it's an M-Network E7 game (the correct switch in z26 is "-g7", and in Stella you can just press TAB to set the game properties, although you'll probably need to exit and restart Stella after doing that before it will run the ROM).

If you're launching Stella from the commandline, you can also use the following command line:

"stella -type e7 ROM_NAME". Or you can go through the TAB menu as you mentioned. And if so, you can restart the current game with 'Ctrl r'; you don't need to exit and restart the emulator.

Link to comment
Share on other sites

It looks nice, but I am not sure how you are going to find the cycles to change the sprite data between board positions. It will definitely require self-modifying code, but even then I'm not sure it can be done easily?

 

Chris

 

Actually, the only times I'll be loading the entire board into RAM (if that's what you're referring to) is when a new puzzle is being started, or when a saved puzzle is being loaded, or when the player decides to clear the board and restart the current puzzle from scratch. Other than that, I'll be updating only the specific portion of RAM where some change is taking place on the board. For example, if you're changing the cell in row 3, column 6, then there's no reason to reload the entire bitmap just for that, when all that really needs to be done is to refresh the bitmap data for that particular cell.

 

I've already resolved most all of the timing issues with respect to drawing the board. The only thing left as far as timing goes is to add in the playfield writes, and I don't expect that to be a problem (knock on wood). I also need to add in the ball for the cursor, but that should be a snap. In fact, I've decided to use the ball for making little "cleanups" in the visuals, like filling in the "missing dot" at the beginning of the bolder lines that enclose the 3x3 zones. So the only real problem that's left right now is to figure out what's wrong with accessing the extra RAM, and I think I know what's causing that. If I'm right, I should be posting another build later tonight with an actual puzzle, rather than just rows of all 1s, or 2s, or 3s, etc. :)

 

Michael Rideout

Link to comment
Share on other sites

If you're launching Stella from the commandline, you can also use the following command line:

"stella -type e7 ROM_NAME". Or you can go through the TAB menu as you mentioned. And if so, you can restart the current game with 'Ctrl r'; you don't need to exit and restart the emulator.

 

Thank you, those are good facts to know! :)

 

Michael Rideout

Link to comment
Share on other sites

Good news, I have the extra RAM access working now. The problem wasn't what I thought-- turns out I was writing to and reading from the RAM banks just fine all along, but the data I was storing in it was crud, because temp1 and temp2 weren't keeping the values I was storing in them. I'm now going back through the kernel from top to bottom to tighten the timings, including things like getting rid of the HMOVE lines and adding the playfield and ball. I don't know how much I'll get done tonight, but I'll post my progress before I go to bed in a few hours.

 

One thing that's been driving me crazy throughout this project is that little things I do can suddenly throw the timings out of kilter, when it seems like they shouldn't make any difference. For example, I ran out of space in the fixed upper bank-- which is only 1536 bytes, since the first 512 bytes of that 2K bank are used by the four smaller extra RAM banks. So I moved the kernel into ROM bank 1, and all of a sudden some of the positionings were off by 3 cycles, even though all I did was move the kernel into a different ROM bank! I've run into that sort of thing several times while working on this game. The crazy thing is, the RESxx commands are preceded by WSYNC commands, so the timings should have stayed exactly the same, right?

 

Michael Rideout

Link to comment
Share on other sites

OK, I don't have anything ready to post tonight after all. :(

 

I figured out a more efficient way to handle the differences between the two frames-- which I'm now calling "fields," even though they aren't interlaced, since it takes two flickered "fields" to make one complete "frame." But it means I must now change the way I'm using the field counter, hence major surgery on the kernel.

 

On the other hand, the next build I post should be more or less complete as far as the display kernel (aside from the "action menu" that will be underneath the game grid), so then I can start working on the actual game logic! :)

 

Michael Rideout

Link to comment
Share on other sites

On the other hand, the next build I post should be more or less complete as far as the display kernel (aside from the "action menu" that will be underneath the game grid), so then I can start working on the actual game logic! :)

I'm looking forward to seeing what the final layout will look like. Keep up the good work!

Link to comment
Share on other sites

I'm enjoying reading your progress on Sudoku. I am curious what was involved in your choosing E7 out of all the extended memory schemes available?

 

BTW, when you work on the asymmetrical playfield, I hope you are able to use the reflected 32 pixel scheme, which would save your many cycles. It's only disadvantage is that the timing is rigid. There is only a small window when you can update PF2. I know bBasic takes care of the playfield, but if you are updating the shapes of the sprites, you may have to get more deeply involved.

Edited by Zach
Link to comment
Share on other sites

I'm enjoying reading your progress on Sudoku. I curious what was involved in your choosing E7 out of all the extended memory schemes available?

 

There aren't really a whole lot to choose from:

  • Superchip -- provides a nice easy 128 bytes, but that's all there is
  • Ram-plus -- provides a nice easy 256 bytes, but that's all there is
  • Supercharger -- Provides 6K, of which 4K is available simultaneously, but that includes code as well as data and is a pain to write to
  • E7 -- Provides 2K RAM plus 15.5K (IIRC) of code space; up to 1.25K of RAM is available at a time, and 1K of the RAM can be accessed from anywhere in the code.
  • 3E -- Provides oodles of RAM and code space, but only 1K of RAM is available at a time, and only 2K of code can access any of the RAM.
  • 4A50 -- Provides oodles of RAM and code space, with up to 3.75K of RAM accessable at once, and all parts of RAM addressable from code anywhere in RAM or ROM

Am I forgetting any?

Link to comment
Share on other sites

I'm enjoying reading your progress on Sudoku. I curious what was involved in your choosing E7 out of all the extended memory schemes available?

 

There aren't really a whole lot to choose from:

  • Superchip -- provides a nice easy 128 bytes, but that's all there is
  • Ram-plus -- provides a nice easy 256 bytes, but that's all there is
  • Supercharger -- Provides 6K, of which 4K is available simultaneously, but that includes code as well as data and is a pain to write to
  • E7 -- Provides 2K RAM plus 15.5K (IIRC) of code space; up to 1.25K of RAM is available at a time, and 1K of the RAM can be accessed from anywhere in the code.
  • 3E -- Provides oodles of RAM and code space, but only 1K of RAM is available at a time, and only 2K of code can access any of the RAM.
  • 4A50 -- Provides oodles of RAM and code space, with up to 3.75K of RAM accessable at once, and all parts of RAM addressable from code anywhere in RAM or ROM

Am I forgetting any?

There's Commavid, and arguably, Pitfall II and the Compumate. However, I do not know the details of these.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...