Pong in Assembly

[Stonemonkey]

I think that because the code for ESC is 1, if you decrement it the zero flag wil be set so you then test that to see if ESC has been pressed.

[Jim]

http://flint.cs.yale.edu/cs421/papers/art-of-asm/pdf/APNDXC.PDF
Absolutely, Esc is 1 so subtracting 1 will set the z flag and there you go.

You can use in,60h if you like but I think using a DOS call might be better.
Ralf Brown http://www.ctyme.com/rbrown.htm has a web page which no DOS programmer can ignore. 15 years ago, that guy was a hero for building this list.  I wonder what he does these days?

Jim

[Phoenix]

I decided to use the "in al, 60h" method; it works, and that's good enough for me I'm slowly progressing with this thing now, and I found some v sync code by Rbraz:

Code: [Select]

VSync: mov dx, 03DAh
       in al,dx
       test al,8
       jz VSync
I have no idea why that works. What does "in" actually do?

[Shockwave]

in is a command that samples input from various ports on the computer, the operand on the left is the byte location that you want to store the incoming data and the right operand is the port number.

You could use in like this too;

Code: [Select]

in al,60h
dec al
jnz main

To check if escape had been pressed for instance. There are loads of ports that you can look at to do different stuff

[Rbz]

"IN reads a byte, word or doubleword from the specified I/O port, and stores it in the given destination register. The port number may be specified as an immediate value if it is between 0 and 255, and otherwise must be stored in DX."

Have fun

[rain_storm]

Reading input from port 60h is useful when you are optimising for size since it saves one byte compared with int 16h. This meathod is useful in tiny code (256 byte demos) but size is not an issue with this program so as Jim said you should just read the keys via int 16h. Unless you want to experiment with reading ports in which case I say go right ahead

[Phoenix]

Oddly enough, everything is rendered just fine with one exception. Everything that's drawn at the top ~30 pixels is invisible or flashing heavily. Does anyone know what the problem might be? Should I post the source?

[rain_storm]

That could be due to a number of reasons

The segment register may not be set to 0A000h when writing to video memory
The offset may be incorrect
Your monitor might not be vertically centered for 320x200 8bpp resolutions

Post what you have so far and we can eliminate some possibilites if that doesnt work try setting your monitors vertical-center / horizontal-center whilst in mode 13h. I often have to do this for my monitor it  seems its only mode 13h & FreeBasic programs that are an issue for me.