Sudoku

[SeaGtGruff]

Is the Sudoku game still on hold?

It's still temporarily on hold for the moment, but I've been planning to resume work on it.

 

I started designing Sudoku using M-Network's E7 bankswitching method, because it provides 2K of extra RAM, which is essential for doing what I'm doing (i.e., storing the screen display data in RAM).

 

But as far as I know, there are no modern homebrew cartridges available for E7 bankswitching-- so if I stick with the E7 format, the game will be playable only on emulators, or by loading it into one of the programmable carts that can play E7 games (e.g., the Cuttle Cart 2, or the newer versions of the Krokodile Cartridge). I would much rather have something that can actually be released on a cart.

 

On the other hand, the new (but currently still unreleased) 4A50 bankswitched cartridge is just the ticket-- 32K of extra RAM, yea!!!-- except it has 128K of ROM, which I don't really need for Sudoku (unless I add a *lot* of extra features, like a humongous soundtrack).

 

John (supercat) told me that the 4A50 cart should be able to handle smaller games, if they're a nice power of 2 (i.e., 128K standard, or 64K, or 32K, or even 16K, etc.). But I got the impression that the actual cart would still contain 128K, with the game code duplicated as many times as needed to fill up the ROM (i.e., 64K+64K, or 32K+32K+32K+32K, etc.). So creating a smaller game won't reduce the price of the finished carts, since they'll still be 128K in size-- in which case I'm perfectly happy to use the 128K of ROM for things like more advanced puzzle-solving logic, including a lot of pre-generated puzzles, having several different tunes, etc.

 

I did finally sit down and learn how to use the 4A50 bankswitching method-- it's really very simple, I don't know why I was intimidated by it at all. Well, I haven't learned *everything* about it, because there are several different ways to switch banks-- but I learned how to use the hotspots for switching banks in the "traditional" manner!

 

One remaining issue is whether to try to use a mixture of bB and assembly, as I'd started out doing, or just switch to pure assembly code. I planned to use assembly for the time-critical things, anyway, but I was hoping to use bB's "higher-level" statements for some of the game logic, since it's easier to code complex decision-making logic, or complex calculations, in a high-level language. So if I want to use bB at all, I'll need to figure out a way to add 4A50 bankswitching to bB-- which I'd like to do, anyway, whether or not I actually do that for Sudoku. In the meantime, I can always just write the complex stuff in a small bB program, compile it to get the equivalent assembly code, then streamline the assembly code and stick it in the Sudoku game, without actually writing Sudoku in bB per se.

 

Also, I need to rework the existing Sudoku kernel for the 4A50 method. This should be easy to do-- and I'll have a *lot* more RAM for storing the screen data. I'll even be able to put the display kernel in RAM and execute it from within RAM. That means I'll be able to use immediate addressing with modifiable code, so that-- among other things-- I should have no trouble interleaving the flickered players and missiles (i.e., "flickering venetian blinds") to produce a better-looking display.

 

By the way, I have two Sudoku games that I bought for the PC, and neither one of them works the way I want my Sudoku game to work-- so I *definitely* want to finish my Sudoku game, because *I* want to be able to play it, too!

 

Michael

[supercat]

John (supercat) told me that the 4A50 cart should be able to handle smaller games, if they're a nice power of 2 (i.e., 128K standard, or 64K, or 32K, or even 16K, etc.). But I got the impression that the actual cart would still contain 128K, with the game code duplicated as many times as needed to fill up the ROM (i.e., 64K+64K, or 32K+32K+32K+32K, etc.). So creating a smaller game won't reduce the price of the finished carts, since they'll still be 128K in size-- in which case I'm perfectly happy to use the 128K of ROM for things like more advanced puzzle-solving logic, including a lot of pre-generated puzzles, having several different tunes, etc.

 

A 128Kx8 flash chip costs $0.92 in quantity 100. I went with 128Kx8 because it was the cheapest size. If I used a 32Kx8 one-time-programmable ROM, that would be about $0.10 cheaper, but would have to be programmed before being soldered to the board.

[SeaGtGruff]

A 128Kx8 flash chip costs $0.92 in quantity 100. I went with 128Kx8 because it was the cheapest size. If I used a 32Kx8 one-time-programmable ROM, that would be about $0.10 cheaper, but would have to be programmed before being soldered to the board.

So you're saying smaller actual ROM sizes are possible, but they wouldn't really be much cheaper? In any case I'm happy to stick with 128K and fill up the ROM with music, pre-generated puzzles, etc.

 

Actually, for the interleaved-flickering multicolored-playfield tile-based adventure game that I started to mull over, I'd love it if I could have *more* ROM, like 256K instead of just 128K!

 

Michael

[Nognir]

Great!

 

I can't wait to solve nearly thousands of Puzzles.