nanochess

I can remember Jennell Jaquays interview saying they played the arcade, recorded videotapes of the gameplay, and used stopwatches to measure timings in order to recreate the game. So in fact they didn't reverse engineered the game, but reimplemented it based on the visuals and behavior of the arcade while playing it. https://www.retrovideogamer.co.uk/rvg-interviews-jennell-jaquays/

Ok. I now have enough data to write a very informative article on Video Chess and some of the techniques that were used in its code. However, I disassembled it because I wanted to know about the level 6 and 7 bug. I've a very good suspect based on the small stack space available, but I need to find a way to prove it. Also some code triggers a pattern in my mind, and I need to compare against an older chess program.

So far there is nothing like trees and nodes. This is what I've got so far (still work to do, because I'm searching how it validates legal moves, and where it returns to video chores). It is based on a simulated stack using 4-bit values preserved in the same bytes as the chessboard (lower 4 bits for board). It starts analyzing the board from the bottom-right corner, and once it finds an own piece, it saves the current state in this simulated stack, it does the movement, and it starts another board analysis with the opposite side (it can deepen even more), once this is finished, it reverts the movement using the information on the stack, and it continues where it was.

I'm curious enough so I've started disassembling and analyzing the code of Video Chess. Edit: So far I found the Reset/Select buttons code operation and how the chessboard is setup so now I know how the pieces are represented and the board addresses. Edit 2: Now I know where it handles the joystick movement and button, along with the chessboard editing feature. I found the movement generator, the code to restore the board after a movement, and the code to change the background color as the Atari "thinks". Now I need to find the code that saves the board state before a movement.

I never have found a failed crystal. I would suspect the TIA is having an "almost" short-circuit.

Thanks! It is a nice review 😃

It depends on how much dialogue you expect to have. My suggestion would be to code the first few screens, and then having a semi-playable game you can estimate/calculate the size of your dialogs. For a first game it is entirely possible everything can fit without compression.

Mr. Chess review by Gray Defender

I saw the title... but... resistance is futile 😂

I've wrote a small article about the development of Mr. Chess for Intellivision. It includes the source code of the earliest version (though not a full game) Enjoy it! https://nanochess.org/mr_chess.html

It is a special type of dress for women.

Apparently yes. The mystery was why the red block wasn't shown the way it was supposed to.

Hi @Lillapojkenpåön I revised your code and it is working fine. However, the thing that is bothering you is logical. My first test was to make sure your right macro was calculated correctly. To do this, I marked each floor tile as red as the square walks, using this code (just before SPRITE 2): temp4 = right #backtab(220 + temp4) = BG00 + FG_BLACK + BG_RED 'stones With this code I was sure your right macro is correct. You can see how each stone gets red in turn in the correct place. The second test took me a little longer because a logical fallacy. The important things is: the background is affected by hardware scrolling counters, but MOB's aren't affected by hardware scrolling counters. So this means that any position used for sprites is the real position in screen as if scrolling isn't happening, and that's why we need to adjust sprites with the scrolling offsets. However, if you are going to use a sprite to pinpoint a card on the screen, you need to use the real coordinate. The correct code to make your red sprite to pinpoint correctly the card is this: temp4 = right * 8 + PF_DIFF 'temp4 = left * 8 + PF_DIFF SPRITE 2, temp4 + HIT + VISIBLE, (#playerY AND 255) + ZOOMY2, SPR16 + SPR_RED Notice the removal of the fine adjustment. So the code was always right. It was only the display code that wasn't right, but you weren't aware of the coordinate differences between the card background world and the sprite world. Probably I'm not using the standard STIC language for describing these, but I'm sure @DZ-Jay can correct any of my non-sense

When envelopes are used, the "command code" for the envelope should be loaded a single time at the start. Otherwise the envelope is "resetted" continuously creating a "motor" noise. if throw_sound = 1 then IF SND = 0 THEN sound 4,$0f,$0007 sound 2,$0BB8,$30 sound 3,$0800,$0004 END IF snd = snd + 1 if snd = 20 then SOUND 4,,0 SOUND 2,,0 SOUND 3,,0 snd = 0 throw_sound = 0 end if end if

Congratulations to the winners!

The final number depends entirely on the publisher. But of course I would be happy of reaching 200 copies.

Boxes are ready! And games are being built!

Thanks for your comments! You can also try https://lulu.com/spotlight/nanochess It doesn't require registration to shop.

Overlays ready! Btw one set of four games is available because it wasn't paid.

Just in case you like fast-camera movements: (and yep, I was unable to change the automatic pronunciation to English)

I thought someone was playing 24 hours of Donkey Kong on Intellivision 😂 My second thought was that someone made a room-size Intellivision. 😅

Manuals are now printed

Just I've been informed there are (still) two sets of four games (it was miscounted before). People ordering the four games together will get ROM files for the four games, PDF manuals, and JPG of the boxes, and this is immediately after your payment. BTW cartridges are being built 😉

Now that is Apr/02 here is a video of the game