Sudoku

[SeaGtGruff]

I curious what was involved in your choosing E7 out of all the extended memory schemes available?

 

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.

 

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.

 

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

[+batari]

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.

z26 supports 4A50, as does the CC2. I think the necessary files are available in Supercat's blog. What remains to be seen is how much the boards are going to cost.

[Zach]

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.

 

Since you only need the middle 32 pixels, there are ways to optimize the duplicated playfield. You can load the values for the right-side PF0 and PF2 at the same time. After you store that value to PF0, simply AND with $0F before storing to PF2. If the X register is available, you can set it to $0F and use the SAX opcode (which stores A&X). Plus, if X is set to $0F, you can do a STX PF0 for the left side. I came up with this technique while developing a new chess kernel.

Edited July 7, 2006 by Zach

[SeaGtGruff]

z26 supports 4A50, as does the CC2. I think the necessary files are available in Supercat's blog. What remains to be seen is how much the boards are going to cost.

 

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

[SeaGtGruff]

Since you only need the middle 32 pixels, there are ways to optimize the duplicated playfield. You can load the values for the right-side PF0 and PF2 at the same time. After you store that value to PF0, simply AND with $0F before storing to PF2. If the X register is available, you can set it to $0F and use the SAX opcode (which stores A&X). Plus, if X is set to $0F, you can do a STX PF0 for the left side.

 

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

[Zach]

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:

In that case, it should be pretty easy for you. Nice Sudoku logo BTW.

[cd-w]

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

 

There are two 16K areas on the memcard: the static allocation area, and the file area. For small quantities of data, the static allocation area is probably best. This area is divided into 64 byte pages, which are reserved for specific games. The allocations are listed on this page. For larger quantities of data, the file area should probably be used, but I am not sure if the format of this area has been completely agreed yet. Details on programming the memcard are given in the AtariVox Programming Guide.

 

Chris

[SeaGtGruff]

There are two 16K areas on the memcard: the static allocation area, and the file area. For small quantities of data, the static allocation area is probably best. This area is divided into 64 byte pages, which are reserved for specific games. The allocations are listed on this page. For larger quantities of data, the file area should probably be used, but I am not sure if the format of this area has been completely agreed yet. Details on programming the memcard are given in the AtariVox Programming Guide.

 

Chris

 

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

[cd-w]

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!

 

I think the 4A50 cart has its own EEPROM facility, but I could be wrong about this (supercat?). In any case, I am keen to see how this turns out as I am a big fan of Sudoku puzzles. Will the Atari be able to generate its own puzzles, or will you be relying on pre-computed puzzles?

 

Chris

Edited July 8, 2006 by cd-w

[SeaGtGruff]

I think the 4A50 cart has its own EEPROM facility, but I could be wrong about this (supercat?).

 

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.

 

In any case, I am keen to see how this turns out as I am a big fan of Sudoku puzzles. Will the Atari be able to generate its own puzzles, or will you be relying on pre-computed puzzles?

 

Chris

 

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

[Inky]

Wow! I didn't think it would be possible! Looks good so far!

[supercat]

Do you have to recompile z26 using those files, or ...? I guess I should just read supercat's blog!

 

I've posted a version of the z26 executable that supports 4A50 banking. My blog also has a link to a copy of the spec, though there are three changes not noted in the spec that maybe I should fix sometime. Any code designed around the spec as written shoud work, though, unless it tries to use both LED's (the cartridge only supports one now).

 

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?

 

I think the CPLD design is "final", unless I find some timing compatibility problems on some 2600's (I've not looked at FB2 timing enough to know if that could be made to work). The most notable changes are the addition of EEPROM support (8Kbytes) and the expansion of flash to 128Kbytes (the $1000-$17FF area uses the first 64K; the areas in $1800-$1FFF use the second 64K). I believe the Z26 emulator will copy a 64K image into both halves of the 128K flash.

[supercat]

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.

 

One of my myriad projects is adding a 24LC16 to the AA cartridge board. If I do that, I'll create a version of Strat-O-Gems that uses the internal EEPROM, but I'll also include import/export options for the memcard/Atarivox. I'd suggest doing likewise with Sudoku (to allow people to move puzzles from one cart to another).

[SeaGtGruff]

