Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Video Chess disassembled and commented

nanochess.org

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Video Chess disassembled and commented

#51

Post by kstrauser »

JohnBooty wrote: post #38
giantrobot wrote: post #23

Earlier quoted context omitted.

Keep in mind is these kind of things have a flat memory space between RAM and ROM. It's not like today where disk is some thing way over there that you need to buffer in RAM. All of your code and resources are in ROM which means they're just an address away. Your RAM is scratch space for dynamic values but you can pull everything else from ROM. For instance your bitmaps for pieces/spaces are stored in ROM, the code c…

Keep in mind is these kind of things have a flat memory space between RAM and ROM This is true and is very central to how these miracles were pulled off. While you know this, for the benefit of those reading: you could also use ROM for time/space tradeoff purposes -- for example instead of doing a bunch of trig calculations in real time for character movement purposes you could just have lookup tables in ROM. the cod…

Wait, the Genesis, which came out in '88, had to race the beam like an old Atari?

Re: Video Chess disassembled and commented

#52

Post by eggy »

I have Oscar's 'Programming Boot Sector Games' and I worked through it last summer. Great fun! And having programmed from 1978 on a Commodore PET 2001 in PET Basic and later on Vic-20 and Amigas in assembler and C, I learned a few new tricks from Oscar's book. Constraints hone your skills, so when you are buried in large frameworks and IDEs you can take some solace that not everything needs to be so complicated. It's also why I enjoy APL/J/BQN and April (APL Re-Imagined in Lisp).

Re: Video Chess disassembled and commented

#53

Post by toast0 »

vikingerik wrote: post #34
Someone wrote: post #18

Earlier quoted context omitted.

