SeaGtGruff

I don't have time at the moment to study your code fully, but part of your problem is that you can't use multiplication with the score (at least, it doesn't work that way *yet*). So you'll need to use a variable to do the multiplication, then assign the result to the score, like this: p=n*o : score=p : rem instead of score=n*o Except if I remember correctly from another thread a week or two ago, you can't assign a variable to the score right now, either, because it's broken. Michael Rideout

Hmm, it might be kind of interesting to give people a way to share puzzles, custom color schemes, user-designed character sets, or even (dare I dream it?) user-written background musical tracks. Michael Rideout

That's great! I'm going to continue developing in E7 for a bit, until I get a build that could reasonably be called a "working demo," and then I'll migrate to 4A50. I hate to sound like a clueless idiot, but... I'm a clueless idiot! Whenever people start using highly advanced technical terms like ROM, PROM, EPROM, EEPROM, RAM, flash (RAM?), TV, TiVo, etc., my eyelids start to flutter and my eyeballs roll back in my head. Are you telling me that 8K of memory will be available for saving and loading game data, which won't be lost when you turn off the Atari, unplug the cart, put the cat out for the night, and go to bed? And are you telling me that 4A50 games can be up to 128K ROM in size using bankswitching, or that up to 128K RAM will be available to use with bankswitching, or ...? 'Splain it to me, Lucy! Michael Rideout

Hey, the second from the right looks good! I think the newest unreleased version of bB 0.99 might support multicolored players (I know it supports multicolored playfields, anyway), in which case it would be possible to use that Mario in a bB game. Michael Rideout

I think batari is afraid that (1) it contains too many bugs right now, and (2) any future bug-fixes to it may conceivably "break" a program that was written with it. http://www.atariage.com/forums/index.php?s...t&p=1093212 Michael Rideout

If the 4A50 carts will have built-in save game capabilities, I guess that would make the MemCard superfluous. On the other hand, I hope to eventually get into AtariVox programming (although I don't think there are any more available right now?), and the AtariVox has a MemCard in it, so adding and keeping MemCard support to Sudoku would be good in case I ever add AtariVox speech to it, too. I plan to have randomly-generated puzzles, but I haven't looked at any discussions or pseudocode for that yet. In the early WIP builds I'll be using puzzles stored in ROM so I can focus on finalizing the display kernel and getting the game play logic in place. And as for using pre-computed puzzles, it should be possible to create many different puzzles from a single pre-computed puzzle, by shuffling the 3x3 zones and/or columns and/or rows (keeping the one-and-only-one-solution condition intact, of course), and/or by mapping the digits to other digits (i.e., all the 3s become 5s, all the 4s become 1s, etc., as in a cipher). Michael Rideout

You're welcome, and thank you for the compliment about the look of the colon. It was hard to design the way a colon should look. Just kidding, of course! Well, I REALLY need to go back and work on "Reventure" some more, because I sort of abandoned it last year, but I definitely want to finish it. And eventually I want to get back to my grandiose "Quest for the Lost Pyramids of Atlantis" game trilogy. Adventures are just about my favorite type of game. But before I get too wrapped up in making games, I also need to resume working on the bB tutorial I started. I've decided to postpone several of the early installments I'd planned (the TV picture, the Atari's features, the Atari's memory map, a crash course in programming, designing a game, etc.), and just go directly into bB programming to help people jump in and get their feet wet. Then I can go back later and post the "missing" installments. And I can always update installments after they've been posted-- in fact, I'll absolutely need to. For example, I should post an addendum to some of the existing installments, to talk about upgrading from one version of bB to another, or installing a newer version of an emulator-- not to mention, we now have another bB code editor to choose from. I'm wondering if I should get the latest unposted bleeding-edge build of bB from batari so I can talk about it in the tutorial, or if it would be better to wait until it's posted for anyone to download and then just update any tutorial installments as needed? I'm using 0.99 for the tutorial, because it's available from batari's blog, but it isn't even "officially" released yet. Are most people using 0.35 or 0.99, I wonder? Which version are *you* using? Michael Rideout

Hey, I had to look at bB's kernel source to be sure I was using the right byte/index for the last two digits of the score. And then I had to reread atari2600land's original post twice because I had just glanced at it quickly the first time, then merrily proceeded to write up an example and an answer that did *NOT* do what he said he wanted to do. So I had to scrap all that and start over. I would have sworn it was going to be necessary to change the way the kernel handles the score-- but after I explained about copying the two kernels and renaming them to "timer_std_kernel.asm" and "timer_multisprite_kernel.asm" (and actually did that myself), then opened up the kernel and scrolled down to modify the code, I saw the use of Y as the index (d'oh, of course!), and realized that bB doesn't give a hoot what's in Y, so I had to change my answer in mid post AGAIN, to remove all the unnecessary talk about copying and changing the kernels! This is why the score graphics can get munged-up if the score's bytes ever contain non-BCD values in them-- and this will also make it a snap to use bB's score to do things like display an 8-line tall title or copyright message at the bottom of the screen, or a six-item inventory strip using any of up to 16 different items, etc. You don't even have to change bB-- just define a data table in your bB program for the game title, inventory items, etc., then dim three variables to the three bytes that store the score pointers so you can point them wherever you want, and then just don't do any assignments or math with the score. I think that should work with no problem. Hang on, now that I think about it, it should be possible to choose from up to 256 different items for an inventory strip, since Y can be 0 to 255, and the score pointers point to an entire byte, not to a nybble. (D'oh again!) I haven't checked bB's routines, but I know there's a place where it converts the nybbles of the score into addresses for the score pointers, so it might be necessary to modify that section-- or it might be possible to just override that stuff on every frame by setting the score pointers manually just before calling drawscreen. I'll do some examples later and post them. I got like 3.5 hours of sleep Thursday night after going to the midnight showing of Pirates 2, so I had to take a 3-hour nap when I got home from work. Then after I got up after my nap, I still wasn't able to stay up all night and work on Sudoku like I'd planned. Sleep is *GOOD*! Considering how hard it is to talk myself into getting out of bed in the morning, I don't know why it's always so hard to make myself go to bed at night! I hope you're having fun with your nephew, by the way. You're helping him learn Atari 2600 game programming, right? I don't think my youngest nephew is old enough to handle that yet, at least not the bB coding and program logic. It will be fun to help him learn 2600 programming in a few more years. In the meantime, he can help with designing the games. I'll have to set up bB on my dad's computer to see how much my nephew is able to absorb about programming while he's staying with my parents this summer. Michael Rideout

Thanks, Chris! For saving a Sudoku game, I'll probably need two 64-byte pages per saved game, to save most of the zero-page RAM. The only reason I might need to save larger quantities of data in Sudoku would be if I eventually add a character-set designer to let the user design custom character sets in the extra RAM, and then save/load the custom character sets. That might be pretty cool to do, way down the road. After all, if I'm going to eventually produce carts (presumably 4A50), and if I'm going to optionally include a MemCard with the cart (i.e., buy it with or without a MemCard), then I'll want to have all sorts of nifty features to help justify the game's price tag! Michael Rideout

SpiceWare's answer was correct, except it looks like it had a typo in it, because score[1] should have been score[2], like this: 202 t=t+1 : COLUP0=196 if t=60 then score=score+1 : t=0 : rem * take out "goto 202" ! if $60=score[2] then score=score+940 216 drawscreen I tested it, and it works. This is trickier. Again, SpiceWare's answer was correct. However, you don't need to do anything to make bB interpret $A as a colon, because it will do that automatically once you add the data for the colon to the scoregraphics table. On the other hand, you *will* need to change the way you're doing mathematical operations with the score, since the nybble (half-byte) that's used for the fourth digit (the hundreds place) won't be a number anymore! And you'll also need to temporarily change the file that tells bB which includes to use ("default.inc"), so it uses your new score graphics instead of the standard score graphics. I realize that a lot of this is over your head right now-- not to worry, be patient and persistent, and you'll understand it eventually (this stuff ain't rocket science, but it ain't a piece of cake, either!)-- so I've done it for you. First, you need to add an eleventh character (":") to the score's character set. In bB 0.99, the score's character set is in the "score_graphics.asm" file. You don't want to destroy the original file, so it'd be best to copy it, and rename the copy to something else, like "timer_score_graphics.asm". Then you can change the ORG and RORG statements at the beginning of "timer_score_graphics.asm," to move it down 8 bytes in memory (since you're going to be making scoretable 8 bytes longer), like this: ; feel free to modify the score graphics - just keep each digit 8 high ; and keep the conditional compilation stuff intact ifconst ROM2k ORG $F7A4; was ORG $F7AC. $F7A4 is 8 bytes less than $F7AC. else ifconst bankswitch; subtract 8 bytes from the addresses if bankswitch == 8 ORG $2F9C-bscode_length; was ORG $2FA4-bscode_length RORG $FF9C-bscode_length; was RORG $FFA4-bscode_length endif if bankswitch == 16 ORG $4F9C-bscode_length; was ORG $4FA4-bscode_length RORG $FF9C-bscode_length; was RORG $FFA4-bscode_length endif if bankswitch == 32 ORG $8F9C-bscode_length; was ORG $8FA4-bscode_length RORG $FF9C-bscode_length; was RORG $FFA4-bscode_length endif else ORG $FFA4; was ORG $FFAC endif endif Then scroll to the bottom of the file and add the graphics for the new colon character to the end of scoretable, just above the ifs, like this: .byte %00111100; data for character "9"; leave it alone .byte %01000110 .byte %00000110 .byte %00111110 .byte %01100110 .byte %01100110 .byte %01100110 .byte %00111100 .byte %00000000; data for new colon character .byte %00011000; it goes just after the data for "9" .byte %00011000 .byte %00000000 .byte %00000000 .byte %00011000 .byte %00011000 .byte %00000000 ifconst ROM2k; Do not mess with any of this stuff at the end! ORG $F7FC else After you make these changes, save the modified "timer_score_graphics.asm" file. Now you need to edit the "default.inc" file to use your new "timer_score_graphics.asm" file. Scroll down toward the bottom of the file and look for where it refers to the score graphics, then change it to look like this: ; score graphics. ; score_graphics.asm timer_score_graphics.asm Then save the modified "default.inc" file. Finally, you must initialize the score so it has the colon in the fourth place. Then you must force the fourth place to always be $A for the colon. Each time you do math with the score, it will destroy the colon-- and the colon will interfere with the math-- so you want to remove the colon, do the math, and then put the colon back, like this: 200 score=0 dim colon = score+1 202 t=t+1 : COLUP0=196 colon = colon && $F0 if t=60 then score=score+1 : t=0 : rem * take out "goto 202" ! if $60=score[2] then score=score+940 colon = colon || $0A 216 drawscreen 218 if joy0down then goto 220 219 goto 202 Save your program and compile it. I tested it, and it works! Just be sure that when you're all done, you change "default.inc" back to what it looked like originally. I'm attaching all the files as I've changed them, for convenience, but I encourage you to try making the changes yourself to help it all sink in better. I couldn't attach files ending in ".inc" or ".asm," so I renamed "default.inc" to "default.txt," and "timer_score_graphics.asm" to "timer_score_graphics.txt." You'll need to rename them back after you download them. Another approach to doing a timer in bB would be to forget about doing the colon, and leave the scoregraphics alone, but just change the spacing of the players for the score digits, so they're arranged like this: 12 34 56 Then you can use the first two places for hours, use the middle two places for minutes, and use the last two places for seconds. That would mean changing the kernel include file to alter the way it spaces and positions the score characters, not to mention changing the timing for when bB loads and stores the players in the score. Maybe we'll try that in another post. By the way, I'm glad you asked these questions, because otherwise I wouldn't have learned what I did while I was answering them. Now I know how to use the score to do a six-item inventory strip, with up to 16 different items to choose from! Michael Rideout default.txt timer_score_graphics.txt timer_question.bas timer_question.bas.bin

Oh, sorry, I didn't see this before I posted my other reply! Michael Rideout

Someone sent me Indenture maps some years ago, but they're text data rather than bitmaps. I'd meant to use the text data to create bitmapped screens, but never finished. The text data file is attached below. Don't remember who sent this to me. Michael Rideout indenture_rooms.zip

That's a neat technique, but there wouldn't be any benefit from it in Sudoku. The 20 playfield pixels I'm using aren't centered on the screen, they're shifted over to the right a little bit, like this: So on the left side PF0 and PF1 will be %00000000, and on the right side PF2 will be %00000000, and I'll need to use PF2, PF0, and PF1 in the middle as shown. I can just do something like this: LDX #0; loop counter and scan line index sleep ??? loop LDA #0 STA PF2; on the right side of the screen STA PF0; on the far right side of the screen STA PF1; on the far right side of the screen STA WSYNC; could possibly move this further down if there's time LDA DATA_GRP0_A,X; X will contain the scan line number within the cell row STA GRP0 : could even do this on the far right side of screen if there's time LDA DATA_GRP1_A,X STA GRP1 : could even do this on the far right side of screen if there's time LDA DATA_PF2,Y; Y will contain the cell row number within the grid STA PF2; on the far left side of the screen sleep ??? LDA DATA_PF0,Y STA PF0; after left PF0 has been drawn sleep ??? LDA DATA_GRP0_B,X STA GRP0 LDA DATA_GRP1_B,X STA GRP1 sleep ??? LDA DATA_PF1,Y STA PF1; after left PF1 has been drawn LDA DATA_GRP0_C,X STA GRP0 LDA DATA_GRP1_C,X STA GRP1 sleep ??? INX; if needed for timing, can change this to LDX #7 : DEX : BPL loop CPX #8 BNE loop Michael Rideout

Do you have to recompile z26 using those files, or ...? I guess I should just read supercat's blog! But if I can "easily" use 4A50 bankswitching with z26, and if I can learn how to use it in programs-- and especially if I can work out how to compile bB code for 4A50 bankswitching like I did for E7-- then I'll either move Sudoku from E7 to 4A50, or see if I can develop the two versions side by side. I'm really keen on being able to use self-modifying RAM kernels with 4A50, for example-- not that I'll need to do that for Sudoku. But aside from the questions of when will actual carts be ready, and how much will they cost, I'm curious about how concrete the current design is. Is it likely to be changed before actual carts are available, and if so, what sorts of changes are we talking about, and how hard will it be to update my code as needed? On another note, I received a MemCard in the mail today, so this weekend I'll be setting up my Atari 2600 and Krokodile Cartridge, and/or my Atari 7800 and Cuttle Cart II, plus the MemCard, to try my Sudoku builds on the real deals, and (once I have the display kernel mostly hammered out) to start adding some code for saving and loading Sudoku puzzles... which raises another question. Was there ever an agreement about standardizing the use of the MemCard? I figure Sudoku really doesn't need to know how to recognize the save formats used by other games; all it really needs to do is have a way of identifying which memory blocks it's using-- like putting six ASCII values for "Sudoku" at the head of a memory block, plus perhaps a save game number-- so it can tell if a given block is being used by Sudoku or by something else. (I haven't started to read up on using the MemCard yet, but I'm assuming that an unused block can easily be distinguished from one that's being used.) Michael Rideout

supercat gave a pretty good summary. I'm most familiar with the older bankswitching methods, for the simple reason that they're documented on the web. And of those, E7 is the only one that has any serious amount of extra RAM-- i.e., enough to think about bitmapping the screen to any extent. Plus, a couple of years ago I (just barely) started working on a game that was using E7, so I was already familiar with how to use it, and last year I made some minor changes in bB's include files to allow the use of E7 bankswitching. As far as I know, 4A50 isn't ready yet, and I'm not even sure whether the design is finalized or subject to changes, not to mention the fact that I don't know how to program for it, let alone how to modify bB so it can use 4A50 bankswitching, or whether 4A50 will run on any emulators yet. I'm hoping that 4A50 will be ready before too long, and I think it should be easy to convert E7-Sudoku to 4A50-Sudoku, because I think the chances of anyone producing E7 carts are slim to none, so 4A50 is probably the only hope for Sudoku (as I'm programming it, anyway) to ever be available on an actual cart. Actually, I think the best way to incorporate the playfield for the background of the cells which are pre-filled, is to use the duplicated or non-mirrored mode. I'm essentially drawing 11 columns on the screen, but using only 10 of them, since there is an empty column between the extra column on the left and the 9 columns of the grid. I'm centering those 11 columns on the screen, but only the 9 in the grid will ever contain pre-filled cells (the "givens" as they're sometimes called). And each cell is two playfield pixels wide, so that means I'll need 18 playfield pixels-- 7 on the left half of the screen, and 11 on the right half. With the non-reflected mode, I can write PF2 right away, then write to PF0, then write to PF1, then clear PF2, which I should be able to integrate nicely with updating the players as far as the timing is concerned. If I use the reflected mode, I'll still need to use three registers for the pixels (left PF2, right PF2, and right PF1), but the timing would be more restrictive. Non-reflected mode will allow more flexibility for the timing, hence making it easier to update the players at the right times, while also sneaking in the playfield updates. Michael Rideout

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

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

Thank you, those are good facts to know! Michael Rideout

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

Very true... but then again, "tremendously difficult" is more fulfilling/satisfying to do. That's only true if the sprite's position is variable (which, of course, it usually is). If you're positioning a sprite to a fixed position, then you can do other things like load color changes, etc., instead of just sleeping for a bunch of cycles while you're waiting for the beam to reach the desired spot on the scan line. Michael Rideout

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 Sudoku.bas Sudoku.bas.bin Sudoku.zip includes.zip

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! 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. 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! 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. 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. 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

Neat! Thanks for posting these! Michael Rideout

Actually, as long as you're running your bB programs on an emulator or programmable cart that can handle any of the bankswitching methods that include extra RAM, then there's no reason you can't use extra RAM in your bB programs. For example, last year I posted some modified include files, a modified batch, and a "postprocess" program, that added M-Network bankswitching to bB, which has 2K of extra RAM. Earlier today I made similar changes to bB 0.99b so I can use the extra RAM in Sudoku. I'll be posting an update later tonight, so you'll be able to look at what I did. The standard 8K/16K/32K bankswitching methods that batari added to bB 0.99 can be used with the Superchip's extra RAM. That's only 128 bytes of extra RAM, but it doubles the total amount of RAM you have available. All you have to do is (1) make sure your program code doesn't compile in the $9000 through $90FF address range, because that's where the extra RAM is; (2) use $9000 through $907F for writing to the extra RAM; and (3) use $9080 through $90FF for reading the extra RAM. The first part might be a little tricky-- I haven't tried using any of those bankswitching methods with bB yet-- but the rest is easy. I'm kind of preoccupied with Sudoku right now, but I'll see if I can figure it out later and post an example. Michael Rideout

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 Sudoku.bas Sudoku.bas.bin