I've posted a version of the z26 executable that supports 4A50 banking. My blog also has a link to a copy of the spec, though there are three changes not noted in the spec that maybe I should fix sometime. Any code designed around the spec as written shoud work, though, unless it tries to use both LED's (the cartridge only supports one now).

 

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 think the CPLD design is "final", unless I find some timing compatibility problems on some 2600's (I've not looked at FB2 timing enough to know if that could be made to work). The most notable changes are the addition of EEPROM support (8Kbytes) and the expansion of flash to 128Kbytes (the $1000-$17FF area uses the first 64K; the areas in $1800-$1FFF use the second 64K). I believe the Z26 emulator will copy a 64K image into both halves of the 128K flash.

 

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

[SeaGtGruff]

One of my myriad projects is adding a 24LC16 to the AA cartridge board. If I do that, I'll create a version of Strat-O-Gems that uses the internal EEPROM, but I'll also include import/export options for the memcard/Atarivox. I'd suggest doing likewise with Sudoku (to allow people to move puzzles from one cart to another).

 

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

[supercat]

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,

 

128K of flash, but with restrictions on accessing (128K chips were cheaper than 64K chips, and anything that needs to be visible in both paging areas can be duplicated if needed).

 

32K of RAM.

 

8K of EEPROM which is a bit of a pain to access, but will keep contents without power. Any given spot in the EEPROM may only be written 1,000,000 times.

[supercat]

Hate to steal your thunder, but maybe toss you a challenge. How do you like the looks of something like this as a kernel? Move cursor with joystick, change number with fire button. Use RESET to toggle the color of the current square. Then figure out how it all works in a 4K cart.

 

FYI, the only flicker is the cursor. The flicker cursors because my code requires the playfield to cover up some bogus sprite data; if the cursor didn't flicker it would be opaque. If I made my code somewhat bigger, I could free up enough cycles to fix that annoyance but don't think it woud bit in a 4K cart. Color selections and color combinations are entirely arbitrary. Can anyone figure out how this works?

sud.bin

Edited July 9, 2006 by supercat

[+atari2600land]

FYI, the only flicker is the cursor. The flicker cursors because my code requires the playfield to cover up some bogus sprite data; if the cursor didn't flicker it would be opaque. If I made my code somewhat bigger, I could free up enough cycles to fix that annoyance but don't think it woud bit in a 4K cart. Color selections and color combinations are entirely arbitrary. Can anyone figure out how this works?

Could it have something to do with the fact that the numbers in the 2nd, 4th, 6th and 8th columns are 1 pixel higher than the 1st, 3rd, 5th, and 7th columns?

[supercat]

Could it have something to do with the fact that the numbers in the 2nd, 4th, 6th and 8th columns are 1 pixel higher than the 1st, 3rd, 5th, and 7th columns?

 

Venetian blinds are an old trick on the 2600, but this kernel adds a new twist. I've posted a blog entry for the kernel; if nobody else can figure it out, I may post my secrets but I want to see what people can work out first.

 

Normally Venetian blinds use a shift of +/- 7 pixels or in a few cases (Strat-O-Gems title screen) +/- 8 pixels. Occasionally, Venetian blinds are used with variable shift amounts (Stampede and Sky Jinks do that). But how much are the sprites here moving from one line to the next?

Edited July 9, 2006 by supercat

[jbanes]

Could it have something to do with the fact that the numbers in the 2nd, 4th, 6th and 8th columns are 1 pixel higher than the 1st, 3rd, 5th, and 7th columns?

Pretty much. It looks like supercat's come up with a rather innovative version of the "venetian blinds" trick. Amazingly, there are only 2 sprites per scanline. Each sprite is doubled wide, thus allowing a great deal of time between each sprite renderng. (More than enough time to update GRP0 and GRP1.) White characters are rendered by GRP0 while pink characters are rendered by GRP1.

 

I'm too tired ATM to fully wrap my head around it, but it's a rather imaginitive trick.

[SeaGtGruff]

Hate to steal your thunder, but maybe toss you a challenge. How do you like the looks of something like this as a kernel? Move cursor with joystick, change number with fire button. Use RESET to toggle the color of the current square. Then figure out how it all works in a 4K cart.

 

FYI, the only flicker is the cursor. The flicker cursors because my code requires the playfield to cover up some bogus sprite data; if the cursor didn't flicker it would be opaque. If I made my code somewhat bigger, I could free up enough cycles to fix that annoyance but don't think it woud bit in a 4K cart. Color selections and color combinations are entirely arbitrary. Can anyone figure out how this works?

 

Very impressive, and I like the nice large grid and digits! Unfortunately, it would not work with my own Sudoku game plans, because I'm using an extra row and column as part of the "scratch work," and I'm putting dots in the cells to indicate which digits could possibly go in each cell. Also, I'm going to have an action menu underneath the grid. Some of those things might be doable with your kernel, but I haven't figured out any solution for the dots that doesn't involve bitmapping the grid in RAM.

 

Michael Rideout

[supercat]

Very impressive, and I like the nice large grid and digits! Unfortunately, it would not work with my own Sudoku game plans, because I'm using an extra row and column as part of the "scratch work," and I'm putting dots in the cells to indicate which digits could possibly go in each cell. Also, I'm going to have an action menu underneath the grid. Some of those things might be doable with your kernel, but I haven't figured out any solution for the dots that doesn't involve bitmapping the grid in RAM.

 

I can certainly see that it would be useful to add features that would require more RAM. I would expect that if you don't mind using a fair chunk of self-modifying code it might be possible to add an extra column to the display while keeping the two-color feature. Stuff could be packet a little tighter horizontally if you won't want to use the playfield to separate your groups of three; vertical height could be reduced as well, especially if you use David Crane's "flicker blinds".

 

I must say, though, that I was quite pleasantly surprised with what I was able to make work in a standard 4K cartridge. I would have expected when I started that even just the basic display would require 8K (going to 8K would let me save three cycles per scan line, which could avoid the need to use the playfield to cover up "bogus" sprite copies).

[SeaGtGruff]

At long last, I have a new build. The display kernel is pretty much as I want it to be, except for the action menu (New, Load, Save, etc.) that will be underneath the grid. And I also need to clean up the code for the kernel.

 

The ball is now working as the cursor (as originally planned). You can move it around with the joystick, but that's it for right now.

 

I had too many problems getting the timing right as far as using the playfield as the background for the givens, so I decided to use inverse graphics instead. That means the grid portion of the screen won't be as colorful as I'd hoped. But on the plus side, it solves the problem of keeping the position of the cursor easy to see whenever the cursor is moved into one of the given cells. On the minus side, I think the flickering is more apparent with the givens.

 

On the other hand, I *am* using the playfield in the grid area. It's used to get the bold horizontal lines; I'm changing the color to match the players, then changing it back after the bold lines have been drawn. It was too difficult to combine the players and missiles for the bold horizontal lines as I was doing in the earlier builds, due to the inability to move right when doing cycle 73 HMOVEs, hence I couldn't resize the missiles and shift them left and right, as when I was using cycle 3 HMOVEs.

 

I also changed the colors of the grid area, because it was hard to pick a cursor color that stood out well against the previous brown grid area, while still looking good with the title colors. Of course, the colors will eventually be user-selectable.

 

A PAL build is included, and if anyone can run it on a real PAL Atari, I'd like to know how bad the flickering is at 50 Hz. Right now there's no way to switch between NTSC and PAL, but I'm going to use the difficulty switches for that-- left difficulty will choose between 60 Hz/262 lines and 50 Hz/312 lines, while right difficulty will choose between NTSC Color/NTSC B&W/PAL/SECAM (based on the left difficulty setting). I figure it's better to use the difficulty switches because they're harder to get to on some Atari models, so it will be easier to set them as needed and then avoid changing them by mistake. Or if that isn't popular with the users, I can use the Color/B&W switch to choose between NTSC and PAL, and not worry about NTSC B&W or SECAM palette support. Come to think of it, since the colors will eventually be selectable anyway, there probably isn't any point in worrying about an NTSC B&W or SECAM setting.

 

I'm posting the include files again, because I made some more changes in a couple of them.

 

Now that the display kernel is mostly done, I can switch over to bB for working on game play.

 

Michael Rideout

 

includes.zip

Sudoku.bas.bin

Sudoku_PAL.bas.bin

Sudoku.bas

[+atari2600land]

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

[cd-w]

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.

 

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