External Module

That SHOWBYTE procedure is great! It'll be used ALOT in future programs. How else can you show the user what number the program has calculated?
BUT, if we use the SHOWBYTE procedure in every program, that means we have to include it's code into every programs's source.
There is a solution.
We will Compile (NASM) SHOWBYTE by itself . Then Link (Alink) it to whatever program needs to use it.

To accomodate this arrangement, we need to:
1) declare "showbyte" as GLOBAL in it's local source-code
2) declare "showbyte" as EXTERN (external) in the source-code which calls upon it.
that's it.

The next program will show the changes made to the SHOWBYTE source-code to make it an external module. The instructions don't change, but it's directives do.
The new Showbyte Module introdces the PUSH and POP instructions, which we use to save the calling code's register values.

When you need to link SHOWBYTE to another program (let's say: pacman.asm/pacman.exe), do the following:
NASM -f obj PACMAN.ASM
NASM -f obj SHOWBYTE.ASM
ALINK PACMAN SHOWBYTE -o PACMAN.EXE

You can also keep SHOWBYTE around as an Object file (.obj, the output of NASM). Then there's no need to re-compile it a thousand times.

After you have SHOWBYTE coded as an independant module, the following tutorial (#7) will be a simple test program that demonstrates calling SHOWBYTE.

Idealy, you'll want the code in external modules to be placed in the same segment as code in the main module.
Same goes for data. This is done by giving segments the same name. Segments with the same name ARE the same segment.

If you're making a BIG program, then you'll want to give segments different names, because you might be running into the 64K segment barrier.

Here's some info on segments.
You make a near call if you're calling code within your present segment.
That means you are calling a 16-bit offset address.
You make a FAR call if you're calling code OUTSIDE of your present segment.
That means you are calling a 32-bit segment:offset address.