AtariAge Forums: AtariAge Forums -> Zach's Projects

I am a long time Windows user who just set up a new computer on Saturday, a Mac Mini running on OS X Leopard. I didn't get the Mac to replace my PC, and I plan to use both for a long time to come. In fact, they share the same keyboard, monitor, and mouse. I haven't even used it for 12 hours yet, so here are my first impressions.

Pros:
Overall easy to navigate operating system.
Calculator with programmer mode.
Graphing calculator!
Built-in dictionary. What took so long?
Weather panel.

Cons:
No built-in simple paint program equivalent to mspaint. Um, didn't Apple pioneer this kind of application? I spent a while looking over free Linux programs before I found Paintbrush.
Having to use a different key for keyboard shortcuts. Hopefully there's a way to change this without going too deep in the code.
Font in Safari is harder to read than Firefox on my PC. I'm using the same monitor, but I'm getting headaches more easily on the Mac. I'm sure there's a way to change the fonts, but it was nice when Firefox looked good from the start.
Safari doesn't display URL's of links before you click them? Maybe I'll install Firefox on the Apple as well.

Again, I haven't been using it that long, and these are just first impressions. I haven't even tried iTunes and some of the other software yet.

It has been over a year since I've posted anything to my blog. Unfortunately I do not have much time for homebrewing these days, but I still hope someday to get back to some of my unfinished projects.

A while ago, I took on the challenge of making a chess kernel without flickering or Venetian blinds. After many aggravating attempts, I finally got it with some convoluted code. I know a chess homebrew is low priority compared to the other projects I've started, but I've been thinking about how better chess AI could work on the 2600.

There was a brief discussion in this thread about making a better chess game by allowing more RAM and ROM. However, by employing more efficient data storage, it should be possible to work with the standard 128 bytes of RAM.

The idea is to encode a chess ply (a move by a single player) in one byte. You need a way to encode a chess move in such a way that can be undone. The most obvious way to encode a ply is to save the chessman's starting square, ending square, and the identity of a captured piece, if any. Normally that would take three bytes, and this encoding would fill up RAM quickly as the computer looks ahead.

For a long time, I didn't think it would be possible to reduce a ply to one byte, but I recently figured out how, in conjunction with a 64 byte array to store the board. The idea takes advantage of the fact that pieces don't move to just any square on the board. Each piece is limited to a few squares where it can move at any time. The piece that can move to the most squares is the queen, and the maximum number of places where she can go is 27.

-- -- -- 04 -- -- -- 18
24 -- -- 03 -- -- 17 --
-- 23 -- 02 -- 16 -- --
-- -- 22 01 15 -- -- --
12 13 14 -Q 08 09 10 11
-- -- 21 05 25 -- -- --
-- 20 -- 06 -- 26 -- --
19 -- -- 07 -- -- 27 --

So, the queen's move can be limited to 5 bits. The queen's starting point does not really need to be saved because she can be found on the board. I do not need to be concerned with the whether the black or white queen is moving, because her color is implied by the position in the search tree. Thanks to pawn promotions, there can be more than one queen, so I need 2 bits to keep track of which queen is moving. (That leads to a maximum of four queens. Even though more queens are legally possible, it is not likely to happen in a practical game. A reasonable compromise, I think.) Finally I need one bit to indicate that the piece moving is a queen rather than some other piece.

And so the coding for a queen move would look like this:

1|XX|XXXXX
1 bit: Indicates queen move
2 bits: One of up to four queens
5 bits: One of 28 possible moves. Each of 1-7 squares to the right, up, up-right, and up-left (with wrapping).

Similarly, rooks and bishops can move to 14 places, so a rook/bishop move would look like:

0|1|XX|XXXX
1 bit: Not a queen move
1 bit: A rook or bishop move
2 bits: One of two rooks or two bishops (Unfortunately, this scheme does not allow for three or more rooks/bishops, which is legally possible with pawn promotions.)
4 bits: One of 15 possible moves. Whether the moves are read as rook or bishop depends on the value of the previous two bits. There are actually 14 standard moves, and 1 special move, castling. Whether the castling is king's side or queen's side can be ascertained from the rook's position.

