This code's entry point is 100 bytes from the start of the segment. This is signature of old school DOS COM files.
This moves a 16-bit pointer in screen_data to di. It is 16-bit because it is only using DI which is a 16 bit register. However that code might not do anything constructive since the appropriate full pointer load in16-bit assembler - which this has to be since it is a COM binary - is to use lds or les. I also would reckon this comes from MASM source since MASM auto-assumes the segment for all pointer loads is ES (ASSUME ES) by default. NASM, FASM, and TASM make no such assumptions.
The first line zeroes out al by using the xor reg,reg operation. To figure this out read about binary operators.
The next line moves a value into cx or the count register in preparation for a rep sto(x) or rep mov(x) - a string operation or a memory copy operation. Since this is using 80*50*2 I would say this is for 80x50 color text mode. The 2 is simply because each cell in the mode requires two bytes to represent this value:
The line rep stosb is this:
rep will execute the opcode immediately following it for cx number of times. The direction of the count (increment or decrement) is found by checking the DF flag or the direction flag. There are 2 opcodes to clear and set the direction flag.
I would say this function does a complete memory copy to a text mode 80x50 color screen.
There is a standard in assembly language. In fact there are 2 machine-level standards in PCs. Mac or Intel x86. AMD can be considered x86 except it does not support SSE/SSE2/or MMX2 - it does support MMX version 1.0 but they paid a hefty price for this support.
Now there are more syntaxes than just intel x86, but even AT&T syntax on an x86 platform is still x86. No matter what the assembler does - it always ends up as Intel syntax x86 code.
All of the popular assemblers have already been mentioned previously in this thread. I recommend NASM.
A similar bit of code to copy a mode 13h back buffer to the screen would look like this: