💾 Archived View for clemat.is › saccophore › library › ezines › textfiles › ezines › APJ › apj_6.txt captured on 2021-12-03 at 14:04:38.
-=-=-=-=-=-=-
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::. Oct/Nov 99
:::\_____\::::::::::. Issue 6
::::::::::::::::::::::.........................................................
A S S E M B L Y P R O G R A M M I N G J O U R N A L
http://asmjournal.freeservers.com
asmjournal@mailcity.com
T A B L E O F C O N T E N T S
----------------------------------------------------------------------
Introduction...................................................mammon_
"Processor Identification"........................Chris.Dragan.&.Chili
"Timing with the 8254 PIT"...............................Jan.Verhoeven
"Programming the Universal Graphics Mode"................Jan.Verhoeven
"Conway's Game of Life".................................Laura.Fairhead
"'Ambulance Car' Disassembly"....................................Chili
"'Ambulance Car' Disinfector"....................................Chili
"Assembling for PIC's"...................................Jan.Verhoeven
"Splitting Strings"............................................mammon_
"String to Numeric Conversion"..........................Laura.Fairhead
Column: Win32 Assembly Programming
"WndProc, The Dirty Way".................................X-Calibre
"Programming the DOS Stub"...............................X-Calibre
Column: The Unix World
"Using ioctl()"............................................mammon_
Column: Assembly Language Snippets
"BinToString"....................................Cecchinel Stephan
Column: Issue Solution
"Absolute Value"....................................Laura.Fairhead
----------------------------------------------------------------------
++++++++++++++++++Issue Challenge+++++++++++++++++
Find the Absolute Value of a Register in 4 Bytes
----------------------------------------------------------------------
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::..............................................INTRODUCTION
by mammon_
Customarily I'll start with the bad news: this issue is about a week late,
primarily because I had forgotten about the two Win32 articles X-Calibre
passed on to me a month or two ago. The good news, however, is that there
may be a December issue; currently I have about 5 or so extra articles that
threatened to bump this issue over the 200K mark. Evenutally I may have a
chance to be late on a monthly basis...
This issue has a bit of a 'back to the basics' feel about it. Packed inside
are articles dealing with some of the 'classics' of assembly: CPU identific-
ation, graphics, and the ever-popular Game of Life. The disassembly of the
Ambulance Car virus also has an old-school feeling to it, hearkening back to
the old days of DOS and com files.
Additional highlighs include X-Calibre's 'bending windows to your will' Win32
articles, two excellent chip programming articles from Jan, utility routines
from Laura and myself, and of course my usual attempt to defend assembly as a
viable programming language for the Unix environment.
Enough commentary; time to get this mag on the road!
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Processor Identification
by Chris Dragan & Chili
Being able to identify the processor in which your program is running, can be a
very useful feature, if not to ensure that your program will work on a wider
range of computers, at least to provide minimum compatibility and guarantee it
not to crash on some processors.
The first part of this article explains how to distinguish between older 80486
and lower processors by checking for known behaviours, while the second part
(written by Chris) takes it one step forward, explaining how to use the CPUID
instruction on newer processors, checking the ID register by means of a TFR and
how to correctly identify a Cyrix processor.
EFLAGS Register
---------------
On old pre-286 CPUs, bits 12 through 15 of the FLAGS register are always set,
so we can check for this type of processor, in opposition to newer ones, by
attempting to clear those bits:
pushf
pop ax
and ax, 0fffh ; clear bits 12-15
push ax
popf
pushf
pop ax
and ax, 0f000h
cmp ax, 0f000h ; check if bits 12-15 are set
je _is_an_older_cpu
jne _is_a_286_or_higher
Once we know that we are at least on a 286 processor, we can then check to see
if we're on a 32-bit processor (386 or higher) or on an actual 286. For this
purpose we know that bits 12-15 of the FLAGS register are always clear on a 286
processor in real mode:
pushf
pop ax
or ax, 0f000h ; set bits 12-15
push ax
popf
pushf
pop ax
and ax, 0f000h ; check if bits 12-15 are clear
jz _is_a_286
jnz _is_a_386_or_higher
If instead, the processor is running in protected mode these bits are used for
the IOPL (bits 12-13) and NT (bit 14) flags. Note that bits 12-14 hold the last
value loaded into them on 32-bit processors in real mode. Also remember that
there is no virtual-8086 mode on 16-bit processors.
In order to find out if the processor is in real or protected mode we must test
if the Protection Enable flag (bit 0 of CR0) is set, if so then we're in
protected mode:
smsw ax
and ax, 0001h ; check if bit 0 (PE) is clear
jz _real_mode
jnz _protected_mode
To find out if it is a 486 or a newer processor we'll try to set the AC flag
(bit 18), since it is always clear on a 386 processor (also NexGen Nx586),
unlike newer ones that allow it to be toggled:
pushfd
pop eax
mov ebx,eax
xor eax,40000h ; toggle bit 18
push eax
popfd
pushfd
pop eax
xor eax,ebx ; check if bit 18 changed
jz _is_a_386
jnz _is_a_486_or_higher
And finally to check if we're in an old 486 or in a new 486 and other newer
processors (i.e. Pentium), we'll try to toggle the ID flag (bit 21) which
indicates the presence of a processor that supports the CPUID instruction. This
part is explained below in a section about CPUID.
PUSH SP Instruction
-------------------
Before the 286, processors implemented the "PUSH SP" instruction in a different
way, updating the stack pointer before the value of SP is pushed onto the
stack, unlike newer processors which push the value of the SP register as it
existed before the instruction was executed (both in real and virtual-8086
modes).
Older CPUs 286+
{ {
SP = SP - 2 TEMP = SP
SS:SP = SP SP = SP - 2
} SS:SP = TEMP
}
(credit for the PUSH SP algorithm representation goes to Robert Collins)
So all one has to do is see if the values of the SP register are different
before and after the PUSH SP:
push sp
pop ax
cmp ax, sp ; check if SP values differ
je _is_a_286_or_higher
jne _is_an_older_cpu
Note - If you want the same result on all processors, use the following code
instead of a PUSH SP instruction:
push bp
mov bp, sp
xchg bp, [bp]
Shift and Rotate Instructions
-----------------------------
Starting with the 186/88, all processors mask shift/rotate counts by modulo 32,
restricting the maximum count to 31 (in all operating modes, including the
virtual-8086 mode). Earlier CPUs do not mask the shift/rotation count, using
all 8-bits of CL. So, if we try to perform a 32-bit shift, on newer processors
we'll end up with the same result (since the shift count is masked to 0),
whereas on an older processor the result will be zero:
mov ax, 0ffffh
mov cl, 32
shl ax, cl ; check if result is zero
jz _is_an_older_cpu
jnz _is_a_18x_or_higher
MUL Instruction
---------------
NEC processors differ from Intel's with respect to the handling of the zero
flag (ZF) during a MUL operation. While a NEC V20/V30 does not clear ZF after a
non-zero multiplication result, but only according to it, an Intel 8086/88 will
always clear it (note that this is only true for the specified processors):
xor al, al ; force ZF to set
mov al, 40h
mul al ; check if ZF is clear
jz _is_a_NEC_V20_V30
jnz _is_an_Intel_808x
In addition to the list of sites where you can find more information, provided
by Chris at the end of this article, you can also try this one:
http://grafi.ii.pw.edu.pl/gbm/x86/ (Grzegorz Mazur)
And also the following packages/programs (available somewhere in the net):
The Undocumented PC (Frank van Gilluwe)
HelpPC (David Jurgens)
80x86.CPU file (Christian Ludloff)
ID Register
-----------
Beginning with the 80386 processor, Intel included a so-called ID register,
which contains information about the processor model and stepping. This
register is accessible in an unusual way - it is passed in DX after reset.
To read the ID register one must proceed the following steps:
1. By storing value 0Ah (resume with jump) at address 0Fh (reset code) in the
CMOS data area, inform BIOS not to issue POST after reset, but to return
the control to the program.
2. Update after-reset-far-jump address at 0040h:0067h.
3. Set shutdown status word (0040h:0072h) to 0, to avoid undesirable
side-effects.
4. Cause a reset.
Causing a reset is typically done by issuing a so-called triple-fault-reset,
i.e. causing an error from which the processor cannot recover and enters
a reset state. TFR (triple...) can be done only if we have enough control
over the processor, i.e. under plain DOS in real mode (no EMS) or under
Win'95 (this is risky). The following code shows how to do it in DOS. The code
is assumed to be in a COM program.
;------------------------------------------------------------------------------
section .data
GDT dd 0, 0 ; Selector 0 is empty
dd 0000FFFFh, 00009A00h ; Selector 8 - code segment
GDTR dw 000Fh, 0, 0 ; Limit 0Fh - two selectors
IDTR dw 0, 0, 0 ; Empty IDT will cause TFR
section .text
; Ensure that we are in real mode, not in V86
smsw ax
and al, 1
jnz near _skip_tfr_since_in_v86_mode
; Update code descriptor as we are going to enter pmode
xor eax, eax
mov ax, cs
shl eax, 4
or [GDT+10], eax
add eax, GDT
mov [GDTR+2], eax
; Update reset code in CMOS data area
cli ; Disable interrupts
mov [SaveSP], sp ; Save stack pointer
mov al, 0Fh ; Address 0Fh in CMOS area
out 70h, al
times 3 jmp short $+2 ; Short delay
mov al, 0Ah ; Value 0Ah - far jump
out 71h, al
; Update resume address
push word 0
pop es
mov [es:0467h], word _tfr ; offset
mov [es:0469h], cs ; segment
mov [es:0472h], word 0 ; Update shutdown status
; Switch to pmode
lgdt [GDTR] ; Load GDT
lidt [IDTR] ; Load empty IDT
smsw ax
or al, 01h ; Set pmode bit
lmsw ax
jmp 0008h:_reset ; Reload CS
_reset: mov ax, [cs:0FFFFh] ; Reach beyond segment limit
; After reset we are here with DX containing the ID register
_tfr: cli
mov ax, cs
mov ds, ax
mov es, ax
mov ss, ax
mov sp, [SaveSP]
sti
;------------------------------------------------------------------------------
Of course there are also other ways of reading the ID register. They are well
described in DDJ (www.x86.org).
As said before, the ID register contains information about processor model and
stepping. The format of the register is as follows:
bits 15..12 - stepping
bits 11..8 - model
bits 7..0 - revision
Some example ID register values:
0303 i386DX
2303 i386SX
3301 i376
This format of the ID register was used in Intel 386 processors (all except
RapidCAD), AMD 386 processors and most of IBM 486 processors.
Another format of the ID register was introduced with Intel 486 processors.
This format is similar to the format of CPUID model information (see below),
and until the Pentium was kept the same. However newer processors do not keep
any useful information in the ID register (it is usually 0). This also concerns
Cyrix 486 processors.
bits 15..14 - unused, zero
bits 13..12 - typically indicate overdrive
bits 11..8 - model
bits 7..4 - stepping
bits 3..0 - revision
And some example ID register values with this format for Intel processors:
0401 i486DX-25/33
0421 i486SX
0451 i486SX2
Cyrix DIR
---------
All Cyrix processors have a Device-Identification-Registers, which are used to
identify these processors. To read DIRs, one first has to determine that he
uses a Cyrix processor. This can be accomplished in two ways:
1. On modern processors using CPUID instruction.
2. On first Cyrix processors issuing 5/2 method.
If there is no CPUID instruction, one has to use the other way of
determination. If one knows that he is on a 486 processor, he can use the
following code:
mov ax, 0005h
mov cl, 2
sahf
div cl
lahf
cmp ah, 2
je _we_are_on_cyrix
jne _this_is_not_cyrix
Once we have determined we are on a Cyrix processor, we can read its DIRs to
get its model and stepping information. All Cyrix processors have their special
registers accessible through ports 22h and 23h. Port 22h keeps register number
and port 23h register value.
; This function reads a Cyrix control register
; It expects a register address in AL and returns value also in AL
ReadCCR: out 22h, al ; select register
times 3 jmp short $+2 ; delay
in al, 23h ; get register contents
ret
DIRs have offsets 0FEh (DIR1) and 0FFh (DIR0). DIR1 contains revision, while
DIR0 contains model/stepping. The following code reads them:
mov al, 0FEh
call ReadCCR
mov [DIR1], al
mov al, 0FFh
call ReadCCR
mov [DIR0], al
Example DIR0 values:
1B Cx486DX2
31 6x86(L) clock x2
55 6x86MX clock x4
CPUID Instruction
-----------------
All newer processors have the CPUID instruction, which helps to identify on
what processor we are. Before using it, we must first determine if it is
supported, by flipping the ID flag (bit 21 of EFLAGS).
pushfd
pop eax
xor eax, 00200000h ; flip bit 21
push eax
popfd
pushfd
pop ecx
xor eax, ecx ; check if bit 21 was flipped
jnz _cpuid_supported
jz _no_cpuid
The only problem may be that NexGen processors do not support the ID flag, but
they do support the CPUID instruction. To determine that, we must hook Invalid
Opcode exception (int6) and execute the instruction. If the exception is
triggered, CPUID is not supported.
Also some early Cyrix processors (namely 5x86 and 6x86) have the CPUID
instruction disabled. To enable it, we must first enable extended CCRregisters
and then enable the instruction, setting bit 7 in CCR4.
; Enable extended CCRs
mov al, 0C3h ; C3 corresponds to CCR3
call ReadCCR
and ah, 0Fh ; bits 7..4 of CCR3 <- 0001b
or ah, 10h
call WriteCCR
; Enable CPUID
mov al, 0E8h ; E8 corresponds to CCR4
call ReadCCR
or ah, 80h ; bit 7 enables CPUID
call WriteCCR
The following functions are used to read/write CCRs:
ReadCCR: out 22h, al ; Select control register
times 3 jmp short $+2
xchg al, ah
in al, 23h ; Read the register
xchg al, ah
ret
WriteCCR: out 22h, al ; Select control register
times 3 jmp short $+2
mov al, ah
out 23h, al ; Write the register
ret
After enabling CPUID we must test if it is supported by flipping the ID flag,
unless of course we have determined that we are not on a 5x86 or 6x86 by
reading DIRs.
Once we have determined that CPUID is supported, we can use it to identify the
processor. The instruction expects EAX to hold a function number and returns
information corresponding to this number in EAX, ECX,EDX and EBX. The two most
important levels are listed below.
level 0 (eax=0) returns:
eax Maximum available level
ebx:edx:ecx Vendor ID in ASCII characters
Intel - "GenuineIntel" (ebx='Genu', bl='G'(47h))
AMD - "AuthenticAMD"
Cyrix - "CyrixInstead"
Rise - "RiseRiseRise"
Centaur - "CentaurHauls"
NexGen - "NexGenDriven"
UMC - "UMC UMC UMC "
level 1 (eax=1) returns:
eax bits 13..12 0 - normal
1 - overdrive
2 - secondary in dual system
bits 11..8 model
bits 7..4 stepping
bits 3..0 revision
If Processor Serial Number is enabled, all 32
bits are treated as the high bits (95..64) of
the number.
edx Processor features (e.g. bit 23 indicates MMX)
There are also other levels, i.e. level 2 returns cache and TLB descriptors,
level 3 the rest of Processor Serial Number.
Other processors (AMD, Cyrix) also support extended levels. The first extended
level is 80000000h and it returns in EAX the maximum extended level. These
extended levels return information specific to that processors, e.g. 3DNow!
support or processor name.
This example code determines MMX support:
; First check maximum available level
xor eax, eax ; eax = 0 (level 0)
cpuid
cmp eax, 0
jng _no_higher_levels
; Now check MMX support
mov eax, 1 ; level 1
cpuid
test edx, 00800000h ; bit 23 is set if MMX is supported
jnz _mmx_supported
jz _no_mmx
As this is not the place for listing all the available information about what
values are returned by CPUID, ID register or DIRs, you should get the most
recent information from the processor vendors:
www.intel.com
www.amd.com
www.cyrix.com
Also you can find very valuable information about the identification topic on:
www.sandpile.org
www.x86.org
www.cs.cmu.edu/~ralf/files.html
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Timing with the 8254 PIT
by Jan Verhoeven
Some time ago I saw a note on the mailinglist from someone in need for a
flexible timer function. For this, there are several concepts.
First, there is the timertick which is updated every 55 ms. For long
time delays, this is the best method. Just read the timervalue at
0000:046C, add the desired delay (in 55 ms intervals) and wait until the
timer reaches that value.
A second approach is to use modern BIOS-ses which have a timingfunction
in BIOS interrupt 15h, but this is "only" present on machines from 1990
or later.
A third approach is to reprogram the RTC chip. No big deal, and there's
a very accurate timer in it (upto 8 kHz) which even has interrupt
capabillities for automated functions and simple multitaskings.
But by far the best way (and most universal and accurate) is to use the
"spare" timer in your PC's 8254 chip.
This chip can be put in many operating modes, but we want it to do the
following:
- start counting at a certain value
- count down
- latched reading mode
- no influence on further PC operation
The counting sequence for the PC is as follows:
- there are 2^16 BIOS-timervalue updates per hour
- there are 2^16 8254 clockpulses per timertick
So, there are 2^32 clockpulses per hour. This boils down to one clock
pulse being around 838 ns. Not bad.
In order to make things very clear I use Modula-2 to show how the
routines are coded. Modula is an extremely structured language, so I use
it as a kind of Meta-Assembler or Pseudo-Assembler.
For those not too familiar with Modula: a CARDINAL is not an old man in
a dress, but a 16 bit unsigned integer.
Here comes.....
---------- OpenTimer ---------------------------- Start ----------
PROCEDURE OpenTimer; (* open timer chip in mode 2 *)
BEGIN
ASM
MOV AL, 34H
OUT 43H, AL
XOR AL, AL
OUT 40H, AL
OUT 40H, AL
END;
END OpenTimer;
---------- OpenTimer ----------------------------- End -----------
The value 34h is constructed as follows:
bit function
----- ---------------------------
6 - 7 select counter (0 - 3)
4 - 5 Read/write mode
1 - 3 Select countermode
0 Binary or BCD
For this case we selected:
- counter 00
- read/write two bytes from/to counterchip
- Mode 2
- binary values
These few lines open the timer in "Mode 2" and prime the down counting
register to 0000. I would love to elaborate on the code, but this is all
which is needed....
It is kind of handy if you restore the state of your machine after your
application stops using the CPU. Therefore there is the following
function to restore "normal" operation of this channel.
---------- CloseTimer --------------------------- Start ----------
PROCEDURE CloseTimer; (* close timer chip *)
BEGIN
ASM
MOV AL, 36H
OUT 43H, AL
XOR AL, AL
OUT 40H, AL
OUT 40H, AL
END;
END CloseTimer;
---------- CloseTimer ---------------------------- End -----------
This function just restores the timer to it's default mode and clears
the counting registers. The value "36h" means:
- counter 00
- read/write two bytes from/to counterchip
- Mode 3
- binary values
---------- ReadTimer ---------------------------- Start ----------
PROCEDURE ReadTimer () : CARDINAL; (* read timer *)
VAR Time : CARDINAL;
BEGIN
ASM
MOV AL, 6
OUT 43H, AL
IN AL, 40H
MOV AH, AL
IN AL, 40H
XCHG AH, AL
MOV [Time], AX
END;
RETURN Time;
END ReadTimer;
---------- ReadTimer ----------------------------- End -----------
After we opened the timer, it might be a good idea to also use it. This
is done in a two-step operation:
- current value of counting register is stored in On-Chip buffer
- the low byte is read in first
- the high byte is read in second
- low and high byte are put in right order
Make sure you always read in TWO bytes, else you will run into framing
errors. Also keep in mind that this is a DOWN-COUNTER!
The value "6" which is sent to the 8254 first might be wrong, but in all
my software it just works fine. It selects Channel 0 to be latched. The
lower four bits of this word should be "don't care" bits, but I prefer
"not to fix a running program".
---------- MilliSeconds ------------------------- Start ----------
PROCEDURE MilliSeconds (ms : CARDINAL);
VAR MaxCount : CARDINAL;
BEGIN
MaxCount := 65535 - ms * 1193;
OpenTimer;
WHILE ReadTimer () > MaxCount DO
(* Nothing! *)
END;
CloseTimer;
END MilliSeconds;
---------- MilliSeconds -------------------------- End -----------
This function has some deliberate errors inside. I calculate MaxCount
such that it is too big. Reason: in Modula I do not control math
operations as well as in ASM (of course!) That's why I subtract the
value from 65,535 instead of 65,536. In ASM I would have used a NOT
operation, but for Modula this is good enough.
Furthermore I use the number 1193 to go from counting pulses to
milliseconds. It's a not too big number so it is good enough to use in
integer arithmatics.
This "MilliSeconds" routine is a dumb waiting-procedure. It calculates a
stop-value for the counter, initialises the counter to mode 2 and value
0000 and then waits until the timer reaches there. Next it closes the
timer and it's all over.
The next function, which was made for diagnostic purposes, shows that in
an application you would have to correct for the
---------- TestTimer ---------------------------- Start ----------
PROCEDURE TestTimer;
VAR First, Last, Delta, k : CARDINAL;
BEGIN
OpenTimer;
First := ReadTimer ();
WriteCard (First, 6); Write (Tab);
FOR k := 1 TO 10000 DO
(* Nothing! *)
END;
Last := ReadTimer ();
Delta := First - Last;
WriteCard (Delta, 6); WriteLn;
CloseTimer;
END TestTimer;
---------- TestTimer ----------------------------- End -----------
You could use this routine to calibrate a timingloop, but on modern PC
architectures this could well lead to disasters. Modern CPU's are so
damned fast, that your loopcounter will overflow.
Therefore this calibration technique is only useful for modifying
inherently slow routines, like those using I/O operations. For some
reason, I/O operations still need around one microsecond each, so these
will slow down the routine enough to make sure there will be no overflow
in the loop-counters.
A friend of mine just uses IN instructions from some silly address to
get reasonably accurate timingloops, assuming that 1 IN operation is
about 1 microsecond. Bit it could well lead to trouble on modern PCI
hardware.
All in all, for most delay-routines, the dumb waiting function is by far
the best since it is the most reliable and accurate to less than a
microsecond. But if you need this many digits, use compensated software,
that takes into account the time to read the timers twice -- because you
need to keep in mind that also this routine relies heavily on I/O
instructions, so it is not infinitely fast!
In a future article I will describe how to use the RTC chip for
generating timing signals and how to use it via the Programmable
Interrupt Controller in automatic mode. That article will be pure ASM
again, so don't be worried about this detour into Modula.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Programming for the one and only universal graphics mode
by Jan Verhoeven
If you need to write a graphics routine that has a reasonable resolution and
which is nearly always present, there is just one choice: mode 12h or the well
known 640 x 480 x 16. This mode is the highest resolution mode which is always
available in all VGA cards.
800 x 600 is better but it either needs a VESA driver installed or the user
must himself figure out how to switch the machine to that mode. Not an easy
task for the majority of "experienced Windows users" (isn't this a paradox?).
Mode 12h is treated as a worst case by many Superior Operating Systems. But
for most purposes it is just fine. It's fast, reasonably easy to use and it is
omni present.
That's why I decided to port my textmode windows to this graphics mode.
The application.
----------------
I built a simple AD converter that measures voltages and converts them into
digits. The ADC fits on a COM port and is completely controlled from software.
The idea was to have different reference voltages, sample rates, scaling
factors, a bar graph display and a 4 digit LED-style read-out.
And in the bottom window there is a "recorder" that plots pixels in real-time.
If all parts have been explained I might post the full package (the sources,
the schematics and such) so that everyone can build one for your own.
How to switch to Mode 12h?
--------------------------
Going to mode 12h is easy. Just use the BIOS interrupt 10h as follows:
mov ax, 012
int 010
and you're in. Remember, I use A86 syntax, so all numbers starting with a
nought are considered hexadecimal.
Plotting in a graphics screen.
------------------------------
Now that we're in Mode 012, we should also try to fill that clear black
rectangle. But first we should define a way of remembering WHERE to put our
cute little dots.
For all my plotting, I use the following structure:
-------------------------------- Window Information Block ------
Infoblk1 STRUC
Win_X dw ? ; top-left window position, X and ...
Win_Y dw ? ; ... Y
Win_wid dw ? ; window width and ...
Win_hgt dw ? ; ... height
CurrX dw ? ; within window, current X-coordinate, ...
CurrY dw ? ; ... and Y
DeltaX dw ?
DeltaY dw ?
Indent dw ? ; Indentation for characters in PIXELS!
Multiply dw ? ; screenwidth handler
Watte01 dw ? ;
BoxCol db ? ; border colour
TxtCol db ? ; text colour
BckCol db ? ; background colour
MenuCol db ? ; menu text colour
ENDS
-------------------------------- Window Information Block ------
It will be clear after looking into this list, that each InfoBlock describes a
window, a rectangular portion of the screen, which is treated as a unity.
Each window is defined by the topleft (x,y) coordinates and the window width
and height. Knowing these four words, the window is defined and fixed on
screen. If the window is to be moved, just adjust the topleft (x,y) position.
Since it is handy to know where in this window we are plotting, I defined two
more X and Y values: "CurrX" and "CurrY". When a request to (un)plot is made,
it will start on these coordinates.
For line drawing and such there are the "DeltaX" and "DeltaY" variables. The
former is for horizontal lines, the latter for vertical lines.
Now that we have our fancy window, where we can plot and draw lines, we also
need some text to see what it's all supposed to be about. The text is plotted
at the CurrX and CurrY postions. Each character is PLOTTED there, so tokens
can be put at ANY location on screen, not just on byte boundaries.
For nice and easy alignments, I defined the variable "Indent" which defines
how many pixels from the left or right margin must remain blank.
Since this software should be as easy to adapt to other resolutions as
possible, there is a need for a "Multiply" variable. This is filled with the
offset address of a dedicated screen multiplier routine.
In Mode 012 there are 640 pixels on a line. That's 80 bytes. So in order to
calculate the pixel address you need to use the following formula:
PixAddr = CurrY * 80 + CurrX / 8
So we need a set of damned fast Mul_80 routines. If needed you can make some
of them and at init-time find out the CPU and hardware and assign a suitable
routine and fill it in in the Window definition structures.
The "Watte01" field is just a filler. Reserved by me.
Since the Mode 012 has 16 colours to spare we should also use them. Therefore
I set up space for 4 colours: Box-, Text-, Background- and Menu-colours.
Each printing routine will make sure the right colour is set.
It will be clear that each window is very flexible to use. If the position is
wrong, just change a few numbers. Also if the colours are not optimal.
And by having several windows assigned to the same area on screen, you can
easily build special effects:
fullscrn dw 0, 0,640,480, 0, 0, 0, 0, 4, mul_80, 0
db 12, 14, 3, 15 ; main screen window
FullScrn just describes the complete screen. It is used for some very general
printing an plotting tasks. It starts at topleft (0,0) and is 640 wide and 480
high.
ParWin2 dw 5, 30,630,150, 8, 9, 0, 0, 4, mul_80, 0
db 10, 11, 3, 11 ; Parameter window
This is a window which is a subwindow of the Full Screen for storing data and
parameters.
PlotWin dw 5,195,630,260, 0, 0, 0, 0, 4, mul_80, 0
db 9, 15, 3, 7 ; Virtual plotting window
This is the Virtual Plotting Window. It has some text, plus the actual
plotting window:
PlotWin2 dw 6,196,628,256, 0, 0, 0, 0, 4, mul_80, 0
db 9, 15, 3, 7 ; Actual plotting window
This is the place where the pixels live. It starts one pixel down/right of the
virtual window and also ends one pixel short of it.
The reason for making this "dummy" window structure was that this way there is
no need for an elaborate checking of extreme ends of the window while erasing
pixels. On the extremes of the "Virtual Plotting Window" there are the pixels
that make up a nice coloured box. It looks not nice when these lines are
erased. And the easiest way to prevent this was by defining two separate
windows: one for constructing the box and one for the actual work.
The 4 digit LED-style read-out is also controlled by four different windows.
Each digit has its own window definition:
------------ Digit Space ------------------------------- Start ---
DigSpac1 dw 16, 90, 40, 50, 0, 0, 0, 0, 0, mul_80, 0
db 9, 11, 14, 3 ; Digital display, digit 1, MSD
DigSpac2 dw 56, 90, 40, 50, 0, 0, 0, 0, 0, mul_80, 0
db 9, 11, 14, 3 ; Digital display, digit 2
DigSpac3 dw 96, 90, 40, 50, 0, 0, 0, 0, 0, mul_80, 0
db 9, 11, 12, 3 ; Digital display. digit 3
DigSpac4 dw 136, 90, 40, 50, 0, 0, 0, 0, 0, mul_80, 0
db 9, 11, 12, 3 ; Digital display, digit 4, LSD
MSD = Most Significant Digit LSD = Least Significant Digit
------------ Digit Space -------------------------------- End ----
This way it is convenient to allign the digits on screen. As with normal LED-
style digits, the seven segments of them are drawn piece by piece. And erased
if necessary.
As you will know from voltmeters, the MSD is the least likely to change in
time and the LSD is most likely to be different between any two samples. So in
a way it is necessary to control erasing of just one digit without massive
software overheads. Therefore I again chose to use a separate window for each
digit. It makes erasing the digit easier and independent of the other three.
Something else to observe is, that the two or three digits behind the decimal
point have another colour from those before it. This way the user can easily
see the approximate magnitude of the number without having to search for a
decimal point. This is accomplished easily by having different BckCols in the
LSD windows.
This all costs a few bytes extra, but it saves a lot of coding.
How to quickly load a segment register.
---------------------------------------
Segment registers cannot be loaded with immediate data. So you normally put a
register on the stack and use that to transfer the constant to the actual
segment register. This is not necessary. It can be done much easier like
below:
VGA_base dw 0A000 ; for ease of loading segment registers
And the corresponding code:
mov es, [VGA_base]
The detour via the stack or via AX takes more cycles and bytes.
Defining what to print.
-----------------------
In a graphics screen there are an awful lot of places where to store our
text. So we need a way to define where to put which tokens. For this I use the
following construct:
-------------- Topic ----------------------------------- Start ---
Topic MACRO ; start of printing message
dw #1, #2
db #3, #4
#EM
TopicEnd MACRO ; topics stop here
dw 0F000
#EM
Topic 180, 9, 'Start : '
ParaStrt db 'Manual ', 0
Topic 9, 28, 'Power : '
ParaPowr db 'OFF', 0
Topic 360, 55, 'Group : '
ParaGrup db '16 ', 0
TopicEnd
-------------- Topic ------------------------------------ End ----
The Topic Macro puts the first two arguments (the new values for CurrX and
CurrY) in the first two WORD positions of the definition table. The actual
text is then put in the BYTE positions. In most cases there will be no #4
argument, but A86 doesn't care about that.
Each "to-print" table is shut down by an EndTopic Macro. It defines a new
CurrX of -4096. That clearly is out of range, so this is end of table.
In normal operation, small negative values of CurrX and CurrY are accepted and
taken care of, although it can be dangerous to use this feature.
Multiplying by 80.
------------------
On all CPU's form the 486, the MUL instruction is single cycle, so it'll be
damn fast. For all older CPU's, the following code could mean some significant
speed increases:
-------------------- Multiply ------------------------ Start ----
mul_80: push bx ; PixAddr in Mode 012
shl ax, 4
mov bx, ax ; bx = 16 x SCR_Y
shl ax, 2 ; ax = 64 x SCR_Y
add ax, bx ; ax = 80 x SCR_Y
pop bx
ret
-------------------- Multiply ------------------------- End -----
This routine is used over and over again, so a few microseconds more or less
will make a big difference.
Where to leave our pixels?
--------------------------
Suppose you need to plot pixel (3,0). That's an easy one. It will fit in the
very first byte of the VGA memory array. It's segment is 0A000 and it's offset
is plain 0.
But not the full byte, since that would produce a line. No, we need to access
bit 4 of byte 0.
Yes, the first pixel is bit 7 of byte 0 and the 8th pixel is bit 0 of byte 0.
Or, in index-language, CurrX = 0 addresses bit 7, and so on.
So we need to invert the screenposition into a bitposition. We'll come to that
later. Suppose, by some sheer magic, we succeeded in making that conversion,
we still need to tell the VGA which bit is involved. That's done by means of
the following routine:
--------------------- SetMask ------------------------ Start -------
SetMask: push dx ; ah = mask
mov dx, 03CE
mov al, 8
out dx, ax ; set bit mask
pop dx
ret
--------------------- SetMask ------------------------- End --------
This is an optimized routine. The VGA is a 16 bit card, so we can use 16 bit
I/O instructions for adjacent I/O ports. The construct:
mov al, 8
out dx, ax ; set bit mask
is identical to:
mov al, 8
out dx, al
inc dx
mov al, ah
out dx, al
Anyway, the plottingmask is defined to be as loaded in the AH register. We can
put any value in AH, not just one pixel, but also "no pixels" and "all
pixels".
Defining colour in Mode 012.
----------------------------
Colours to use during plotting are defined in a comparable fashion:
--------------------- Set Colour --------------------- Start -------
SetColr: push dx ; ah = colour
mov dx, 03C4
mov al, 2
out dx, ax ; select page register and colour
pop dx
ret
--------------------- Set Colour ---------------------- End --------
In Mode 013 you just can load a bytevalue colour into a memory location and
that's it. So that's an ultrafast resolution, but at the price of resolution.
In Mode 012 we define colour with a series of I/O instructions. If a colour
got set, it remains active until canceled by another SetColr call. Try to
remember this when all on a sudden all kinds of fancy colours start to appear
on screen....
Where to put the pixel?
-----------------------
I have presented the formula some paragrpahs before this one. Basically we
work with virtual coordinates and must translate these to real coordinates
before trying to calculate an address. This is done by:
------------------ VGA memory address ---------------- Start -------
VGaddr: ; calculate address in VGA memory
mov es, [VGA_base] ; quickly load segment register
mov ax, [di.CurrY] ; ax = current Y
add ax, [di.Win_Y] ; adjust for window offset
call [di.Multiply] ; multiply by bytes per row
mov bx, [di.CurrX] ; bx = current X
add bx, [di.Win_X] ; adjust for window offset
shr bx, 3 ; divide by 8
add bx, ax ; bx = index address into video segment
ret
------------------ VGA memory address ----------------- End --------
It's all fairly straightforward.
How do we plot pixels in Mode 012?
----------------------------------
This is a silly process. We cannot access all the 4 colour planes at once, so
we have used SetColr to define which colourplanes are to be affected. This all
is rather complicated. You may either believe me on my word, or consult a 1200
page reference....
Now that we're ready to plot pixels, we do so by the following code:
------------------ VgaPlot -------------------- Start --------------
VgaPlot: mov al, [es:bx] ; Do the actual plotting
mov al, [ToPlot]
mov [es:bx], al
ret
------------------ VgaPlot --------------------- End ---------------
The first line is a read command. It notifies the VGA controller about the
address of the pixelbyte. The resulting data from the read is of no concern.
We immediately replace it with the value of "ToPlot". For plotting there is a
value of "FF" in this byte and for erasing there is a "00" in it.
After this comes the actual plotting function. The write to the specified
address sets the pixels as defined by AL and SetMask.
Adding it all up gives the following code to really plot a pixel:
-------- PlotPix ------------------------------- Start -----------
PlotPix: push ax, bx, cx, es ; plot a point on screen
call VGaddr
mov cx, [di.CurrX] ; calculate plottingmask
add cx, [di.Win_X]
and cx, 0111xB ; cl = position in byte
mov ah, 080
shr ah, cl ; now move the high bit backwards...
call SetMask ; use it to set mask
call VgaPlot ; and do the plotting
pop es, cx, bx, ax
ret
-------- PlotPix -------------------------------- End ------------
That's it to plot a pixel: just a few calls to some procedures we defined
earlier on. The msjority of this procedure is comprised of the way to find the
actual bit-position in the VGA memory byte. Remember, to plot pixel 0 we need
bit 7!
Therefore we load CX with the current X value, correct this for the current
window position and isolate the lower 3 bits. These indicate the position of
the pixel in screenmemory.
mov cx, [di.CurrX] ; calculate plottingmask
add cx, [di.Win_X]
and cx, 0111xB ; cl = position in byte
At this point, CL contains the n-th bit in this byte. So I load AH with the
binary pattern 10000000 and shift it right until the corresponding bit
position is reached:
mov ah, 080
shr ah, cl ; now move the high bit backwards...
I don't know if there are batches of Intel CPU's that have a problem with the
SHR instruction is CL equals zero, but I have not yet noticed any.
Lines: series of pixels.
------------------------
There are three kinds of lines: horizontal, vertical and sloped ones. Vertical
lines are plotted pixel by pixel since all of them end up in different bytes
of VGA memory. Sloped lines are best taken care of by a Bresenham-style line
drawing algorithm (although the digital differential analyser is better).
Horizontal lines are a different kind of line. In these, several adjacent
pixels are plotted. And adjacent pixels mainly are in the same VGA memory
byte. Therefore I made two horizontal line drawers. The one for short lines
(less than 17 pixels) just plots the pixels one by one.
The other algorithm, for lines of 17 pixels or more, tries to fill VGA memory
with as much byte writes as possible.
Taking care of longer horizontal lines.
---------------------------------------
Suppose our line is composed as follows:
First 1 2 3 ... K Last ; byte in video memory
......## ######## ######## ###...### ###..... ; # = pixel to be set
So our line starts at pixel 6 (i.e. bit 1) of VGA memory byte "First". Next it
lasts for N pixels and the last pixel to plot is pixel 2 (or bit 5).
We need some variables to calculate how to proceed with this in the shortest
possible time. This needs some calculations, so for short lines the math
overhead is more work than the actual plotting will take up.
First 1 2 3 ... K Last ; byte in video memory
......## ######## ######## ###...### ###..... ; # = pixel to be set
We first need to know the E-value which describes the number of pixels to plot
in the very first byte. The E-value is calculated as follows:
E-val = 8 - ((CurrX + Win_X) AND 7)
Now we know the number of pixels to plot in the very first VGA memory
location. It would however come in handy if we would know with which plotting
mask this would correspond. That's why we use it to derive the E-mask:
E-mask = FF shr ((8 - E-val) AND 7)
Next we need to know how many pixels there need to be plotted in the last
memory location. L-value and L-mask are determined as follows:
L-val = (Total - E-val) AND 7
L-mask = 080 sar L-val
With the SAR we shift signbits to the right until the number of pixels
corresponds with the number of bits in the mask.
The last parameter we need to know is the actual speeding-up part: the full
bytes that can be plotted. The octet-part of the routine. We do this as
follows:
K-val = (T - E-val - L-val)/8
Now it also becomes clear why I kept the E-val and L-val parameters. They're
just needed for getting the right value for K-val.
There is, however one exceptional situation. Suppose the line we need to plot
is 26 pixels long, starting at pixel 6. This would produce the values:
E-val = 2 E-mask = 00000011
L-val = (26 - 2) AND 7 = 24 AND 7 = 0 L-mask = 00000000
K-val = (26 - 2 - 0)/8 = 3
So, if the line ends on a byte boundary, we may NOT try to plot <A LOT> of
pixels past it (in a plotting loop that starts with CX = 0).
What the H_line procedure does is no more than what I decribed above. Here
comes the source:
-------- H_Line -------------------------------- Start -----------
L0: mov cx, [di.DeltaX] ; do a short line
L1: call PlotPix ; by just repeating a single pixel-
inc [di.CurrX] ; plot and update of CurrX
loop L1 ; until done
pop es, cx, bx, ax
ret
H_Line: push ax, bx, cx, es ; optimized horizontal line drawing
cmp [di.DeltaX], 17 ; too few pixels for a bulk draw?
jb L0
mov cx, [di.CurrX] ; do a long line
add cx, [di.Win_X] ; first get the E-value as described
and cx, 0111xB ; above
mov bx, 8
sub bx, cx
mov [E_val], bx ; pixels to plot in leftmost byte
mov al, 0FF ; now compose the mask to use there
shr al, cl
mov [E_mask], al ; and store it in memory
mov cx, [di.DeltaX] ; CX = length of line
sub cx, [E_val] ; compensate for first-byte pixels
mov ax, cx
and ax, 0111xB ; this many pixels in rigthmost byte
mov [L_val], ax ; and store it in memory
sub cx, ax ; CX = number of pixels inbetween
shr cx, 3 ; divide by 8 pixels per byte
mov [K_val], cx ; number of "full" bytes to plot
clr al ; AL := 0
mov cx, [L_val] ; prepare to compose L-mask
cmp cx, 0 ; any bits in "last byte"
IF ne mov al, bit 7 ; if any bits, setup AH register
dec cx ; compensate for pixel 0, ...
sar al, cl ; ... compose plotting mask and ...
mov [L_mask], al ; ... store it into memory.
; that's it. Let's plot!
call VGaddr ; load BX with address of byte in
; VGA memory
mov ah, [E_mask]
call SetMask ; set plotting mask and ...
call VgaPlot ; ... plot leftmost part
inc bx ; get adjacent address
mov cx, [K_val] ; prepare for bulk-filling
jcxz >L4 ; if nothing to do, jump out
mov ah, 0FF ; else set ALL PIXELS mask
call SetMask
L3: call VgaPlot ; plot middle part
inc bx
loop L3 ; until done
L4: mov ah, [L_mask]
call SetMask
call VgaPlot ; plot remaining pixels
mov ax, [di.DeltaX]
add [di.CurrX], ax ; make sure CurrX is updated
pop es, cx, bx, ax ; and git outa'here
ret
-------- H_Line --------------------------------- End ------------
The preparations are the bulk of the work, but after that is done, the line is
plotted with the lowest amount of I/O overhead.
Vertical lines.
---------------
Vertical lines are simply plot by repeatedly calling PlotPix. It's so simple
that neither need nor want to elaborate on it:
-------- VertLin ------------------------------- Start -----------
VertLin: push cx ; draw a vertical line
mov cx, [di.DeltaY]
L0: call PlotPix
inc [di.CurrY] ; adjust Y coordinate
loop L0 ; but not X value!
pop cx
ret
-------- VertLin -------------------------------- End ------------
What to do with linedrawing functions?
--------------------------------------
Now that we can draw lines, we can also draw boxes and window borders. This
all looks very professional and the overview of a program is enhanced
considerably. Try to figure out how to make the box-drawers by yourself.
Plotting text.
--------------
Now that we have windows that can be put at any plotting position, we also
need to be able to position text at any position. It doesn't look nice if
different windows force text to default to byte boundaries. And with the
experience we got from the H_line function, we are able to make a character
plotter that puts text on screen at ANY position.
I use a 9 x 16 character set. The nineth bit is just always blank, but it
enhances readability considerably. The pixels in the bitmap are all 8 bits
wide and 16 pixels tall.
In exceptional cases, the bitmaps can be plotted at byte boundaries. In 85+ %
of the time this will not be the case. Therefore I do the following:
- do some positioning math first
- repeat 16 times:
- load the byte of the bitmap in AH
- shift AX to the right the correct number of pixels
- plot the AH part
- if plotting on a byte boundary, we're done, else
- repeat 16 times:
- load the byte of the bitmap in AH
- shift AX to the right the correct number of pixels
- plot the AL part
Let's just have a look:
-------- PutChar ------------------------------- Start -----------
L0: add [di.CurrY], 16 ; process 'LF'
L1: pop es, si, cx, bx
ret
L2: mov bx, [di.Indent] ; process 'CR'
mov [di.CurrX], bx
jmp L1
PutChar: push bx, cx, si, es ; print char in al at (x,y)
cmp al, lf
je L0
cmp al, cr
je L2
mov bx, [di.CurrX]
add bx, CHR_WID
cmp bx, [di.Win_wid] ; still safe to print character?
jbe >L3 ; if so, skip over this part
mov bx, [di.Indent]
mov [di.CurrX], bx ; mimick 'CR'
add [di.CurrY], 16 ; mimick 'LF'
L3: mov cx, [di.CurrX]
add cx, [di.Win_X]
and cx, 0111xB
mov [C_val], cl ; store shiftcount for masks
mov bx, 0FF00
shr bx, cl ; setup plotting mask and ...
mov [P_mask], bx ; ... store it
clr ah ; ax = ASCII code
mov si, ax ; make address of pixels in bitmap
shl si, 4
add si, offset bitmap
call VGaddr ; bx = -> in video memory
mov ax, [P_mask] ; only the AH part is used ...
call SetMask ; ... here.
mov cx, 16 ; 16 pixel lines per token
L4: push cx ; we're in the loop now
mov ah, [si] ; AH = pixelpattern
clr al ; AL = empty
mov cl, [C_val] ; get shiftcount
shr ax, cl ; distribute pixelBYTE across a WORD
mov cl, [es:bx] ; dummy read, CL is expendable
mov [es:bx], ah ; actual plotting of this half
add bx, 80 ; point to next pixelbyte address
inc si ; next pixeldata address
pop cx
loop L4 ; and loop back
sub bx, 16 * 80 - 1 ; back to original position
mov ax, [P_mask]
cmp al, 0 ; if nothing to do, ...
je >L6 ; ... skip this chapter
mov ah, al ; else repeat the lot for the right-
call SetMask ; most pixels....
mov cx, 16
sub si, cx ; correct SI
L5: push cx
mov ah, [si]
clr al
mov cl, [C_val]
shr ax, cl
mov cl, [es:bx]
mov [es:bx], al
add bx, 80
inc si
pop cx
loop L5
L6: add [di.CurrX], CHR_WID ; adjust CurrX value before ...
jmp L1 ; ... getting a hike
-------- PutChar -------------------------------- End ------------
So far for plotting text. This routine will dump any character in any place of
the graphics screen. But it needs a CurrX and a CurrY value to know where to
plot things. This is both an advantage and a disadvantage. The advantage is
that we can plot ANYWHERE we like. The disadvantage is that we need to
elaborately specify CurrX and CurrY before the text is where we would like to
have it.
That's why I made the constrcut with the Topic and TopicEnd macro's, as
described above.
Here comes the code for printing a table on screen. We spent a lot of time on
the preparations, and this is the stage where it is going to pay off. Look how
much code we need for printing neat sets of tokens and characters on screen.
-------- Print --------------------------------- Start -----------
print: mov ah, [di.TxtCol] ; print a table of text
call SetColr
L0: lodsw ; get Xpos
cmp ax, 0F000 ; end of table?
je ret ; exit, if so
mov [di.CurrX], ax
lodsw ; get Ypos
mov [di.CurrY], ax
L1: lodsb ; get text
cmp al, 0
je L0
call putchar ; and print it
jmp L1 ; until this line is done
-------- Print ---------------------------------- End ------------
Wit this approach, and starting from a working (empty) framework of routines,
you can design the userinterface of your software within the hour. And it will
look just fine.
The actual code is then the only thing you need to worry about.....
Having such routines, which have been tested and found reliable, you make the
user interface easily and are able to concentrate on the actual coding the
maximum amount of time. If the screen needs another layout (since you couldn't
realize the function you considered), just change a few entries in the table.
Many times just the X or Y values need some adjustment for better lining up,
or for regrouping. No need to worry about the order of the plotting. Just make
sure that the correct window is selected (for the colours) and that the table
is terminated by a TopicEnd.
Conclusion.
-----------
So far my elaboration on the VGA mode 12h. Again, I would rather use 800 x 600
but that mode is not standardised. VGA 12h is standard on all VGA cards, so
it's the best we can universally get and for many applications it is more than
enough.
Please try to make the BoxDrawing function. I will submit the "solution" to
the next issue. For future issues I will start working on an explanation about
mouse-usage. This little rodent is nice to control many applications. If the
screen is well layed out, you don't need the keyboard for data entry. Just drag
the mouse along the screen and poke him in the eye.
The bitmap data for the character generator can be obtained from
http://asmjournal.freeservers.com/supplements/univ-vmode.html
where the complete text of the article has been archived.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Conway's Game of Life
by Laura Fairhead
I had the idea for this one day after stumbling upon a "gem" that
somebody had written to play life. It was small and fast and reminded
me of years ago when I had written many versions of this for the
BBC Master 128 (my love lost). Since I had never written a version
for the PC I thought that I would, and ended up spending some hours
trimming off the bytes until it is now :- 156 bytes long. I must admit
if it was not for the program that I found, this program would have been
MUCH slower than it is. After I had written the code I tested it against
the program that I had found and to my perplexity it was a great deal
slower. After some hours of frustration I found the reason:- my program
was accessing the video memory to do the bulk of its work. This must have
brought about a factor of 12 decrease in speed!!
Life is a classic game of cellular automata by John Conway. It is
played on an nxn grid of squares. Each square may be occuppied by a
cell or empty. Each 'go' of the game the player calculates the next
generation of a colony of cells by applying three simple rules:-
(i) a cell with less than 2 or more than 3 neighbours dies
(ii) a cell with 2 or 3 neighbours survives
(iii) a cell is born in a square with exactly 3 neighbours
A neighbouring square is one diagonally adjacent as well as the
normal horizontal/vertical so each square has 8 neighbouring squares.
Overview of the code
~~~~~~~~~~~~~~~~~~~~
First, note that if we define
S:=state of square in this generation (0=empty, 1=occupied)
N:=number of neighbours
S':=state of square in the next generation
then according to the rules
S'={0, if N<2 or N>3
{1, if (N=2 or N=3) and S=1
{1, if N=3
so S'=1 iff (N=2 and S=1) or N=3
this can be simplified using bitwise-OR to the dramatically simple:
S'= ( N|S=3 )
note: iff means "if and only if"
"A iff B" means that A => B and B => A
The code uses one big array with one byte for each square that
starts just after the program end. To save space it just assumes that it
can use this memory since this is generally okay. However this is
very bad practice really and it should use AH=04Ah/int 021h to adjust
the memory size and abort if not successful.
The big array actually serves the purpose of 2 arrays; bit0 of
a byte indicates the state of the square in the current generation. bit4
of each byte indicates the state of the square in the next generation.
After initialisation, generation 0 is calculated by filling about
1/4 of the array with 1's.
Now we do a loop to get the next generation. The screen is 0140h
bytes across and 0C8h bytes down. Therefore:-
-0141h -0140h -013Fh
-0001h . +0001h
+013Fh +0140h +0141h
If DI is the offset of the array which we are calculating for,
note that the neighbours can be summed as follows:-
MOV AX,[DI-0141h]
ADD AL,[DI-013Fh]
ADD AX,[DI+013Fh]
ADD AL,[DI+0141h]
ADD AL,[DI-1]
ADD AL,[DI+1]
ADD AL,AH
Note that if bit4 of any of the neighbours was set then we would
still have the correct total in the least significant 4 bits of AL.
So from here the new cell state can be calculated simply:-
OR AL,[DI]
AND AL,0Fh
CMP AL,3
And if ZF=1 now we have a set cell.
JNZ ko
OR BYTE PTR [DI],010h
ko:
When the next generation has been calculated we have done most of
the work. The only thing is that if we want to iterate we need all
of those bit4 's moved to bit0, also we want to display the next
generation, this can be done easily at the same time.
Note that due to the structure of the code generation#0 is never
displayed. Also we always have blue cells. Despite this it is quite
an entertaining little program to watch....
The source here is in MASM format but should be trivial to convert
to run on any assembler. It is assembled into a .COM file which means
you should use the /T option on the linker (T=tiny).
===========START OF CODE===================================================
OPTION SEGMENT:USE16
.386
cseg SEGMENT BYTE
ASSUME NOTHING
ORG 0100h
kode PROC NEAR
;
;mode 013h=320x200x256 (0140hx0C8h) and be kind with the stack
;
MOV SP,0100h
MOV AX,013h
INT 010h
;
;use current time as random number seed
;in BP,DX which is used later
;
MOV AH,02Ch
INT 021h
MOV BP,CX
;
;get seg address of 1st seg after code for array store start
;for now ES points there and DS=screen
;
MOV AX,DS
ADD AX,01Ah ;(OFFSET endofprog+0Fh>>4)=(1A)
MOV ES,AX
MOV AX,0A000h
MOV DS,AX
;
;CREATE GENERATION#0
; this is done by filling approx 1/4 of the cells in the array
; 'randomly', while taking care not to fill any edge cells
;
;
;blank the array
; this is done to ensure the edge cells are clear
;
XOR DI,DI
MOV CX,0FA00h
REP STOSB
;
;fill the array
; two nested loops, CL counts the rows, SI counts the columns
; this is so that after each row DI can be bumped past the edge
;
MOV CL,0C6h
MOV DI,0141h ;array offset we are addressing
;
;BX is 0141h from now until exit, it is used as a constant later
;
MOV BX,DI
lopr0: MOV SI,-013Eh
;
;iterate random number seed in BP,DX
;
lopr: LEA AX,[BP+DI]
ROR BP,3
XOR BP,DX
SUB DX,AX
;
;set cell with probability 1/4
;
CMP AL,0C0h
SBB AL,AL
INC AX
STOSB
;
;
INC SI
JNZ lopr
SCASW ;DI+=2, skipping edge
LOOP lopr0
;
;now we set DS=array, ES=screen. this doesn't change until exit
;
PUSH ES
PUSH DS
POP ES
POP DS ;DS=vseg,ES=0A000h throughout
;
;'mlop' is the main loop, outputting generations until the user terminates
;
mlop:
;
;CREATE NEXT GENERATION
;
MOV DI,BX ;DI=0141h
;
;'lopy' is the loop for rows, a count is not needed because we can get
;the stop point from testing the array offset DI
;
lopy: MOV SI,013Eh
;
;'lopx' is the loop for columns, SI holds the count
;
;
;get the total number of neighbours into the least significant 4 bits of AL
;
lopx: MOV AX,[DI-0141h]
ADD AL,[DI-013Fh]
ADD AX,[DI+BX-2]
ADD AL,[DI+BX]
ADD AL,[DI-1]
ADD AL,[DI+1]
ADD AL,AH
;
;calculate new cell state
;
OR AL,[DI]
AND AL,0Fh
CMP AL,3
JNZ SHORT ko
OR BYTE PTR [DI],010h
ko: INC DI
DEC SI
JNZ lopx
;
;(each row we miss 2 edge cells)
;
SCASW
CMP DI,0FA00h-013Fh
JC lopy
;
;FIXUP ARRAY AND DISPLAY
; bit4 is copied to bit0 in each byte. all other bits then cleared so
; cells appear as blue pixels, also the iteration loop above assumes
; that bit4 is clear on entry (it only sets it)
;
MOV CX,03E80h
XOR DI,DI
lopc: LODSD
SHR EAX,4
AND EAX,01010101h
MOV [SI-4],EAX
STOSD
LOOP lopc
;
;USER KEYPRESS?
;
MOV AH,0Bh
INT 021h
ADD AL,3
;
;no, back for next generation
;
JP mlop
;
;yes, AL=2 now so make AX=2 to go into text mode
;
CBW
INT 010h
;
;back to DOS
;
MOV AH,04Ch
INT 021h
kode ENDP
endof EQU $
cseg ENDS
END FAR PTR kode
===========END OF CODE=====================================================
While the code is optimised for size and for speed you may find that
it runs too quickly. This can be easily remidied by the addition of a wait
for vertical synchronisation loop (or vert sync as we techies call it).
Just add the following after the generation calculating code (that
is after the instruction 'JC lopy'):-
MOV DX,03DAh
lopv0: IN AL,DX
AND AL,8
JNZ lopv0
lopv1: IN AL,DX
AND AL,8
JZ lopv1
Also if you add this the program size has changed. 'endofprog' is now
01ABh, so the number of segments to add to DS to get the start of free space
is now 01Bh. You must change the instruction at the beginning of the code:-
MOV AX,DS