Next are king/knight moves
0|0|1|XX|XXX
1 bit: Not a queen move
1 bit: Not a rook/bishop move
1 bit: A king/knight move
2 bits: Which king/knight. Up to three knights are possible.
3 bits: The move. Both kings and knights can go to up to eight squares.

Finally: Pawn moves:

0|0|0|XXX|XX

1 bit: Not a queen move
1 bit: Not a rook/bishop move
1 bit: Not a king/knight move
3 bits: Which pawn
2 bits: The move. Either 2 steps forward, 1 step forward, or a leftward/rightward capture.

The question is now how to store captures. At first I thought I'd need an additional byte to record them, until I realized that there are plenty of empty squares in the board array. Whenever a piece captures, it swaps positions with its captive, and a flag is set to indicate the captured piece is no longer in play. Of course another piece may need to move to that square, so pieces will have to swap with every move, whether a capture or not. Some mechanism will be needed to indicate when an undo returns a captured piece to the board. What I'm thinking now is that three bits can indicate the current depth of the search, and during an undo when it reaches 0 it comes back into play. That allows for a 14-ply tree, which is probably deeper than the Atari can handle in a reasonable amount of time.

Undoing en-passant captures is a little tricky, and I haven't ironed out all the details yet, but I'm sure it can be done. Again, this whole article is just a description of what is possible, not a plan to get back to work on chess. If I do find time for homebrewing again, Chetiry will be my first priority.

If you haven't seen it in the homebrew forum yet, I have posted a demo of a well-known Russian block game. The kernel manages 10 independently colored blocks at 8 pixels wide. (Well, 9 pixels for the far right one.)

Although there are only 4 COLUxx registers in the TIA, VBLANK offers an often overlooked 5th color (always black).

There are four colors available for the first 4 cells: background, playfield, player 0, and player 1. There are also three registers that can be pre-loaded with new colors. Then there is just barely enough time to load and store the last three colors, only because I am running code in RAM and using immediate addressing. Finally, to close off the edges of the play area, I turn VBLANK on and off.

In order to turn on VBLANK on the right side, I chose color values whose bit #1 were set. Then whatever value was saved to COLUPF on the right could also be saved to VBLANK. Turning it off on the left side was more of a challenge. I ended up using PHP, knowing that none of the color values loaded were zero, and bit 1 of the status register would be clear.

I also experimented with SHX to clear VBLANK. It has the advantage of using fewer cycles and freeing the SP, but the disadvantage is that it is a little understood illegal opcode that may not be entirely stable. So far, my tests with SHX have been successful, but I'll stick to PHP unless I find another use for the SP.

Currenlty it takes two scanlines to update the colors for the next row. I wish I could have done it in one line, but the block data has to be compressed to fit in 128 bytes of RAM, and I don't see any way to unpack and store 10 colors in only 76 cycles.

Without further ado, here is the code for coloring the blocks, part of an unwrapped loop.

;------------------------------------------
	  pla
	  lda #<BackToRom1
	  sta SelfMod+22
	  lda color4;
	  sta COLUP1; block 4 
	  lda color1
	  sta COLUBK; block 1
	  lda color2
	  sta COLUPF; block 2
	  lda color3
	  sta COLUP0; block 3
	  lda color5
	  sleep 4
	  jmp SelfMod
BackToRom1
;--------------------------------------------

SelfModCode; byte count
	  php; 0; turn off vblank
	  sta COLUBK; 1 2; block 5
	  stx COLUPF; 3 4; block 6
	  sty COLUP0; 5 6; block 7
	  lda #COLOR0; 7 8
	  sta COLUP1; 9 10; block 8
	  lda #COLOR0; 11 12
	  sta COLUBK; 13 14; block 9
	  lda #COLOR0; 15 16
	  sta COLUPF; 17 18; block 10
	  sta VBLANK; 19 20
	  jmp BackToRom1; 21 22 23
;-------------------------------------------

EDIT: Added a screenshot using DEC VBLANK. (I tried this on hardware too.)
[attachment=1784:attachment]

EDIT2: Check out what INC VBLANK does!
[attachment=1787:attachment]

I've been busy making an applet of Catacombs of Mu. Since it's an original game, I thought it would be a good idea to try out the gameplay before doing any 6502 coding.

I'm aware that there are bugs, and am not looking for bug reports at this time. Also, I probably will tweak the gameplay. I just wanted to show you what I've been working on:

http://gaia.ecs.csus...leyz/mu/mu.html

p.s. The game flickers more on some systems than others. Now I understand why most Java applet games have a small width and height.

OK, I changed the colours in Four-Play for those of you who live across the Atlantic, (or the Pacific, for you Aussies and Kiwis.)

The colours look good in z26 to me. Anyone care to try on hardware?

Today I built a bike light out of a prototype board, a 9V battery connector, a resistor, and an LED. It won't win any beauty contests, but it works. I have new respect for the people around here would build their own hardware, because I've now dealt with wires slipping out of holes heat them, getting plastic insulation too close to the iron, cutting a wire too short, etc.

One problem I had was that the holes in the prototype board were too small to insert two wires that I wanted to connect. I thought I could put them in adjacent holes, but getting a piece of molten solder in between was pretty tough, since there was nothing in between to heat. Any suggestions?

Why should you care that I made a bike light? Simple: I am building experience so I can make a cart dumper that can be used for the Charlie Brown prototype that resides here in Northern California.

Unfortunately this won't be done in time for the Four-Play release.

[attachment=1368:attachment]

If the design is really as simple as shown below, and if it could actually work, this could be a good electronics project for a beginner like myself. It seems to be just a matter of attaching wires.

If the dumper is safe, I can think of a certain undumped Charlie Brown prototype that resides here in Northern California. It was batari who first suggested the idea of using a switch to make his dumping program work safely, although what he described is a little different.

[attachment=1225:attachment]

I already have the AA board and batari's dumper program on an EPROM. I believe a cartridge slot can be purchased without much difficulty. Although an Atari board is easy to find, removing the chip will be some work. I don't know if such a thing as a 48-24 multiplexor with a switch exists, or if multiplexor is technically the correct term, but I think you can figure out what I mean. So what do you think? Would it work? Would it be safe?

-------------------------------------------------------------------------------
EDIT: Added a new diagram based on suggestions from batari.
[attachment=1228:attachment]

[attachment=1207:attachment]
[attachment=1208:attachment]
[attachment=1237:attachment](new binary with bug fixes and new puzzle #1)

[attachment=1463:attachment]

Overall, I thought the comments from the 2006 1K compo were fair. The addition of new puzzles should significantly improve gameplay.

Note that all puzzles can be solved from any starting square. Also, the first puzzle is just a warm up; if you keep moving, you can't lose.

If you are new to Knight Jumper, the object of the puzzle is to guide your chess knight across the board touching each square exactly once. First move the knight to the starting square of your choice and then press the FIRE button to begin. From then on, just move the knight to the next square. You can FIRE to undo the most recent move, except at the end of the game. When the game is over you can reset with the FIRE button. Use SELECT and RESET for their obvious purposes.

It's nearly finished, with just a couple details to take care of. I still need to double and triple check that all the puzzles have solutions, and I want to make the scanlines stable during a FIRE reset.

Have Fun!

[attachment=1197:attachment]
(actual screenshot)

Here's another kernel that I would have not thought possible earlier. It draws up to 17 objects that can independently be any of 5 colors. I'll give you all a chance to guess how this works before explaining it.

Here are some details. Are they useful as hints?

• The ball is available as a cursor, and can be a 6th color.
  
• Colors are very limited: the choices are $3X $7X $BX or $FX.
  
• If the number of objects in a row is at most 11, the color choices are unrestricted (except for one, which depends on A and X.)
  
• If the number of objects per row is 10 or less, you can make more interesting shapes with the PF.

One fun application would be a Sega Swirl clone.