> But holy how, that chess game really pushed the limits! Having 4 kilobytes of ROM made it relatively easy, I think. If one ignores draws by repeated positions (which I think all small chess programs do), board state can easily be stored in 67 bytes or so (64 for the board proper plus four bits for whether various castlings are allowed, plus a byte indicating the square for en passant opportunity, plus a byte for co…

Each square of the board doesn't even need a byte, only a nibble. There are 6 piece types so that fits in 3 bits, plus one for color. If you pack two of those nibbles per byte then you can do it in 32 bytes plus the castling and en passant bits. Video Chess uses the lower nibble of 64 bytes for the board, and the upper bits of those for various other purposes. You actually could condense further than that. Build the…

> writing an engine for that data structure is much more cumbersome, since it can't look at a square to find what piece is on it, instead it has to iterate over all the pieces to find out what's on a square.

Ignoring the move generation, this is also way harder to render the output with. The Atari 2600 has very few cpu cyles per line, and I don't know if you'd have enough time to iterate through all the pieces to see if and where they are on the current line, even given that several video lines are spent on each chess rank.

Re: Video Chess disassembled and commented

#54

Post by soegaard »

danmaz74 wrote: post #39
soegaard wrote: post #32

Earlier quoted context omitted.

Looks neat. Better call the puzzle training something else than Puzzle Rush though.

> Looks neat. Thank you. > Better call the puzzle training something else than Puzzle Rush though. Why? I think it's the most recognised name for the sequence of puzzles becoming harder and harder, even if I removed the time limit (as that leads to not learning much :)

It’s trademarked.

Re: Video Chess disassembled and commented

#55

Post by billforsternz »

reaperducer wrote: post #36
kstrauser wrote: post #3

I think I’m pretty good at writing software, and then I see stuff like this, and the impostor syndrome kicks in hard. A fully working chess game in 4K of ROM, using each of the 128 bytes of RAM for several purposes? That’s some genius. Bravo to OP for the disassembly and explanation, too!

A fully working chess game in 4K of ROM, using each of the 128 bytes of RAM MicroChess says hold my 924 byte beer: http://www.benlo.com/microchess/index.html MicroChess is also believed to be the first home computer software that was available for sale to the public. I have this on my KIM-1, and I find watching it play itself kind of soothing.

I'm featured on that page, for porting it to C for running on modern PCs. But by far my favourite retro chess software project is Sargon 1978 https://github.com/billforsternz/retro-sargon

Re: Video Chess disassembled and commented

#56

Post by toast0 »

kstrauser wrote: post #51
JohnBooty wrote: post #38

Earlier quoted context omitted.

Keep in mind is these kind of things have a flat memory space between RAM and ROM This is true and is very central to how these miracles were pulled off. While you know this, for the benefit of those reading: you could also use ROM for time/space tradeoff purposes -- for example instead of doing a bunch of trig calculations in real time for character movement purposes you could just have lookup tables in ROM. the cod…

Wait, the Genesis, which came out in '88, had to race the beam like an old Atari?

The races are quite a bit different. On an Atari, pretty much all games spend the screen on time feeding the TIA chip; with most or all of the game logic happening during vblank.

On a Genesis, games spend most of vblank feeding the VDP chip with sprite and other graphics data, and then can run their game logic during the screen on time. With some effects requiring frobbing the VDP chip during the drawing phase.

However, the genesis and contemperaries still don't have a frame buffer, so their graphics chips are processing background tiles and sprites pretty much just in time. I see some notes that the Genesis VDP does some of this work earlier than most others, so something like changing sprite position data in vram won't be effective until the next frame, whereas contemporaries can reuse a sprite on the top and bottom of a frame by repositioning it in the middle. Otoh, the Atari 2600 doesn't really have sprites, you have to program the TIA with patterns each line.

Re: Video Chess disassembled and commented

#57

Post by JohnBooty »

kstrauser wrote: post #51
JohnBooty wrote: post #38

Earlier quoted context omitted.

Keep in mind is these kind of things have a flat memory space between RAM and ROM This is true and is very central to how these miracles were pulled off. While you know this, for the benefit of those reading: you could also use ROM for time/space tradeoff purposes -- for example instead of doing a bunch of trig calculations in real time for character movement purposes you could just have lookup tables in ROM. the cod…

Wait, the Genesis, which came out in '88, had to race the beam like an old Atari?

It's beam-chasing, BUT in a much more powerful and programmer-friendly (declarative, really) tile based way. All of the 8- and 16-bit home and arcade systems essentially worked this way.

For the Genesis you've got two independent background layers. They are made of tiles. You also have 80 sprites which are also tiles.

For each sprite, you give the system an X,Y position and a pointer to VRAM for the graphics data.

For each background layer, you give it a scroll offset and a list of pointers to VRAM for the graphics data. Very similar to sprites, but you move the whole layer at once so each tile doesn't get its own X,Y.

You don't have to do this on every frame. It will just keep drawing the same thing over and over until you change something. You don't have to do steps 1 through 3 on every single frame - you just make the changes you need. If the game is paused or the player hasn't moved, for example, you might not do anything at all.

You have a limited amount of time during VBLANK (the time between frames) to do graphics work. This is where you update sprite/background positions, transfer data, change palettes, whatever.

You have an even more limited amount of time during HBLANK (the time between individual lines in a frame) to do things as well. A common use for this is updating the background scroll position in the middle of the frame. This is how you get "line scrolling" effects like the cool pseudo-3D floor effect in Street Fighter II. You can also change palette colors. This is how you get the transparent water effect in Sonic the Hedgehog even through the Genesis doesn't have true alpha transparency - you change the palette part of the way down the screen during VBLANK.

Re: Video Chess disassembled and commented

#58

Post by sitkack »

rahen wrote: post #50
reaperducer wrote: post #49

Earlier quoted context omitted.

I'd love to see a dev setup for using the PDP-11 and the Atari 2600 for doing gamedev. I did a quick search on youtube and the search engines and couldn't find anything. The photographs I've seen aren't all that interesting. A VT-52 terminal and a hand-built cart wired into an RS-232 port, all on a long desk. Hopefully there are more exciting photographs out there that I haven't seen.

Have a look at the PDF document here: https://forums.atariage.com/topic/259003-intellivision-devel... Also check out the links provided at the end of the document. Besides the PDP-11, I'm glad to see the beloved PDP-10 was also used by game developers back in the days.

Be see, I mean a demo of what it is like to dev Atari 2600 games using a PDP-11. I mean there are PDP-11 emulators, we could setup a pure virtual Atari dev system.

Re: Video Chess disassembled and commented

#60

Post by raldi »

devit wrote: post #42
dws wrote: post #29

Many years back (so details are fuzzy), a friend who worked at Atari in the early 80's told that the programmer who did the game part of the work had the basic chess algorithm working in a few months, spent the next year getting it to run in less than 128 bytes of RAM, and was then burnt out and left tech. IIRC, the game devs used a PDP-11 for much of their work, so that had a bit more RAM to work with to get started…

The 128 bytes of RAM seems quite easy (game state is 32 bytes for chessboard + 1 byte for side-to-move+castling+en-passant plus 2/3 bytes per move in the search stack + 1 byte to record the depth at which castling was disrupted = 54/64 bytes with depth 10, leaving a luxurious 64/74 bytes for call stack and local variables). The problem seems to be more the 4KB of ROM, but only if one is trying to make it actually som…

But the computer also needs to keep a scratch space to consider potential moves it could make, which if done in a straightforward manner would exhaust the other 64 bytes of memory.
Post reply on HN